Hardening Linux: a 10 step approach to a secure server
The Internet has become a far more dangerous place than it was 20 years ago. Nowadays, Operating System and application security is an integral part of a server configuration and, while firewalls are very important, they are not the panacea.
This list of steps is intended as a guideline with a practical approach. We’ll try to provide a complete picture without getting into unnecesary details. This list won’t replace a good book on secure systems administration, but it will be useful as a quick guide.
Before we get started it’s
worth to mention that security is not a status: it’s just a process.
The correct initial setup of the server only provides a good start and
helps you get half the way through. But you actually need to walk the
other half of the road, by providing proper security vigilance,
monitoring and updating.
These are the ten steps to secure a new installation of a Linux server
(or to improve security in an existing server). We’ll go through them
with some examples and comments:
- Choose a widely used Linux distribution that releases security updates in a timely manner.
It’s not a matter if there will be new vulnerabilities in your Operating System: it’s just a matter of when they will be found. And when that happens you want to be among the first ones to obtain and apply the fix (or the compensatory control, should a fix not be initially available).
And the more people using your distribution, the sooner the vulnerabilities will be found and corrected. The worst thing that could happen to you is a vulnerability only known by a few, with a so called “zero day exploit” being used in the wild.
And avoid exotic or custom configurations as much as possible: standarization is a big advantage. It’s much easier and faster to apply a security fix by just installing a default package through an standard tool (rpm, yast, apt-get, emerge, etc.) than to reconfigure and recompile from source a whole set of applications and libraries.
- Plan the filesystem layout beforehand.
Avoid using a single partition approach. Create, at least different partitions for /, /tmp, /home, /usr and /var. Mount /tmp, /home and /var with, at least, the following options: noexec, nodev and nosuid (why would anybody need to create a device, an executable or, even worse, a setuid executable in these three directories anyway?).
- Don’t install unnecesary packages.
If you don’t have a need for package xyz, just don’t install it. You can always install it later if you find out that you really need it. The more software that you have installed, the more likely you will be impacted by a vulnerability, and the more software you will need to keep up to date.
Avoid compilers and developer tools. Avoid network tools. Avoid packages that have binaries setuid root (some of them are really needed, but don’t get carried away).
- Change default passwords and create regular users
Never forget to review /etc/passwd and /etc/shadow looking for default users. Lock out non interactive accounts (a simple ‘!!’ in the password field in /etc/shadow will do it – for extra protection replace the shell in those accounts by ‘/bin/false’ in /etc/passwd).
Create regular users for normal system administration. Abusing the root account for system administration is not only dangerous but also silly: root mistakes can be very expensive (root can wipe out the whole filesystem with a simple command).
Install and configure sudo. If you need to run anything as root, just precede the command by ‘sudo’. It has the double advantage of making you conscious of running that command as root, and also keeping track (audit trail) of which commands are run as root and by whom.
- Disable unnecesary daemons and network services
Run a ‘ps -ax’ and review each line. Think if you really need that daemon. If you don’t, remove it from the startup scripts and kill it.
Run a ‘netstat -anp’ and see which applications are listening to network ports. Disable all network services that you won’t use.
- Disable remote root logins over ssh
Edit the sshd configuration file (usually /etc/ssh/sshd_config). Make sure that the line ‘PermitRootLogin no’ is present and not commented out. Anyway, you will always login as yourself and use sudo to run commands as root, won’t you?.
- Set up and enable iptables
Configure and enable iptables with a deny by default policy for incoming and outgoing traffic. These are the basic rules that you should have for a web server running on port 80 (use it as a guideline, don’t copy it literally):
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A OUTPUT -i lo -j ACCEPT #accept internal connections
iptables -A OUTPUT -d your_dns_server -p udp—dport 53 -j ACCEPT #DNS/UDP
iptables -A OUTPUT -d your_dns_server -p tcp—dport 53 -j ACCEPT #DNS/TCP
iptables -A OUTPUT —state ESTABLISHED, RELATED -j ACCEPT #established and related connections
iptables -A INPUT -i lo -j ACCEPT #accept internal connections
iptables -A INPUT -p tcp—dport 80 -j ACCEPT #HTTP on port 80
iptables -A INPUT -s your_administration_box -p tcp—dport 22 -j ACCEPT #ssh from your administration workstation
iptables -A INPUT -m state—state ESTABLISHED, RELATED -j ACCEPT #established and related connectionsYou may need extra rules if you are sending your logs somewhere else (a very good idea as nobody will be able to alter the logs, even if the server gets compromised).
An outgoing deny by default policy is almost as important as an incoming deny by default policy. The least thing that you want is to let a hacker use your compromised server as a jumpbox to attack something else. And he will be already inside your network.
- Configure security related kernel parameters
Enable syncookies, disable responses for pings to the broadcast, enable ip spoof protection, disable ICMP redirects and disable source routing. You can do so by adding the following lines to /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0 - Install a host based Intrusion Detection System (HIDS)
If you can afford the effort of walking the extra mile, install an HIDS system. A well known one is Samhain.
Or at least use an integrity verification system like AIDE or Tripwire™ .
But if you feel really corageous, you could improve general Operating System security with Role Based Access Control and multilevel security (as in SELinux or in grsecurity ), but both of these will require kernel patches and substantial modifications to the system.
- Apply the latest updates
Unless you are installing the latest version of a distribution that just came out yesterday (and I would recommend at least waiting a few weeks before installing a new version of any distribution), there are most likely updates available to some of the packages that you’ve just installed. So review the fixes and the caveats, and apply them. And familiarize yourself with this process because you’ll be doing this for the entire life of this server.
Now some tips to a good security conscious approach:
- Never get overconfident: never think that your server is unbreakable.
- Review the logs frequently. Understand what the errors messages and warnings mean.
- Before installing a new application, always evaluate the risk and take a conscious decision of what level of risk is acceptable. Remember that most of the remote compromise holes reside in applications, not in the OS itself.
- Pick widely used applications with good security support and promptly fixes. Install them in a chroot environment whenever possible. Run them using a non-priviledged account (not as root).
- Make backups frequently and keep them outside: they are your last resource.
And above all things: keep yourself updated in security matters (at least regarding the software that you’re running). Spend a few minutes every day reviewing security alerts, they are well worth the effort and the payback is high.