Sysadmin blog Most Linux distributions have a significant focus on security. This does not mean they are necessarily ready for production out of the box. Tools like SELinux, excellent firewall options, and robust access controls can make Linux exceptionally secure. Despite this, actually deploying a Linux system into production still requires that the systems administrator have some idea what they are doing.
Let’s use my favourite distribution, CentOS, as an example. (CentOS is a near-identical repackaging of Red Hat Enterprise Linux.) By default, SELinux is turned on. In most situations, this is a great thing; SELinux provides a layer of sandboxing so that applications of a certain class can’t impinge upon files belonging to applications or users of another class.
SELinux serves as a layer of security beyond the traditional access controls built into the rest of the distribution. In my experience, the primary use for SELinux is preventing a compromised web application from clobbering the rest of the server. Unfortunately, many packages and web applications are still outright incompatible with SELinux.
While an excellent default option, much of the advice a novice Linux administrator will encounter when trying to get something working involves simply disabling SELinux. In order to subsequently achieve the same level of security for the web applications that were the most likely reason to disable SELinux, they now have to know the ins and outs of various Apache extensions such as mod_security.
Unfortunately, tools to easily and comprehensively lock down Apache are not part of the default CentOS distribution. This often means tutorials, manuals and editing config files. None of it is particularly hard, but it can be intimidating to a rookie, particularly given the typical internet FUD surrounding the every-so-scary command line. For pain reduction, I recommend Webmin for experienced admins and first timers alike.
CentOS ships with the firewall on by default, configured to allow only DNS and SSH through. Unfortunately the SSH server is configured to run on the default port (22) and allow root to log in. SSH running on the default port is a bad plan. Toss a monitoring program on any external IP, and within minutes port 22 lights up like a Christmas tree.
Ideally, you never log on as root; you should have a non-administrative user handy. The SSH daemon needs to be configured to disallow root access and the port changed to something somewhere above 1024. Naturally the firewall opening will have to be changed as well.
Bizzarely, CentOS doesn’t include Fail2Ban in the default repository. Fail2Ban scans the secure logfile to detect attempted brute force attacks and bans offending IP addresses. To gain access to this package, we must enable the EPEL repository, and do a little bit of work.
CentOS doesn’t have any default activated anti-malware applications. Far from being immune to compromise, Linux systems, especially those hosting web servers while improperly configured, can indeed play host to some pretty nasty pieces of software. My preferred front line defences are the ever popular ClamAV and LMD. LMD is not in any of the basic CentOS repositories, and also requires a little bit of work to get installed.
DDOS Deflate is another favourite. A useful script run as a scheduled Cron job, DDOS Deflate helps to block denial of service attacks. Unfortunately, it is another tool not included in the default repositories.
In addition to the above basic precautions, there are the standard sorts of system hardening that apply to any operating system to consider. You will inevitably find services activated by default that probably have no use for your deployment.
Disabling these, as well as unnecessary users and even kernel modules for services, (such as wireless or FCoE,) can also help lower your attack surface with minimal effort. Certain scripts have been written to help ease the burden of system hardening. Most popular amongst these is Bastille. While Bastille can help with some of the basic hardening, there are always some elements of a secure deployment that are simply reliant on the systems administrator’s experience.
As with Windows, OSX, or any other operating system, care and attention is still required before letting a Linux system loose into production. Fortunately for novice Linux admins, it isn’t as hard as it is often made out to be, and the internet is filled with resources designed to help.