Protect your Web server with mod_security
Monday, October 16, 2006 11:38 AM
Vincent Danen tells you how to tighten up security for your Web server by implementing some simple preventive measures with mod_security.
Anyone paying any attention to the number of new vulnerabilities being discovered has quickly realized that the largest "threat" to security is no longer applications bundled with the operating system but, rather, Web services that can be used on virtually any platform.
A quick perusal of the CVE dictionary will quickly show that various Web applications have more vulnerabilities than the systems providing the groundwork for the application itself.
This could be a discourse on how easy it is to program incorrectly with scripting languages like PHP, or the number of vulnerabilities found in (largely) PHP-based applications; but instead, the focus will be on preventative measures, so that even if one of the Web applications you happen to be running is vulnerable to a XSS (cross-site scripting), SQL injection, or any one of a number of other classes of vulnerabilities, you can protect yourself without rushing to upgrade to the latest version.
Since every Linux distribution ships with Apache, and because it powers more sites than it doesn't, the easiest way to mitigate threats is to use Apache with mod_security. A fair number of Linux distributions provide mod_security, so it's only a yum, apt-get, or urpmi away with package names such as apache2-mod_security or httpd-mod_security. If it isn't included in your distribution, downloading and compiling from source is a no-brainer; just be sure to compile it as a module you can insert into the Apache "stack."
Once this is done, edit httpd.conf and add:
LoadModule security_module extramodules/mod_security.so
SecFilterEngine On
Include conf/mod_security.conf
This will load the mod_security.so module, enable the engine, and include the file mod_security.conf (paths may vary, dependent upon distribution). The reason for including a separate configuration file is to separate mod_security rules from regular Apache directives. Once this is done, the mod_security.conf file will contain all the mod_security rules; each time the rules have changed, however, Apache needs to be reloaded.
Some example rules are:
SecAuditLog logs/audit_log
SecAuditEngine RelevantOnly
SecFilterScanPOST On
SecFilterDefaultAction "deny,log,status:500"
SecFilter /etc/passwd
SecFilter "\.\./"
SecFilter "<[[:space:]]*script"
The first enables the audit log and tells it to log only relevant policy violations, which makes it very easy to identify and keep track of issues. Then, mod_security is told to scan all POST requests, and to first deny, then log, then throw an Error 500 page on any policy violations, instead of allowing the Web server to process the request.
The SecFilter directives are to create the actual policy filters. In this case, any requests with the string "/etc/passwd" are automatically denied. As well, path traversal attacks, or strings containing "../" are stopped in their tracks. The final SecFilter is a cheap-man's XSS filter that still allows common HTML tags.
mod_security is quite powerful and many sites provide various rules. The trick is to start small and build up appropriate filters. What works for one person may not work for you or the applications you have installed, and the last thing you want is for mod_security to stop legitimate traffic and requests.
There are currently no comments for this post.