Tuesday, 14 June 2022

Ditching Redhat

As I've written elsewhere, when I started my current gig in 2019, the infrastructure and IT Operations turned out to be very different than what I had been told when I handed in my notice to my previous employer. The description I keep going back to is that it was a fractal horror story.

The majority of the systems were Centos, along with some Redhat boxes (pre-dating the "Enterprise" moniker) and a few Whitebox Linux machines. I'd ever heard of Whitebox before I arrived here. The Whitebox Linux distribution was a free version of Redhat Linux (again without the "Enterprise"). These dated from the last millenium.

Upgrading the systems in place was going to be a lot more work than replacing them. In the majority of cases they were so old that the repositories were no longer online. Further, the key server components were all built from tarballs. And every host had a different version of the base operating system, and different builds/file layouts. As a result there was benefit to sticking with Redhat/Centos. By reverting to repo based software installations (wherever possible) we would be deploying updates from a single, trusted channel.

So would it better to replace this with something else? As I was deliberating this, IBM bought over Redhat. And while there was nothing to suggest that the future for Centos might be any different this was not a good time to be commiting to Centos as the strategic platform going forward. Further, I've seen the impact of trying to run Linux with the SELinux targeted policy in an Enterprise environment.

I did consider the possibility of migrating to a docker (or similar) infrastructure. But the disadvantages and risks from this massively outweighed any benefits.

My initial thought was to go for a purely rolling release model. The systems in place had not been upgraded because management
- was terrified of breaking stuff
- did not have enough people/right skills to implement upgrade cycles
While the level of risk of breaking things with a rolling release compared to a staged release was probably the same, the rolling release model would mean that pain would be more spread out. However there are no large scale rolling release distros geared towards enterprise environment. Is rolling-release in the enterprise simply an oxymoron?

While I had previously run a datacentre primarily on Suse, that was a long time ago. Yast is still a fantastic toolkit but Suse seems to have become less relevant in an enterprise server role. Debian stable would have been a good fit - with the advantage of a huge range of software available from official repositories, however I didn't want to move to a platform with even less frequent upgrade cycles that RHEL.

This left Ubuntu as the next obvious choice.

In addition to upgrading the hosts, I also wanted to move the infrastructure from a 1990's dial up ISP to something more akin to a modern, integrated environment; grouping functionality by its technical role with structured dependencies instead of building the same wheels over and over again. A priority was building a proper DMZ to sit between the applications and the internet. This meant I could: 

  • avoid exposing the ancient machines directly on the internet
  • centralize/automate certificate managementupgrade all the sites to HTTP/2 without having to replace the platforms
  • implement WAF-like security controls
  • implement useful analytics


So after some initial testing, I built out a cluster of reverse proxies using Ubuntu and nginx.

The impact was huge.

Changing to HTTP/2 resulted in page load speeds roughly doubling on every service.

Letting the lightweight proxy handle the long haul communications freed up processes (and therefore memory and CPU) on the origin servers resulting in a massive increase in capacity. Previously the moitoring would light up like a christmas tree as load ramped up every morning, swap files filled up and response times plummeted. This almost completely eliminated the issues.

I expect I would have seen these same benefits regardless which Operating System/distribution I had chosen, but Ubuntu has proved to be fast, reliable and very low effort.

As the modernization program has progressed, every investment in re-platforming/upgrading has paid back multi-fold. I've only run into two issues which couldn't be solved on the path I'd planned.

The first was Solr. The version in the Ubuntu repos (inherited from Debian) is old and very badly organized. For this the tarball package proved to be a mch better choice.

The second was FreeIPA. As part of the modernization we needed to replace the old OpenLDAP installation. Moving to FreeIPA provided an integrated solution which could easily support additional features (notably sudo). However the version available from repo at that time was not very current / stable. After trying various options I went with Alma Linux on the hosts for the FreeIPA service.

I guess I'm digressing from where I started to talking about architecture.

While these changes have demonstrated their value, the choices here were, in many cases, the exact opposite of the obvious solution:

- Solved a work overload by taking on more work
- Solved an inability to patch by maximizing the frequency at patches were available/applied
- Simplified the management of the infrastructure by introducing more components/complexity



Tuesday, 12 April 2022

Password Manager 2

Having previously decided to try out Syspass, I must say I'm disappointed.

In terms of the broad design it gets a lot of things right. But the implementation is particularly poor and buggy. It is built as a single page application and if you accidentally hit the back button or close your window then its rather painful to get back to your session (at least as something you can interact with). Operations will randomly fail then succeed when re-invoked. The permissions/access model around the API make it unsuitable for integration with clients in most cases. And the browser plugin would not work at all for me.

I'm still using it just now - it's better than the spreadsheet it replaced. And I've gone to the trouble of writing scripts to very the passwords and export the data to Keepass. 

I was excited to learn of VaultWarden - and open source implementation of BitWarden. The current version would not compile on Ubuntu 20.04LTS (required newer version of Rust) so I tried out the docker version. The software has no support for user groups which would make policy management an enormous job.

Why is this so hard people!


Tuesday, 25 January 2022

Proxmox Backup Server Evaluation

 I'm already running Proxmox Virtualization Environments (3 x PVE clusters) at $WORK. Currently these just dump backups to NFS, but I am evaluating more sophisticated options in advance of replacing the existing Simplivity clusters with Proxmox. Proxmox Backup Server has (not surprisingly) very good integration with PVE and hence an obvious choice.

The first (actually second - the first was a prototype and got deleted) PVE cluster provides our Dev and Test environments, so for the evaluation I just created a VM there. When I get around to implementing the service properly it will be on separate hardware.

Performance

Currently the daily backups on the dev/test cluster are getting close to overrunning their out-of-hours time slot - so a faster backup is critical for the next environment. My test cases were a couple of recent LXC containers and a very old Centos 5 VM (on the basis that if it works with that it should work for anything!).
There were little differences in time for the backups comparing NFS with LZO compression, NFS with ZSTD compression and PBS (although more than the graph suggests - that's a log scale) until I ran a second backup of the VM using PBS. Backup time for 55Gb VM dropped from 15 minutes to 3 seconds! For that reason alone, PBS looks the winner here. Sadly, the LXCs did not exhibit the same speed up - apparently this an architecture thing due to a VMs ability to track dirty pages.

Data size

In terms of the data footprint, there was again, not much difference between the methods until I got to the second round of backups via PBS. The de-duplication offers a huge gain for VMs and for LXCs. I expect this reduction in data volumes to carry over to the replication when I look at offsite replication.

I am somewhat wary of de-duplication having fallen foul of its implementation in Simplivity a couple of times, however on Simplivity, the virtual disk is included in the same de-duplication dataset as the backups - so one bad block not only takes out your VM but also all your backups too. With the PVE + PBS model, the virtual disk is separate from the backups.

Utility

The ability to mount a PBS backup and extract a single file or directory tree is really useful.

What's not to like...

I've not fully grokked the backup pruning but the facility is an elegant solution to the problem of maintaining older backups. 

Although I've done 2 rounds of backups on PBS, I can currently only see one version in the user interfaces of both PVE and PBS. 

Like local PVE backups, the naming is based on the VM/T ID rather than its given name. If you run an environment like mine that means you need to maintain a lookup table (I've already got this scripted against the API).

The lack of a speed up for LXCs is doubly disappointing - unlike VMs, the LXCs need to be offline for a large part of the backup, but I'm happy with the trade-off of using mostly VMs in the new environment. In my research, I also came across a post by Stefano Marinelli who is using Borg backup for his LXCs with some success. However I'd prefer not to start down the road of providing different solutions to what should be the same problem - particularly when its about provisioning something I hope not to depend upon!
 

Update

Although the first backup was visible in the PBS after it was run, on subsequent runs it was not: after the third run, two versions were visible, after the fourth, three....

Bit of a strange one, but effectively resolved.

Friday, 10 December 2021

CVE-2021-44228 log4j RCE mitigation

 "This seems to be generating some buzz" - a passing comment in $WORK's chat app - promoted me to go look at this in a bit more detail. As a systems admin, I generally let the devs guy worry about the health of the applications while I deal with the infrastructure, but this one is bad. Real bad. Like Corona virus for Java application servers. It even came from China (but kudos to the AliBaba guys for letting everyone know - this could have gone very differently).

I've never been able to work on Java developer timescales - and I didn't think this vulnerability would let me. So...

Fail2ban

I've got a small cluster of proxies fronting the web and application servers. These have fail2ban running which does a good job of keeping the script-kiddies out (really - I needed to put in a bypass for the company we subcontract the pen-testing to). So first off was a fail2ban rule:

#
[Definition]

failregex =     ^<HOST>.*\"\${jndi:ldap://
ignoreregex =


But fail2ban reads the log files to get its input. The log files don't get written until the request is processed. It won't catch the first hit.

Containment

The exploit works by retrieving a malware payload from an LDAP server. So the next step I took was to add firewall rules preventing our application servers from connecting to ports 389 and 636 other than our whielisted internal LDAP servers. 

Of course that's only going to help when the attacker is using an LDAP server running on the default ports. Bit it was worth doing. We were already getting attempts to exploit out servers, but they were crude / badly targeted. Until 14 minutes after I rolled out the firewall change. When we got hit by a request which would have triggered a successful exploit.

Prevention

The best mitigation (apart from applying the patch) is to set the "formatMsgNoLookups=true" option (hint for non-Java people out there - add this on the Java command line prefixed with "-D"). However according to the documentation I could find this only works on some version of log4j / it is far from clear just now if those versions are a sub-set or a superset of the versions which are vulnerable to the exploit, and I did not have time to go find out.
 
It seems obvious now, but there is a better way of protecting the systems. The proxy cluster uses nginx, so I went on to add this in the config:

if ($http_user_agent ~* \{jndi: ) {
        return 400 ;
}
if ($http_x_api_version ~*  \{jndi: ) {
        return 400 ;
}

(note that the second statement may have a functional impact).

I don't know if I've covered the entire attack surface with this, but now I get to go to bed and our servers live for another day.

Tuesday, 16 March 2021

Provisioning remote access with Linux - why not Guacamole?

Previously I posted about provisioning secure remote access - a zero-trust access solution.

I've been asked a few times why I didn't just install Guacamole.

Apache Guacamole is an excellent tool - but it provides a rather different spin on the problem of remote access. It's really a sort of privileged access management tool - you authenticate to Guacamole and it then injects credentials into client applications. It can do TOTP with GoogleAuth.

I didn't want to provide access to privileged accounts - I wanted people to access their own accounts.

If Guacamole could integrate with a good secrets management system, or even just PAM it would make it so much better. If it used PAM for authentication this would open the door to so many more use-cases. It does have a few choices for how to authenticate but does the Java thing of constantly reinventing the wheel. And I want my security to be as solid as possible.

It wasn't really that hard to get my solution (which, unlike Guacamole, really leverages the existing security subsystems of Linux).

Wednesday, 10 February 2021

xrdp: login failed for display 0

 I should know better. Anything that involves Microsoft will either work out of the box or be a world of pain.

TL;DR 

xrdp login with Active Directory account failing - still don't have a complete solution. The error reported above is generic - anything could be going wrong.

The problem...

My problem today is in setting up a virtual Linux desktop with AD authentication. The fact that its a virtual desktop rather than a physical one shouldn't be relevant. Of course it doesn't help that AD instance I'm connecting to is very temperamental. Its full of broken GPOs and the reverse DNS doesn't work. But mostly my gripe is about xrdp (and the hundreds of people who regurgitate the same simple fixes without any links to authoritative resources).

I got the box up and running. Xrdp was working with local Unix accounts. I joined the host to AD. Xrdp still works with local accounts. I could ssh to the host with a MS-AD account. But xrdp with a MS-AD account failed with "xrdp: login failed for display 0". 

You'll find lots of "fixes" for this in Google (without any diagnostics). This message is reported when anything goes wrong - things which are specific to xrdp, and other things:

  • wrong username/password
  • a username starting with a digit
  • X server not running
  • permissions for the user account
  • connecting with too great a bit-depth for some servers 
  • too many sessions already connected
  • firewall blocking access to AD Global catalog
  • other stuff

So here's what I did:

Read the log files

This is a Mint 20 system, so the default log is /var/log/syslog. There is also a specific log for xrdp (/var/log/xrdp-sessman.log) and Xorg (/var/log/Xorg.0.log). The xrdp log contained a very small subset of what was in the syslog. The Xorg log was untouched.
 The syslog contained lots of audit information and the fact that login failed, but nothing I could see which indicated why.
In /etc/rdp/sesman.ini, the log level was already set to DEBUG.  

Check pam authentication config

Both /etc/pam.d/sshd and /etc/pam.d/xrdp-sesman include common-auth to handle authentication. And that defines pam_sss.so as a provider of the auth service.

Disabled Manadatory Access control

Unlike SELinux  I've never had issues with Apparmor config out of the box. However just to eliminate this, I disabled it. That didn't help. But it did cut down the noise in the log files:

Feb 10 12:27:17 dev-d02-pg-user systemd-resolved[464]: message repeated 5 times: [ Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.]
Feb 10 12:28:47 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
Feb 10 12:28:47 dev-d02-pg-user xrdp-sesman[608]: (608)(140486245402176)[INFO ] A connection received from ::1 port 41674
Feb 10 12:28:48 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[INFO ] xrdp_wm_log_msg: sesman connect ok
Feb 10 12:28:48 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
Feb 10 12:28:48 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[DEBUG] return value from xrdp_mm_connect 0
Feb 10 12:28:48 dev-d02-pg-user systemd[1]: Started SSSD NSS Service responder.
Feb 10 12:28:48 dev-d02-pg-user sssd[nss]: Starting up
Feb 10 12:28:48 dev-d02-pg-user systemd[1]: Starting SSSD PAM Service responder...
Feb 10 12:28:48 dev-d02-pg-user systemd[1]: Started SSSD PAM Service responder.
Feb 10 12:28:48 dev-d02-pg-user sssd[pam]: Starting up
Feb 10 12:28:51 dev-d02-pg-user systemd[1]: Starting SSSD PAC Service responder...
Feb 10 12:28:51 dev-d02-pg-user systemd[1]: Started SSSD PAC Service responder.
Feb 10 12:28:51 dev-d02-pg-user sssd[pac]: Starting up
Feb 10 12:28:52 dev-d02-pg-user xrdp-sesman[608]: (608)(140486245402176)[DEBUG] Closed socket 9 (AF_INET6 ::1 port 3350)
Feb 10 12:28:52 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[INFO ] xrdp_wm_log_msg: login failed for display 0
Feb 10 12:28:52 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[DEBUG] xrdp_mm_module_cleanup
Feb 10 12:28:52 dev-d02-pg-user xrdp[959]: (959)(139750112610112)[DEBUG] Closed socket 16 (AF_INET6 ::1 port 41674)

Log files again

Looking in /var/log/auth.log, I found this:
Feb 10 13:36:52 dev-d02-pg-user xrdp-sesman[606]: pam_sss(xrdp-sesman:account): Access denied for user symcbean.in.msad: 6
 (Permission denied)


At last, a smoking gun!
I commented out the pam_sss.so entry in /etc/pam.d/common-account:
### account    [default=bad success=ok user_unknown=ignore]    pam_sss.so
and rebooted. Now I no longer get en error on the rdp client! I no longer get an error in auth.log. Sadly though, I don't get a desktop session - just a blank window :( Also, I'm not sure exactly what I've changed here - I suspect it may be the host-based access control mechanism? 

xrdp-sessman.log says....

[20210210-13:55:14] [INFO ] A connection received from ::1 port 55456
[20210210-13:55:15] [INFO ] ++ created session (access granted): username
symcbean.in.msad, ip ::ffff:10.2.0.40:58538 - socket: 12
[20210210-13:55:15] [INFO ] starting Xorg session...
[20210210-13:55:15] [DEBUG] Closed socket 14 (AF_INET6 :: port 5910)
[20210210-13:55:15] [DEBUG] Closed socket 14 (AF_INET6 :: port 6010)
[20210210-13:55:15] [DEBUG] Closed socket 14 (AF_INET6 :: port 6210)
[20210210-13:55:15] [DEBUG] Closed socket 9 (AF_INET6 ::1 port 3350)
[20210210-13:55:15] [INFO ] calling auth_start_session from pid 951
[20210210-13:55:15] [DEBUG] Closed socket 8 (AF_INET6 ::1 port 3350)
[20210210-13:55:15] [DEBUG] Closed socket 9 (AF_INET6 ::1 port 3350)
[20210210-13:55:25] [ERROR] X server for display 10 startup timeout
[20210210-13:55:25] [ERROR] X server for display 10 startup timeout
[20210210-13:55:25] [ERROR] another Xserver might already be active on display 10 - see log
[20210210-13:55:25] [CORE ] waiting for window manager (pid 964) to exit
[20210210-13:55:25] [DEBUG] aborting connection...
[20210210-13:55:25] [CORE ] window manager (pid 964) did exit, cleaning up session
[20210210-13:55:25] [INFO ] calling auth_stop_session and auth_end from pid 951
[20210210-13:55:25] [INFO ] shutting down sesman 1
[20210210-13:55:25] [DEBUG] cleanup_sockets:
[20210210-13:55:25] [INFO ] ++ terminated session:  username
symcbean.in.msad, display :10.0, session_pid 951, ip ::ffff:10.2.0.40:58538 - socket: 12

Partial Solution

I can't remember which log file I found it in - but some of the Xclients were reporting errors creating config files in $HOME. In checking I found that $USER did not have permissions on $HOME. Although I had installed oddjob-mkhomedir, this did not appear to be working as expected - I had manually created the home dir and failed to set the permissions correctly. The combination of commenting out the /etc/pam.d/common_account entry and fixing the permission on $HOME allowed me to login with my MS-AD credentials.

Miscellaneous

  • https://superuser.com/questions/1264096/xrdp-rejecting-login
  • https://www.reddit.com/r/linuxadmin/comments/js3grq/pam_sss_sshdaccount_access_denied_for_user_ad/
  • https://access.redhat.com/solutions/2187581 (paywalled)
  • https://listman.redhat.com/archives/freeipa-users/2015-March/msg00489.html
  • https://thornelabs.net/posts/rhel-6-fix-xrdp-error-another-xserver-is-already-active-on-display-10.html (probably not my issue since it works with a local account, although it might be due to missing config in $HOME)

Friday, 5 February 2021

5 indicators that an article is not worth reading

You've seen them often enough. They lure you in with a promise of fulfilling your heart's desire, empowering you and transforming your management/IT/tap-dancing skills. Follow this simple guide and save hours of frustration. You can avoid wasting your life exposing yourself to someone's Google adword farm. Watch for these tell-tale signs....

A complex discussion is decomposed into a small number of bullet of bullet points (5 seems particularly popular). The prose is presented as rambling text, usually 2-3 screenfuls when a bullet point layout would have taken a fraction of the space and less of your time.

The N points only address a subset of problem context from a unilateral viewpoint

The article spends more time discussing a specific solution than the problem
or even how the solution addresses the problem. It certainly never, ever compares alternative approaches.

Buzzwords - "Successful", "Must Read", "master"

It never links to authoritative sources.

It's just getting to the point where you might learn something you didn't already know when