Source: Security Focus
Linux Kernel Hardening
by Anton Chuvakin, Ph.D.
last updated January 23, 2002
--------------------------------------------------------------------------------
This article will cover the issues of Linux hardening, with a specific focus on kernel hardening and its use on production systems. Several kernel-hardening approaches and their usability will be analyzed.
Is Linux secure? The question is much less useful, than 'Is Linux "securable"?' The answer to the latter is a definite yes. Being securable means that Linux can be made more secure (to whatever degree necessary) by applying a clearly defined sequence of steps that always produces the same result, and that can be automated and applied to systems that have been in operation for a long time. It would be ideal to be able to make securing systems understandable by regular system administrators who don’t have formal security training. However, the last requirement might be pushing it a bit, since security will likely always require expertise.
Linux can be made more secure by hardening the system. It is beyond the scope of this article to discuss system hardening; however, there are a number of system hardening resources available, such as:
There are also utilities available, such as Bastille linux. The latter automate the hardening process with detailed explanations on each step. Hardened Linux distributions such as EnGarde Linux and Immunix are also available. Typical steps that are taken during the system hardening include:
- Minimizing installed software
- Patching the system
- Securing filesystem permissions and S*ID binaries
- Improving login and user security
- Setting some physical and boot security controls
- Securing the daemons via network access controls
- Increasing logging and audit information
- Configuring vendor supplied security software (IDS, host firewall)
It is curious to note that hardening is not just a matter of fixing bad defaults the vendors throw at users. It is believed that vendors ship systems with mostly open default setting based on customer feedback. Thus hardening should be viewed not as "fighting the evil vendor", but rather as optimizing the system based on local business and security needs.
Hardening is also a great example of defense in depth. Such a Linux system will be much harder to crack and utilize for nefarious purposes. There are examples of Linux servers running for years without a successful penetration and with no firewall. Their reliability is due to a professionally hardened OS.
However, system hardening appears to be lacking in several aspects. For example, buggy SUID programs and network application will still give the attacker root and user access. If attacker gets "root", there is positively no way to stop them from anything on a normal Linux system. In addition, basic Unix access controls will not stop authorized system users from doing various bad things (port scanning, accessing unauthorized resources, running password crackers or banned network applications), which cannot be prohibited using ‘access control’ without rendering the system unusable. And while hardening, improved logging, audit and intrusion detection will complicate rootkit deployment by attackers, kernel-level rootkits can easily overcome those preventive measures.
To combat these threats, kernel hardening is needed. Kernel hardening can be defined as enabling additional kernel-level security mechanisms to improve the security of the system, while keeping system close to traditional Linux. What are some approaches to kernel hardening? Current Linux kernel security can be tightened a bit without adding any new features or patches. One can compile the kernel with no module support (in this case, most kernel rootkits cannot function) and some security-related kernel options can be turned on.
The full article can be wieved here.
