If you want to harden one or more Linux systems, you need to bring a lot of time, energy and patience with you – because there are all kinds of hurdles to overcome. These are the biggest and most annoying “showstoppers”.
Linux administration is a feast for “hobbyists”
Let’s start with a provocative statement: Linux systems are still a bit of a hobbyist’s thing today. While Windows is more like a classic production car – with operating instructions, workshop service and warranty – Linux is reminiscent of a tuned-up mechanic’s car. The vehicle drives, sometimes faster and more elegantly – but only if you know what you are doing.
This is also clearly evident in the corporate environment: Linux admins build their servers with the same dedication as a Star Wars fan builds his Lego Millennium Falcon. Every configuration parameter is carefully considered. Every setting and every alias is an expression of know-how or taste.
This proximity to technology brings with it enormous flexibility. But it comes at a price! At the latest when it comes to systematic System Hardening, i.e. verifiable security, personal preferences and established structures have to give way to a standard. This is often much more difficult than it sounds!
Linux System Hardening: Uniform? Not at all!
While Windows admins can manage many configurations via registry entries, the Linux world is more fragmented: settings are scattered across many files. And depending on the distribution, the ways in which a goal is achieved differ. Especially in heterogeneous environments, the standardization of Linux Hardening becomes a challenge.
In this context, the following questions arise, among others: What influence does the choice of Linux distribution have on the Secure Configuration of a system? And what can an administrator or security expert expect when managing several distributions simultaneously?
The CIS Linux benchmarks: A jumble of specifications and isolated solutions
The benchmarks of the Center for Internet Security (CIS) theoretically provide very good guidance. Unfortunately, however, they are anything but consistent in practice.
🛑 Even with basic topics such as firewalls, it is noticeable that there are completely different recommendations for SUSE than for Ubuntu – even though the protection requirements are identical.
🛑 Even worse are the contradictory rules of the CIS benchmarks for one and the same Linux system. For example, the specifications state “Ensure ufw is installed”, only to demand “Ensure ufw is not installed” a few pages later.
🛑 There is also the inconsistent naming: “Ensure web server services are not in use” sounds completely different to “Ensure apache2 is not enabled”. Both statements mean the same thing, but the wording sounds different.
🛑 A similar case: “Ensure XY is not installed” versus “Ensure XY is not in use”. Same content, different wording. This may be due to historical reasons or originate from different sources, but does not contribute to clarity.
🛑 Titling a rule for XDMCP (X Display Manager Control Protocol) “Ensure XDCMP is not enabled” could be dismissed as a funny twist of letters – but it doesn’t make implementation any easier.
🛑 Sometimes one rule is declared as “manual” – i.e. cannot be automated – and the identical rule in the other benchmark is declared as “automated” – including a bash script.
🛑 What’s more, the bash scripts that are delivered with the CIS benchmarks are rarely ready to use. They have to be adapted and often do not work on multiple systems. This means that the supposed automation quickly becomes a Sisyphean task.
Debian vs. Red Hat System Hardening: The two-tier society of the Linux world
Anyone who wants to harden Linux systems quickly realizes that there are two large camps – Debian (incl. Ubuntu) and Red Hat (incl. SUSE). There is a deep technical divide between them. It starts with the package managers (dpkg vs. RPM) and doesn’t end there.
🛑 The most noticeable difference is the Mandatory Access Controls (MAC). Debian traditionally uses AppArmor, Red Hat relies on SELinux. But regardless of whether SELinux or AppArmor is used, both pursue the same goal, namely fine-grained rights management. Unfortunately, they speak completely different languages.
🛑 These differences are reflected in the CIS benchmarks. Here you can quickly get a feel for which camp a distribution belongs to. Benchmarks for Red Hat-like systems, for example, contain pages and pages of SELinux configurations, while Debian-based systems only talk about AppArmor. This gives the impression that the other security concept does not even exist.
🛑 Anyone who comes up with the idea of hardening their Debian system with SELinux will quickly realize this: There are no compliance points for this – on the contrary. You fail the standard check because AppArmor rules are missing. A securely configured SELinux system should not be rated worse than an AppArmor setup. However, the benchmarks (still?) see it differently.
Debian, Ubuntu, Red Hat and SUSE Hardening: The devil is in the detail
Once the CIS Linux benchmarks have been internalized, the fine-tuning begins. This is where the most treacherous traps lurk. A few examples:
🛑 Not all services are the same! What is called “sshd” on one system is simply called “ssh” on the other. The web server is called “apache2” on one side and “httpd” on the other. If you automate without paying attention to such differences, you suddenly stop ghost services – or forget real services.
🛑 Configuration behavior is even more critical. Modern distributions allow configurations via sshd_config.d, but only some include the directory automatically. Debian does it, SUSE often does not – unless you name it explicitly.
🛑 The result: The option is in the file, but is ignored. The audit script, which searches in the file instead of asking the service with sshd -T, returns a false-negative result – i.e. compliance where there is none. A time bomb!
🛑 At the end is probably the most laborious phase of System Hardening. Microscopic debugging involves comparing man pages, audit logs and distribution wikis, among other things. All this to find out why an audit tool triggers or not.
➡ Speaking of audit tools: Do you already know the free AuditTAP? You can use it to check the Secure Configuration of important and relevant security settings on various Linux and Windows systems.
Between wishful thinking and Linux reality
What can we learn from all these challenges? SUSE, Red Hat, Ubuntu or Debian Hardening in particular and Linux System Hardening in general are not copy-paste projects! They require sound experience, in-depth knowledge of the distributions and a professional, structured approach. You also need a lot of time.
Hardening a Linux system is much faster and easier with Enforce Administrator. The hardening tool supports you in hardening large IT system landscapes sustainably and centrally – always in accordance with the latest benchmarks.
⏬ Download: Enforce Administrator Product Brochure (PDF)
Conclusion
Hardening Linux systems is possible, no question about it. If you have time, patience and in-depth Linux and Hardening expertise, you can achieve a high level of security. But the undertaking is anything but simple.
As soon as several distributions are involved, routine quickly turns into manual work. Different paths, inconsistent benchmarks and sometimes contradictory requirements make standardization a balancing act. The mass of freely available scripts often promises a lot. However, they usually only run on exactly one system with exactly one configuration.
Scalability? Not a chance. If you really want to harden dozens or even hundreds of systems automatically and consistently, you are faced with a mammoth task. It is not enough to roll out a bash script via Ansible! You have to understand, intercept and document the differences.
The best way to achieve your goal efficiently is to use a professional solution such as Enforce Administrator.
Do you have any questions? Want to know more about System Hardening? Contact us – our experts will be happy to help you!
Images: Freepik, FB Pro