Search

Simple Server Hardening

These days, it's more important than ever to tighten up the security on
your servers, yet if you were to look at several official hardening
guides, they read as though they were written for Red Hat from
2005. That's because they were written for Red Hat in 2005
and updated here and there through the years. I came across one of these
guides when I was referring to some official hardening benchmarks for
a PCI audit and realized if others new to Linux server administration
were to run across the same guide, they likely would be overwhelmed with
all of the obscure steps. Worse though, they likely would spend hours
performing obscure sysctl tweaks and end up with a computer that was no
more protected against a modern attack. Instead, they could have spent a
few minutes performing a few simple hardening steps and ended up with a
more secure computer at the end. So in this article, I describe a
few hardening steps that provide the most bang for the buck. These tips
should take only a few minutes, yet for that effort, you should get
a much more secure system at the end.

Classic Hardening

Before I talk about some hardening recommendations, I figured I'd start
by highlighting some of those classic security steps you are likely
to see in those older hardening guides. Now this isn't to say that all
of these steps are necessarily bad advice, it's just that in many cases
the advice refers to deprecated systems or describes steps
that modern Linux server distributions have taken by default for years.

For instance, many hardening guides spend a lot of time focusing on
tcpwrappers, a classic Linux service that lets you restrict which IPs can
access particular services. These days, most administrators use iptables
firewall rules to restrict access to ports instead. You also will be
advised to enable the use of shadow passwords and to disable shells on
common role accounts (like the mail, bind, www and mysql users). Although
that isn't bad advice, the fact is that all Linux distributions already
do this for you out of the box.

Another tip you usually will see in a hardening guide is to disable
all unnecessary services, and in particular, the guides will tell you to
disable telnet, daytime, chargen and a number of other obscure inetd
services that not only haven't been turned on by default in a long time,
but in many cases they also aren't even installed by default anymore. The fact
is that most server distributions ship with all network services apart
from SSH turned off. Speaking of SSH, now that I've talked a bit about
some classic hardening tips, let me discuss a few modern hardening tips
starting with SSH.

SSH

As I mentioned, just about every server you will encounter turns on SSH by
default,
and there is an assumption that you will use it for remote administration. Here
are a few simple changes you can make to your /etc/ssh/sshd_config file
that take only a second but make it more secure.

First, disable root logins and make sure that you use only SSH protocol 2
(previous protocols have known vulnerabilities). In many distributions
(in particular many cloud images), these steps already may be done for you:

PermitRootLogin no
Protocol 2

A lot of people focus way too much, in my opinion, on SSH brute-force
attacks when they talk about server hardening. It's true that if you
put a Linux server on the internet, one of the first things you will
see in your logs is a steady stream of SSH brute-force attempts. Many
sysadmins go to lengths that I think fall somewhere between ineffective,
absurd and overkill, including moving SSH to some random port (security
by obscurity) or using a system like fail2ban. With fail2ban, your system
reads failed login attempts and creates firewall rules to block attackers
after a few failed attempts. This seems sensible on the surface, but it
has a few problems:

This stops only attackers who have one machine—most have botnets and
spread brute-force attacks across many IPs.

If you have a weak, easily guessable password and a common user name,
they might guess the password before fail2ban kicks in.

Usually internal networks are whitelisted—attackers still can brute-force
attack you from a different compromised machine on your network.

Instead of going through all of those steps to mitigate SSH brute-force attacks, I recommend that you eliminate the attack entirely:
disable password authentication and rely on SSH keys only. Before you
enable this option, be sure that everyone who logs in to this machine
(or at least the administrators) have generated and tested logging in
using SSH keys—you wouldn't want to get locked out. When you are ready,
change the PasswordAuthentication parameter in your sshd_config to:

PasswordAuthentication no

The final quick SSH hardening step is to restrict which cryptography
cipher suites and algorithms to use, so that you use only the ones that are
considered to be safe by today's standards. I'm no cryptographer, but I
don't have to be one to look at the recommendations from cryptographers and
copy and paste them into my SSH config:

Once all of these settings are in place, restart the SSH service to use them.

Account Hardening

For general hardening of the system accounts, the best recommendation
I can make is to disable the root account altogether and use
only sudo. You also should avoid direct login to any shared
accounts, whether
it's the root account or some role account like a user that manages your
application or web server. By requiring users to log in as themselves
and then sudo up to root or role accounts, you provide a nice audit trail
for who did what, and you make revoking access simpler when users no
longer need an account—since the shared accounts won't have a
password,
you don't have to change them every time a member of the team leaves;
instead, you can just remove that user's account.

Most distributions currently include sudo, and some also either
disable the root account by default or allow you to disable it during
installation. Otherwise, you simply can edit your /etc/shadow file and
replace whatever password you have in place for the root user with a *
symbol. Just make sure you do have sudo working first with at least one
account so you don't lock yourself out.

When using sudo there are a few practices you should follow to help
keep it secure. First, while the use of NOPASSWD sudo rules (rules
that don't require you to enter a password) are somewhat unavoidable for
dæmons that may run cron jobs like backup jobs, you should restrict any
NOPASSWD sudo rules to just those dæmon role accounts and require all
real users to type in a password. As much as possible, you also should
follow the principle of least privilege and grant users sudo access
only to the specific commands they need instead of granting them access to run
all commands as a particular user (especially the root user). Finally, if
you find yourself granting users access to a general-purpose command to
do something specific (like granting them access to service or systemctl
so they can restart just one service), consider creating a simple shell
script that runs the command with only the specific parameters you want
and granting them sudo access to that script instead.

Although these hardening steps aren't the only things you should do
to lock down your server, they are a good start and should take
only a few minutes. In my next article, I'll add another round of simple
hardening tips, including SSH client hardening and cloud hardening steps,
and I'll finish up with some general-purpose recommendations.

Kyle Rankin is a Tech Editor and columnist at Linux Journal and the Chief Security Officer at Purism. He is the author of Linux Hardening in Hostile Networks, DevOps Troubleshooting, The Official Ubuntu Server Book, Knoppix Hacks, Knoppix Pocket Reference, Linux Multimedia
Hacks and Ubuntu Hacks, and also a contributor to a number of other O'Reilly books. Rankin speaks frequently on security and open-source software including at
BsidesLV, O'Reilly Security Conference, OSCON, SCALE, CactusCon, Linux World Expo and Penguicon. You can follow him at @kylerankin.