Eighteen years after its initial release, the Apache HTTP Server software is by far the most dominant Web server on the Web, as it has been for more than a decade. While this is an impressive feat, its large (more than 50%) share of the Web server market makes Apache a popular attack target.
To combat these problems, the most recent versions of both Apache HTTP and its add-ons should be used; keeping the HTTP server up to date is absolutely critical.
The latest high-profile attack aimed at Apache was uncovered by researchers at security firms ESET and Sucuri. Attackers managed to work a backdoor into Apache that redirected Web traffic to malicious websites, where visitors would be infected by the Blackhole exploit kit. This attack underlined the need for organizations to enact Apache security best practices and highlighted the serious fallout that can be caused by insecure Apache Web servers.
In this tip, we'll provide the best practices needed to secureApache servers against modern attacks.
Apache security basics
In many cases, Apache server compromises are the result of outdated modules, configurations or even Web code hosted by the Web server. To combat these problems, the most recent versions of both Apache HTTP and its add-ons should be used; keeping the HTTP server up to date is absolutely critical. However, the current trend among attackers is to focus on external component frameworks, modules and add-ons that open up Apache HTTP to attacks to which it would not otherwise succumb. Keeping track of these new components is half the battle; the other half is ensuring that these packages are updated with patches and new versions as they become available. As always, remember to double check the source of a download when updating; clever attacks often try to disguise malware as a benign software update.
Beyond ensuring that updates are applied, organizations should also configure Apache HTTP Server to minimize the attack surface. While this may sound simple, there are dozens of considerations that only the system administrator can make (usually in collaboration with the Web developer). For example, a current trend with distributed denial-of-service attacks is to consume system resources while using the least amount of traffic possible. The effect of such an attack can be minimized by configuring parameters such as RequestReadTimeout, TimeOut, KeepAliveTimeout and MaxRequestWorkers to values that cut down on resource consumption. (More information about this can be found on Apache's website.) Other considerations for system administrators should include the following:
- Run HTTPd using an account with restricted privileges. Doing this will minimize the impact to the overall system, should an attacker manage to compromise the daemon itself.
- Deny the use of .htaccess files by configuring the AllowOverride parameter to None. This will ensure that htaccess files cannot be used.
- Configure mods such as mod_python and mod_php to use safe mode. Use this where it makes sense, but it may not be necessary in newer versions.
- Lock down the file system so that only root can overwrite the Apache binary. Doing this will prevent the httpd binary from being replaced with a malicious version.
Monitoring for Apache attacks
From the editors: More on Web server security
Learn how to deploy strong encryption in a Web server environment
Secure DNS resolvers are key to stopping amplified DDoS attacks
Even after putting protections in place to defend Apache servers, organizations must still be wary of attacks slipping through the cracks and wreaking havoc.To ensure that attacks don't go unnoticed, organizations should monitor their logs closely for signs of compromise. Enable a level of logging that makes sense both for HTTPd at a system level and with the Web daemon internally. A bash or python script can be easily constructed that will search the logs for certain terms, or the built-in syslogd command can be used to alert admins to potential errors or attacks. Effective monitoring and alerting requires a firm understanding of the content being served. Some content, such as use of LDAP for authentication, may behave in ways that would cause a less dynamic Web server to generate alerts. If your server is trying to use LDAP while the Web application is designed to use local authentication, there may be cause for alarm. Disabling mod_php may allow organizations to exclude attacks of that type from alerts, thus making real alerts that much more meaningful. For Web servers facing a high risk of attack, consider enabling mod_log_forensic to get an even more in-depth view of client requests.
High-risk Web servers also have the most to gain from enabling mod_security, though all systems can gain some benefit. This module opens the door to a variety of tools that can be utilized to both detect and prevent attacks. You can choose to integrate this into your existing enterprise security model through IPS, IDS, NIDS and SIEM systems. mod_security has the ability to act like a Web application firewall, which is invaluable when serving Web applications that may not have the best input filtering.
By enacting these basic measures, it is possible to confidently secure Apache HTTP server and serve content with minimal risk of compromise. One of the most important parts of operating a secure system is keeping abreast of the latest security risks and software releases. Doing this, along with practicing diligent monitoring, will go a long way toward keeping your Apache instances secure.
About the author:
Brad Causey is an active member of the security and forensics community worldwide and tends to focus his time on Web application security as it applies to global and enterprise arenas. He is a member of the OWASP Global Projects Committee and the President of the International Information Systems Forensics Association chapter in Alabama. Brad is an avid author and writer with hundreds of publications and several books. Brad also holds dozens of industry recognized certificates such as CISSP, MCSE, C|EH, CIFI and CGSP.
This was first published in July 2013