Hardening Linux:OS Hardening Principles

Hardening Linux and Using iptables

There’s tremendous value in isolating your bastion (Internet-accessible) hosts in a DMZ network, protected by a well-designed firewall and other external controls. And just as a good DMZ is designed assuming that sooner or later, even firewall-protected hosts may be compromised, good bastion server design dictates that each host should be hardened as though there were no firewall at all.

Obviously, the bastion-host services to which your firewall allows access must be configured as securely as possible and kept up to date with security patches. But that isn’t enough: you must also secure the bastion host’s operating-system configuration and disable unnecessary servicesin short, “bastionize” or “harden” it as much as possible.

If you don’t do this, you won’t have a bastion server: you’ll simply have a server behind a firewallone that’s at the mercy of the firewall and the effectiveness of its own applications’ security features. But if you do bastionize it, your server can defend itself should some other host in the DMZ be compromised and used to attack it. (As you can see, pessimism is an important element in risk management!)

Hardening a Linux system is not a trivial task: it’s as much work to bastionize Linux as Solaris, Windows, and other popular operating systems. This is a natural result of having so many different types of software available for these OSes, and at least as much variation between the types of people who use them.

OS Hardening Principles

Operating-system hardening can be time consuming and even confusing. Like many OSes designed for a wide range of roles and user levels, Linux has historically tended to be “insecure by default”: most distributions’ default installations are designed to present the user with as many preconfigured and active applications as possible. Therefore, securing a Linux system not only requires you to understand the inner workings of your system; you may also have to undo work others have done in the interest of shielding you from those inner workings!

Having said that, the principles of Linux hardening and OS hardening in general can be summed up by a single maxim: “That which is not explicitly permitted is forbidden.” However, it scales very well to most other information security endeavors, including system hardening.

Another concept originally forged in a somewhat different context is the Principle of Least Privilege. This was originally used by the National Institute of Standards and Technology (NIST) to describe the desired behavior of the “Role-Based Access Controls” it developed for mainframe systems: “a user [should] be given no more privilege than necessary to perform a job” (http://hissa.nist.gov/rbac/paper/node5.html).

Nowadays people often extend the Principle of Least Privilege to include applications; no application or process should have more privileges in the local operating environment than it needs to function. The Principle of Least Privilege and Ranum’s maxim sound like common sense (they are, in my opinion). As they apply to system hardening, the real work stems from these corollaries:

• Install only necessary software; delete or disable everything else.

• Keep all system and application software painstakingly up to date, at least with security patches, but preferably with all package-by-package updates.

• Delete or disable unnecessary user accounts.

• Don’t needlessly grant shell access: /bin/false should be the default shell for nobody, guest, and any other account used by services, rather than by an individual local user.

• Allow each service (networked application) to be publicly accessible only by design, never by default.

• Run each publicly accessible service in a chrooted filesystem (i.e., a subset of /).

• Don’t leave any executable file needlessly set to run with superuser privileges, i.e., with its SUID bit set (unless owned by a sufficiently nonprivileged user).

• In general, avoid using root privileges unnecessarily, and if your system has multiple administrators, delegate root‘s authority via sudo.

• Configure logging and check logs regularly.

• Configure every host as its own firewall; i.e., bastion hosts should have their own packet filters and access controls in addition to (but not instead of) the firewall’s.

• Check your work now and then with a security scanner, especially after patches and upgrades.

• Understand and use the security features supported by your operating system and applications, especially when they add redundancy to your security fabric.

• After hardening a bastion host, document its configuration so it may be used as a baseline for similar systems and so you can rebuild it quickly after a system compromise or failure.

All of these corollaries are ways of implementing and enforcing the Principle of Least Privilege on a bastion host.