{"id":873,"date":"2017-01-20T00:00:49","date_gmt":"2017-01-19T22:00:49","guid":{"rendered":"https:\/\/community.virtono.com\/?p=873"},"modified":"2017-01-24T19:35:01","modified_gmt":"2017-01-24T17:35:01","slug":"hardening-linux","status":"publish","type":"post","link":"https:\/\/www.virtono.com\/community\/knowledgebase\/hardening-linux\/","title":{"rendered":"Hardening Linux:OS Hardening Principles"},"content":{"rendered":"

Hardening Linux and Using iptables<\/strong><\/p>\n

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<\/span> firewall at all.<\/p>\n

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.<\/p>\n

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!)<\/p>\n

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.<\/p>\n

OS Hardening Principles<\/strong><\/p>\n

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!<\/p>\n

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.”\u00a0However, it scales very well to most other information security endeavors, including system hardening.<\/p>\n

Another concept originally forged in a somewhat different context is the Principle of Least Privilege. This was originally used by the <\/a>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<\/a>).<\/p>\n

Nowadays people often extend the <\/a><\/a>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<\/span>, in my opinion). As they apply to system hardening, the real work stems from these corollaries:<\/p>\n