I am copying a portion of the web page here so you can see how malicious attacks make there way into servers, undetected by the host company, and from there they impact you. The words are techie, but I can make the point: You are at the mercy of companies that host web sites- the individuals that support the servers MUST know security, must correctly and intelligently configure the servers, and they must keep the software up-to-date. I'm betting a large number of people in many hosting companies don't meet best practice criteria. Be especially careful of offshore hosting sites and the websites residing on those hosts.
So read this as an example of best practices for hosting companies.
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 secure Apache 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 asRequestReadTimeout, 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
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_securityhas the ability to act like a Web application firewall, which is invaluable when serving Web applications that may not have the best input filtering.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_phpmay 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 enablingmod_log_forensic to get an even more in-depth view of client requests.
Remain aware
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.
No comments:
Post a Comment