Comprehensive guide to hardening RHEL clones?

Is there some sort of comprehensive guide on hardening RHEL clones like Alma and Rocky?

I have read Madaidan's blog, and I plan to go through CIS policies, Alma and Rocky documentation and other general stuff like KSPP, musl, LibreSSL, hardened_malloc etc.

But I feel like this is not enough and I will likely face problems that I cannot solve. Instead of trying to reinvent the wheel by myself, I thought I'd ask if anyone has done this before so I can use their guide as a baseline. Maybe there's a community guide on hardening either of these two? I'd contribute to its maintenance if there is one.

Thanks.

22 comments

Madaidan's Insecurities hasn't been updated in a few years, so some of the information is a bit out of date. It is still decent information, but don't follow it granularly. What you may be looking for instead is secureblue, which essentially does what you are describing but for Fedora Atomic desktops.
- Thank you for that. Yes, I only really follow his post roughly.
  Unfortunately, I don't think secureblue is going to be a possible choice. I like the secureblue project, I think it's awesome but what I'm working with will likely only come with a Rocky/AlmaLinux base.
- From secure blue's website:
  Who is secureblue for?
  secureblue is for those whose first priority is using Linux, and second priority is security. secureblue does not claim to be the most secure option available on the desktop. We are limited in that regard by the current state of desktop Linux standardization, tooling, and upstream security development. What we aim for instead is to be the most secure option for those who already intend to use Linux. As such, if security is your first priority, secureblue may not be the best option for you.
  Why do they say that? What limitations does Linux have in terms of security?
  
  https://privsec.dev/posts/linux/linux-insecurities/
  That's a more up-to-date article about security issues with Linux.
  TL;DR is that Linux (the desktop, not the kernel) is fundamentally insecure, and so the more secure options for desktop are Qubes OS (Qubes OS is not a Linux distro) or (even better) GrapheneOS used in Desktop Mode. secureblue is about as secure as Linux can get, but the most secure option for desktop itself.
  Things also get weird when you consider running secureblue inside of Qubes OS. See my post for more thoughts about that.
What do you want to achieve exactly?
Different requirement can lead to different approach.
- What do you mean? I want to harden it in a general sense against exploitation
  
  What does that even mean? What kind of exploitation are you talking about?
  Every use case comes with its own risk, and every risk needs to be handled differently. People jokingly said that if you wanna be sure, don't connect your computer to the network at all; and if you wanna be surer, don't use a computer. While that was a joke, there's truth in that.
  If you're just going to use it as a workstation, then firewall to make sure some randos don't ping you should suffice. If you're sharing this workstation with your tech illiterate mates, then perhaps something to prevent executing random stuff like SELinux or AppArmor would do. If executing random stuff is just what you do, then set up VMs or some other ways to isolate that execution environment.
  If you're sharing files directly from your computer to the internet (e.g. with SMB or NFS), then you'd need to make sure only the right people have the access, and the auth can't be brute-forced (i.e. with rate-limiting and lock-out policy). Same goes if you allow remote login (i.e. thru SSH). Some people use custom port number to obscure their stuff, and you can do it too, but do keep in mind it could make your life (or your mates' lives) harder.
  If you're running other outward facing services like SQL database or HTTP, that would require different ways to address. If you're on such level, you'd want do some serious readings.

22 comments