What configuration hardening checklist will make my server more secure?
Introduction
Any information security policy or standard will include a requirement to use a ‘reinforced construction standard’. The concept of hardening is pretty straightforward, but knowing which source of information to refer to for a hardening checklist when there are so many posts can be confusing.
Server Protection Checklist Reference Sources
The most popular ‘brands’ in this area are the Center for Internet Security or CIS Hardening Checklists (free for personal use), NIST (aka National Vulnerability Database) provided by the Program Repository from the National Checklist or SANS Institute Reading Room articles on hardening the Top 20 most critical vulnerabilities.
All of these groups offer setup hardening checklists for most Windows operating systems, Linux variants (Debian, Ubuntu, CentOS, RedHat Enterprise Linux, aka RHEL, SUSE Linux), Unix variants (such as Solaris , AIX and HPUX) and firewalls and network devices. , (like Cisco ASA, Checkpoint and Juniper).
These sources offer a convenient one-stop-shop for checklists, but you’d better find manufacturer or community-specific checklists for your devices and operating systems. For example, Microsoft and Cisco offer very comprehensive hardening best practice recommendations on their websites, and the various CentOS and Ubuntu communities have numerous secure Internet setup best practice tutorials.
So which checklist is the best? Which setting hardening benchmark is the best and safest? If you consider that all the benchmarks for, for example, Windows 2008 R2 seek to eliminate the same vulnerabilities from the same operating system, you will quickly realize that there is naturally a high degree of similarity between the different sources. In short, they all say the same thing, only in slightly different terms. The important thing is that you assess the risk levels relevant to your systems against the trade-offs you can make in terms of reduced functionality in exchange for increased security.
Strengthening the configuration and management of vulnerabilities
It is important to distinguish between software-based vulnerabilities that require patches to repair and configuration-based vulnerabilities that can only be mitigated. Achieving a safe and reinforced construction standard is really what a hardening program is all about, as it provides a consistent and fundamental level of safety.
Setting hardening presents an exceptionally difficult challenge, as the level to which it can be hardened depends on your environment, applications, and work practices. For example, removing web services and ftp from a host are basic good harness practices. However, if the host needs to act as a web server, then this will not be a sensible hardening measure.
Similarly, if you need remote access to the host over the network, you will need to open the firewall ports and enable the terminal server or ssh services on the host; otherwise these should always be removed or disabled to help protect the host.
By contrast, patching is a much simpler discipline, with a general rule of thumb that the latest version is always the safest (but test it first to make sure it works!).
Configuration hardening procedures
Similarly, patching should be done at least once a month, setting hardening should also be practiced regularly; it is not a one-time exercise.
Unlike patches, where new vulnerabilities in software packages are routinely discovered and then fixed using the latest patches, new vulnerabilities based on configuration are rarely discovered. For example, the CIS Server 2008 Benchmark has only been updated 3 times even though the operating system has been available for almost 5 years. The initial benchmark, version 1.0.0 was released in March 2010 and was later upgraded to version 1.1.0 in July of the same year. Then there was a recent update to version 1.2.0 in September 2011.
However, while new configuration best practices are rarely introduced, it is vital that hardened configuration of your Windows servers, Linux and Unix hosts, and network devices are regularly reviewed because changes can be made at any time that may adversely affect the performance. inherent security of the device.
When you consider that any checklist typically has between 200 and 300 measurements, verifying that all hardening measurements are applied consistently and continuously has to be an automated process.
This can be provided by vulnerability scanning devices like Nessus or Qualys, however these are limited in the range and depth of checks they can perform unless they are granted administrator or root access to the host under test. Of course, doing so actually introduces additional security vulnerabilities, as the host is now accessible over the network and there is at least one more administrator or root account in circulation that could be abused.
Configuration Hardening – File Integrity Monitoring
The other limitation of scanning devices is that they can only perform an instant evaluation of the device in question. While this is a good way to verify device compliance with a configuration hardening best practice checklist, there is no way to verify that the file system has not been compromised, for example by a Trojan or other malware.
Resume
Ongoing file integrity monitoring combined with ongoing configuration hardening assessment is the only true solution to keeping systems secure. While brand checklists, like CIS benchmarks, are an excellent source for strengthening best practices, they are not the only option available. In fact, manufacturer-provided checklists are generally a more specific source of vulnerability mitigation practices. Remember that there can be a wide variety of checklists with different terms and language, but that ultimately there is only one way to strengthen any particular system. Most importantly, you apply the appropriate hardening measures for your environment, balancing risk reduction with operational and functional commitments.