Other Ideas

My next thoughts would be how to keep a close check on the filesystem. You might want to create MD5 checksums of your key files to compare them later if you suspect a compromise. Alternatively, you could install a filesystem integrity check, such as AIDE (Advanced Intrusion Detection Environment), to keep an eye on filesystem changes.

You might also want to configure iptables to catch any services that fire up unexpectedly through either conspiracy or misconfiguration.

Another interesting option for securing your system is port knocking [6]. Port knocking lets you close off your SSH server port to the outside world – switch off pings and make your server completely invisible. Then, the only way to wake up the SSH Server is to connect to a predefined sequence of ports.

If you are offering your users remote access through SFTP, you might want to lock down their access by forcing them to work within their home directories and not to run other system commands. Simply configure an SFTP chroot of sorts [7].

You might also consider employing a tool that automatically examines and locks down your system, reporting on security issues. Tools such as Bastille Linux or Lynis provide this kind of securing auditing service.

The upside of tools like Bastille Linux and Lynis is they speed up the process of security hardening and make it so you don't need to know all of the ins and outs of what you are securing in great detail. The downside is that sys admins become less interested in understanding security at a deeper level and ultimately risk losing the benefits of learning how to secure systems themselves. It's very easy to type Y and accidentally render a system useless if you don't understand exactly what the application is asking you.

It Never Ends

Clearly security isn't just about the server configuration. I could have gone into much further detail about configuring your server and looked at other parts of the network as well. What about checking for dangerous files with setuid permissions? You would only want to allow a select few files to have permissions that mean the user running the file inherits the permissions of the file.

Try tinkering with this command-line example, if I've caused you concern in this regard:

# find / -xdev \( -perm -4000 \) -type f -print0 | xargs -0 ls -hal

With this command we can check which files, on our entire system, are configured with permission 4000 or the SUID bit (which will show up as s in the file's permissions after a directory listing). You can remove any nasty surprises that show the s bit as being present with:

# chmod -s /home/chrisbinnie/nasty_file

To protect my filesystems further, I might consider SELinux at this stage of the build too. I might have also go secret-agent-style and have a peek at the US National Security Agency's recommendations [10].

When putting Apache on this box, I would immediately hide the cgi-bin directory and change the ServerTokens settings to Prod. I also would encourage a quick refresher on hardening Apache by reading the excellent article at the Geekflare site [11].

The never-ending list of security checks simply keeps on going. If you want to read further, look at OpenSCAP from the National Institute of Standards and Technology (NIST) [12]. OpenSCAP works on "automatically verifying the presence of patches, checking system security configuration settings, and examining systems for signs of compromise."

I hope this article has piqued your interest enough to keep on exploring the fascinating side of system security. It is a good idea to build and configure your server systems with a close eye on security if you want to return at a later date and find them working in the same way that you left them.