[featured article] uptime and service reliability, but also because you can implement all three of them, on any number of machines, with some simple automation. Automation is one of the keys to good system security, because it ensures that security policies and checks are implemented uniformly, as scheduled, and helps keep costs down by limiting person-hours spent performing repetitive tasks. Believe me, nobody wants to recompile Apache on a hundred servers when a security update is released! Now that we have discussed how to better maintain security monitoring and apply software updates, let’s discuss some of the aspects of server security that require the human touch. First, I recommend that every hosting company establish a documented policy on how servers should be configured. Start by disabling all the system services that will not be used on the server. Do you use centralized name servers? If so, disable your DNS server. When you go through each entry of the service list, you should also note services that don’t need to be publicly accessible and restrict them only to sources that need access. You should also consider removing software that doesn’t fit into your hosting model (e.g. print servers, IRC clients, unused web server modules), because that lowers the number of applications that you need to maintain and update. Each additional piece of software you leave installed on your system (that isn’t going to be used) creates a pointless security liability. Keep in mind that your policy needs to be constantly updated, as customer needs change. If you suddenly begin seeing demand for a piece of software you don’t have installed you should be prepared to deploy that software to your fleet (using the package management tools discussed above) and make sure it is installed on future machines. Consistency is a primary goal here, because if each of your systems is unique with its own blend of installed software, making good security decisions that apply equally to each of your machines becomes more difficult, if not impossible. Consider this situation: One of your staff members receives a request for a specific software application to be installed on one of your hosting servers. If he (or she) installs an application specifically for one machine, the chance is very low of that software being properly updated in the event a security flaw is discovered. So, now your fleet has a consistent security policy, you are regularly applying security updates on every machine, and you have a solid automated monitoring system. What’s next? A realization that none of these things are any good unless your staff properly utilizes available resources. Anyone working on your systems should thoroughly investigate any potential security situation, and let you know if something is consistently a false positive (so you can make changes to your systems and policies as needed). Vigilant staff can make a huge difference in the use of any of these systems (and likewise can cause any or all of these systems to become worthless). Staff should also be vigilant not only when responding to notifications, but also in their daily tasks. If something doesn’t feel right, it usually isn’t. Strange log messages, console messages, applications acting strangely, and files damaged or out of place, could all indicate a security issue. These things should be investigated and reported. We can’t talk about security without mentioning a few of the pitfalls that are all too common in the web hosting industry. One of the biggest mistakes I still see companies making is shared authentication. If all of your servers share the same password (or, to a lesser degree, utilize a public key authentication token), then a compromise of one of your systems can easily result in the viral compromise of all of your systems. Each system must have unique authentication data, and that authentication data must be changed on a regular basis. I recommend that you cycle authentication data no less than once per calendar month (and every time you experience a system compromise on any server, or lose a staff member). It is also critical that your hosting servers do not have trust relationships with one another, because these interrelationships can also cause a viral compromise in the event one server is compromised. If your servers must trust one another, that trust should be limited to 24 <strong>Ping</strong>! <strong>Zine</strong> <strong>Web</strong> Hosting <strong>Magazine</strong>
www.pingzine.com 25