“Linux is a secure OS.”
You’ve probably heard this statement from time to time, and compared to Windows you could argue that it is. But really it’s kind of a meaningless statement: no system which is connected to a network or used by human beings is completely secure, and if it was it would probably be useless.
But you can certainly beef up the security of a given Linux system to make it more secure than it would otherwise be – while still enabling it to do its job – and it’s that process, known as hardening, that is the subject of this article. Without going in to the finer details, we’ll be looking at the general steps you should take to harden any system under your control that warrants extra security beyond what you believe is necessary for your “normal” systems.
Before you can start the process of hardening a given system you need to have a clear idea of what they system is to be used for, what software it will therefore need to run, and the sorts of threats or vulnerabilities you want to protect against.
1. Start From Nothing
It’s only possible to harden a system from a known secure state, and in practice this means starting from scratch with a bare system. This means you have the opportunity to partition the system’s disk however you like, and it’s a prudent security measure which costs nothing to separate the OS files from all the other data you’ll be putting on it.
The next step is to configure a minimum install to get the system booted, and add in the extra packages you need to enable to the system to do the job you want it to. Why a minimum install? Because the less code on your machine, the less vulnerabilities there are waiting to be exploited: you can’t exploit what isn’t there. You’ll also need to apply any security patches to the OS, or any of the packages running on it.
At this point it is worth noting that all the patching in the world is pointless if a potential attacker can get physical access to the machine – he could simply pick it up and walk off with it. So part of the process of hardening a server involves placing it in a secure environment. It’s also possible that a more stealthy intruder who gains physical access to the server could boot the server from a CD-drive or other device and then browse, modify of steal any data the OS he boots into could see. (Booting a Windows server from a Linux CD is a classic way of gaining access to passwords in the supposedly secure Windows SAM database.) So it’s wise to configure the system’s BIOS to restrict booting to the system’s internal hard drive, and to lock the BIOS and boot loader down with a strong password.
The next thing is to compile your own kernel, again including only the parts that you really need. Once your custom kernel is built and installed and you reboot into your kernel, you have a running system with a limited attack surface. But there are still plenty of ways to harden it further – the fun has only really just begun …
2. Pare Down Services
With a running, slimmed down system, the next step is to make sure that only the system services you really need are running. Most will have been weeded out by now, but it’s still likely that some will still be running in the background. You’ll have to track them down by looking in the various locations like /etc/init.d and /etc/rc.d/rc.local that hold boot scripts for various daemons, checking anything launched by cron, and so on. You can also check what services are listening on sockets using netstat or even a port mapper like Nmap.
Some of the services you should look at disabling if they are running (unless you specifically need them) include:
- Network file systems e.g. samba
- Printing services e.g. cups
- Mail services e.g. pop, imap, sendmail
- Remote access daemons e.g. telnetd, ftpd, rlogind
- X (window system)
Of course there’ll be some services that you will wish to allow, and one way to limit the amount of potential damage they could do to the rest of the system is to run them in their own chroot jails when possible so that they are isolated from the rest of the file system.
3. Consider Permissions
Mirroring the old spy diktat about “need to know”, you can also harden your file system by ensuring that no user is given the power to do anything that is not strictly necessary. You can do this by performing an audit and reducing permissions for each file to the minimum possible, and ensuring that group permissions reflect the make-up of your groups. Ultimately, the aim is that no-one should be able to read or write files that they have no business to. You should also probably encrypt any particularly sensitive data.
The logical continuation of this is to make sure no-one can get access to accounts that they shouldn’t by ensuring you have a secure root password known by as few administrators as practical, that other user credentials are up to date, and that policies like password expiry periods are adhered to. It’s also very wise to remove any predefined accounts provided with default passwords, or to change the default passwords at the very least.
As had been said many times before, security is a process not a job. This means that to keep a machine in a hardened state it’s vital that you keep watching and hardening it further when necessary. To do this you’ll need to monitor the system and its logs, apply any patches in a timely fashion, and keep up with security news so you can deal with any vulnerabilities as soon as they become known. And remember that this article is not an exhaustive checklist – just a series of pointers to areas where there are opportunities to harden your systems.
There are always more steps you can take which will make your Linux system more secure and less productive. The key, as ever, is finding the right balance.