5 tips for getting started with Linux server security

Security is a popular topic among Linux system administrators. Every forum I read, every conference I attend, and every IT-centric discussion I'm part of always turns to security, and then the conversations turn, inevitably, to Linux security. This is my experience, and my inability to keep from eavesdropping on tech conversations about Linux is the origin of this article. These are my five recommendations for starting with a more secure Linux installation right out of the box.

[Want to try out Red Hat Enterprise Linux? Download it now for free.]

Keep it minimal

When I install Linux, I always install the smallest version possible. For CentOS or Red Hat Enterprise Linux, this means a minimal installation. I prefer to start small and then add what I need rather than to remove what I don't need. The added benefit to selecting a minimal install is that the system's footprint is also minimal. Disk space is cheap, but who wants to waste disk space on superfluous applications that might come back to haunt us later with security issues? All I need initially is a base install with an SSH server so that I can connect to it and manage it remotely. I can add whatever I need through DNF later.

Servers are GUI-free zones

If your Linux system will live life as a server, don't install a graphical user interface. Several people argue this point. From a security standpoint, installing a GUI—even a small one—requires a lot of extra software packages. Any of these could be susceptible to security problems. Some GUI packages can open ports on your system, which is undesirable because that action increases the attack surface. Finally, your system's performance might (will) suffer from having a graphical interface, because GUIs consume a lot of system resources.

Leave the GUIs to the desktop. Learn the command line.

Firewalls are mandatory

On Red Hat-based systems (Red Hat Enterprise Linux, Fedora, and CentOS), firewalld is your default firewall. Use it. This host-based firewall protects your system from unwanted intrusions through all port, except for those you have explicitly allowed. You can also selectively limit outgoing traffic through the firewall.

However, the most secure method for limiting outgoing traffic is to have an internal internet proxy server set up, and only allow outgoing traffic to that system. You can also allow SSH traffic to your local subnet in case you need to connect from one system to another. Host-based firewalls can be frustrating when testing connectivity between systems, especially for newly configured services, but it's well worth the few moments of frustration. Hang a sign just above your monitor(s) in your cubicle that reads, "CHECK THE FIREWALL," and you'll be fine.

SELinux is worth learning

Ah, the much-loathed and misunderstood SELinux. Typically, system administrators disable or remove SELinux altogether rather than dealing with the extreme security-enhanced angst that it produces. My advice is to leave this service on, enabled, and set to enforcing.

SELinux uses what's known as mandatory access control (or MAC), whereas firewalls use rules-based access control, and the standard *nix permissions are known as discretionary access control. Before giving up and disabling SELinux, please read some documentation on its configuration. Since most systems only run a small set of services, configuring is not that big of a hassle as opposed to the danger of not having this service enabled.

SELinux has to be set up in a particular way, allowing files to be labeled, set up in security contexts, and rebooted a couple of times to get things going. Read the documentation. SELinux, contrary to popular belief, is NOT a firewall (or a replacement for one), an anti-malware solution, a replacement for authentication mechanisms such as multi-factor authentication, or a security panacea by any stretch of the imagination.

SELinux is a defense against privilege escalation from services that run as the root user. Turning it off is probably is a bad idea. Using SELinux correctly is an added layer of protection needed in these days of advanced persistent threats and smarter malware.

Remote root logins are a bad idea

By default, on Red Hat-based systems, the root user may log in remotely via SSH. I can understand why this feature is set by default on newly installed systems, but it should be disabled once the system is up and operable, and accounts with sudo access have been created.

Disabling remote root login prevents an attacker from using brute force methods to guess your root password. Attempts are logged but will have no effect on your security because the root account cannot log in remotely. And if you have an intrusion prevention script or service installed, repeated attempts automatically result in a new DROP rule or the creation of an /etc/hosts.deny entry.

Check to see if remote root logins are enabled:

$ sudo grep -i root /etc/ssh/sshd_config

PermitRootLogin yes
# the setting of "PermitRootLogin without-password".
#ChrootDirectory none

If you see PermitRootLogin yes, then the root user can log in remotely via SSH. Edit the /etc/ssh/sshd_config file and place a # to comment out the line, or change yes to no. Restart the sshd service to accept the new configuration:

$ sudo systemctl restart sshd.service

The root user will no longer be able to log in via SSH.

Wrapping up

Read any survey for the past ten years and you'll see that security is the top priority or concern for system administrators. Make it your priority to secure a system with at least these five tips before your systems go live into production. Security is not something you can put off or relax on. These five tips will help you bring a more secure system online and make your network a safer place to work.