It is often said that the only manner in which a server can be secured would be to disconnect it and power it off. Kevin Mitnick, a rather well known Cyber Security Analyst, has gone so far as to add that all I/O devices should be removed from the hardware and the server should be buried in concrete. Such a solution is quite comprehensive to say the least, and will most certainly ensure that the data on your server is available to not even the most clever of attackers. Sadly however, this solution does not allow for such amenities as high availability or customers. To make matters all the more frightening, information security is an extremely expansive topic. So much so that for each application, programming language, operating system, or hardware device there exists entire volumes dedicated to known attack vectors and what you can do to prevent allowing them in your environment. Therefore, to keep matters concise and relevant the scope of this article is confined to web hosting, and more specifically (as other articles will be forthcoming) protecting root access in a Linux based web hosting environment.
It is not entirely uncommon to draw analogies between Chess and Information Security, and in Linux-based web hosting root level access is most aptly represented by the King. Furthering the analogy, how effectively you can protect your king is decided in no small part by how well you decide upon the first few moves. Attempting to retroactively add security to a live production environment is going to provide you with a plague of problems, so starting off right is absolutely crucial to protecting your interests.
Okay, so enough rhetoric; How do we do this? Starting off, letâ€™s assume that we are on a brand new server with a fresh operating system and control panel installed. It is of no small note that all packages should be up to date, as a good deal of software updates serve to close off security gaps that were left open in previous versions. In RedHat based systems such as the exceptionally common CentOS, you can list ALL of your packages via the following command:
Of course, you are going to want to know who needs an update; Doing so will require adding but a single word:
yum list updates
This will show you the entire list of packages that have updates in their respective repositories. Once you gather this information, you can update everything at once with the following:
Although by far the quickest, this can be cause for trepidation considering that any bugs or issues that are introduced during a bulk update such as this can be quite a pain to track down. For a more granular approach, you can update individual packages like so:
yum update package_name
This allows you to check functionality between updates, reducing the possibility of a surprise bug being caused by any one of the 150 updates that you just performed in a single command. Debian based systems donâ€™t use yum and rpm, but rather use apt-get and dpkg somewhat analogously. For instance, you can update all of your packages in Debian servers not unlike with yum:
For individual packages, you would just install them (which, if already installed, is the same as an update):
apt-get install package_name
There are many different *nix distributions, and many of them have unique package management systems. If you are using something less conventional such as Suse or BSD you will want to look into exactly what is required, however the point remains that all packages should be up to date to minimize potential attack vectors for your system.
Making sure that all of your serverâ€™s packages are up to date is a large portion of the process, but we are nowhere near complete. Next we will take a look at installing a SPI (Stateful Packet Inspection) Firewall program, namely CSF.
- Hardening Your Hosting Environment (without killing yourself) Step 1: Updates
- Hardening Your Hosting Environment (without killing yourself) Step 2: The Firewall
- Hardening Your Hosting Environment (without killing yourself) Step 3: SSH Obfuscating