Securing Web Server Software
To some extent, an organization deploying a third-party web server product is inevitably placing its fate in the hands of the software vendor. Nevertheless, there is still a large amount that a security-conscious organization can do to protect itself against the kind of software vulnerabilities.
Choose Software with a Good Track Record
Not all software products and vendors were created equal. Taking a look at the recent history of different server products reveals some marked differences in the quantity of serious vulnerabilities found, the time taken by vendors to resolve them, and the resilience of the released fixes to subsequent testing by researchers. Before choosing which web server software to deploy, you should investigate these differences, and consider how your organization would have fared in recent years if it had used each kind of software you are considering.
Apply Vendor Patches
Any decent software vendor must release security updates periodically. Sometimes, these address issues that the vendor themselves discovered in-house. In other cases, the problems were reported by an independent researcher, who may or may not have kept the information to herself. Other vulnerabilities are drawn to the vendor’s attention because they are being actively exploited in the wild. But in every case, as soon as a patch is released, any decent reverse engineer can quickly pinpoint the issue that it addresses, enabling attackers to develop exploits for the problem. Wherever feasible, therefore, security fixes should be applied as soon as possible after they are made available.
Perform Security Hardening
Most web servers have numerous configurable options controlling what functionality is enabled and how it behaves. If unused functionality, such as default ISAPI extensions, is left enabled, then your server is at an increased risk of attack in the event that new vulnerabilities are discovered within that functionality. You should consult hardening guides specific to the software you are using, but here are some generic steps to consider:
■ Disable any built-in functionality that is not required, and configure the remaining functionality to behave as restrictively as possible consistent with your business requirements. This may include removing mapped file extensions, web server modules, and database components. You can use tools such as IIS Lockdown to facilitate this task.
■ Many functions and resources that you need to retain can often be renamed from their default values to present an additional barrier to exploitation. Even if a skilled attacker may still be able to discover the new name, this obscurity measure will defend against less skilled attackers and automated worms.
■ Apply the principle of least privilege throughout the technology stack. For example, the web server process should be configured to use the least powerful operating system account possible. On Unix-based systems, a chrooted environment can be used to further contain the impact of any compromise.
Monitor for New Vulnerabilities
Someone in your organization should be assigned the task of monitoring resources such as Bugtraq and Full Disclosure for announcements and discussion about new vulnerabilities in the software you are using. You can also subscribe to various private services to receive early notification of known vulnerabilities in software that have not yet been publicly disclosed. Very often, if you know the technical details of a vulnerability, you will be able to implement an effective work-around pending release of a full fix by the vendor.
Use Defense-in-Depth
You should always implement layers of protection to mitigate the impact of a security breach within any component of your infrastructure. There are vari- ous steps you can take to help localize the impact of a successful attack on your web server. Even in the event of a complete compromise, these may give you sufficient time to respond to the incident before any significant data loss
occurs:
■ You can impose restrictions on the web server’s capabilities from other, autonomous components of the application. For example, the database account used by the application can be given only INSERT access to the tables used to store audit logs, meaning that an attacker who compromises the web server cannot delete any log entries that have already been created.
■ You can impose strict network-level filters on traffic to and from the web server.
■ You can use an intrusion detection system to identify any anomalous network activity that may indicate that a breach has occurred. After compromising a web server, many attackers will immediately attempt to create a reverse connection out to the Internet, or scan for other hosts on the DMZ network. An effective IDS will notify you of these events in real time, enabling you to take measures to arrest the attack.
