ModSecurity is a free, open source Apache module that acts as web application firewall (WAF). Its rich features, strong community, and optional commercial support make it a must for any production Apache web server that serves non-static content and requires auditing.
ModSecurity's primary function is to offer reliable protection against web threats. It does not move the focus on security from the application, but rather adds features on a global level. You can configure it by specifying rules with conditions and actions for every part of the communication between a client and a server, including the request header, request body, response headers, and response body. Thus ModSecurity can prevent attacks against the web server, interpreters such as PHP, Perl, and ASP, and web applications.
ModSecurity can mitigate zero-day attacks and provide protection for vulnerabilities before vendors do, as it did recently with rules for the Apache Range Header DOS vulnerability and Java floating point DOS attack.
While it's inspecting the complete communication flow, ModSecurity can also log it, meaning the software can be used for auditing and troubleshooting. Full logging adds overhead to the web server, so it is usually enabled only when problems have to be debugged. However, full logging (and reviewing) is a must in some organizations that put high emphasis on security.
ModSecurity can take extremely powerful actions once it encounters a matched condition. Actions can be disruptive, such as blocking transactions, or non-disruptive, such as logging data. It can execute a Linux command once a condition is met, which significantly extends ModSecurity's functionality and gives it all the power Linux has for handling a transaction. It can chain rules to apply more complex conditions. Its accounting algorithms can be used as substitution for ModEvasive to stop excessive numbers of requests and DOS attacks.
ModSecurity is available for installation from the official repositories of Debian-based distributions. For CentOS and other Red Hat-based distributions, ModSecurity is available in the EPEL repository, but if you want to have the latest version with the latest features, you need to perform a manual installation. Here's how to do that in CentOS 6:
LoadModule unique_id_module modules/mod_unique_id.so
./configure && make && make install
LoadModule security2_module modules/mod_security2.so
apachectl -D DUMP_MODULES |grep security
At this point ModSecurity is installed but not enabled or configured – so let's configure it.
When you begin to configure ModSecurity, you first use global directives such as SecRuleEngine in your main configuration file /etc/httpd/conf/crs/modsecurity_crs_10_config.conf, as I'll discuss later in detail. However, for most of the configuration you create security rules with the directive SecRule. The latter fine-tune ModSecurity, and tend to become very complex.
A sample ModSecurity rule looks like this:
SecRule Target Operator [Actions]
Target defines what is to be checked – for example, REQUEST_URI. Operator states how the check should be performed. The optional Actions specify what is to be done once a condition is met.
Getting started with ModSecurity is not easy, nor is it easy to write your own security rules. That's why you should begin with the core ruleset distributed by OWASP. You can customize it for your needs, but this ruleset is reliable, proven, and covers many popular malicious attacks. Even though it is not web application-specific, it can help against common hacking techniques. However, it can also block legitimate requests, so it has to be deployed with care and customized.
Create a separate directory in which only ModSecurity files with rules will be stored, such as /etc/httpd/conf/crs/. To tell Apache to include all ModSecurity configuration directives from this directory, add the following line at the end of Apache's configuration file (/etc/httpd/conf/httpd.conf):
Download the latest ruleset to a temporary directory – for example, ~/mod_security_test/. You can do this with a Perl script called rules-updater.pl that by default you can find in /usr/local/modsecurity/bin/. It requires the Perl module Crypt::SSLeay, and you run it like this:
/usr/local/modsecurity/bin/rules-updater.pl -rhttp://www.modsecurity.org/autoupdate/repository/ -prules -Smodsecurity-crs
The above command downloads a zip archive with a version tag for the rules – currently modsecurity-crs_2.2.2.zip. Extract the archive (unzip modsecurity-crs_2.2.2.zip) inside the temporary directory, then copy the main configuration file for ModSecurity, called modsecurity_crs_10_config.conf.example, and the basic rules found in base_rules:
cp ~/mod_security_test/modsecurity_crs_10_config.conf.example /etc/httpd/conf/crs/modsecurity_crs_10_config.confcp ~/mod_security_test/base_rules/* /etc/httpd/conf/crs/
In addition to the base rules, the core ruleset provides application-specific rules such as the ones in the ~/mod_security_test/slr_rules directory. The latter are specially designed to protect popular web applications such as Joomla and WordPress. However, take extra care when applying any specific or experimental rules, because they could corrupt legitimate communication between clients and the web server.
To start using the newly installed rules, edit the file /etc/httpd/conf/crs/modsecurity_crs_10_config.conf and look for the directive SecRuleEngine, which determines whether and how ModSecurity rules are enforced. It has three modes: On (enabled), Off (disabled), and DetectionOnly, which just logs when a rule is triggered without enforcing it. The third option is perfect for getting started with ModSecurity or for ensuring trouble-free deployment of new ModSecurity rules. In addition to specifying this setting, specify SecDataDir, which is the directory used for storing persistent data IP addresses and sessions. A good place to store this data is /tmp; specify SecDataDir /tmp right after the SecRuleEngine setting.
Once you have set SecRuleEngine to DetectionOnly, reload Apache to make the change take effect. Then you can begin testing ModSecurity even in production environments, because it will cause no harm. By default ModSecurity logs to Apache's error log, which in CentOS is /var/log/httpd/error_log.
As a first test, access a bogus URL such as http://yourserverip/etc/. In the Apache's error log you should see an error containing "ModSecurity: Warning. Pattern match "\\\\/etc\\\\/"." This indicates that ModSecurity rules are enabled. If you see a "404 Not Found" page, it confirms that ModSecurity is in learning mode (SecRuleEngine DetectionOnly). If ModSecurity's rules were enforced (SecRuleEngine On) you would see a "403 Forbidden" page.
When you first implement ModSecurity you will probably get a lot of warnings and errors about legitimate requests. Suppose you did have a directory called etc on the website. According to Apache's error log it would be blocked because of ModSecurity's rule id 958700. Here's a snippet taken from the log:
[Wed Nov 09 05:40:34 2011] [error] [client 10.0.2.2] ModSecurity: Warning. Pattern match "\\\\/etc\\\\/" at REQUEST_FILENAME. [file "/etc/httpd/conf/crs/modsecurity_crs_40_generic_attacks.conf"] [line "221"] [id "958700"] [rev "2.2.2"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [tag "WASCTC/WASC-33"] [tag "OWASP_TOP_10/A4"] [tag "PCI/6.5.4"] [hostname "localhost"] [uri "/etc/"] [unique_id "TrpYon8AAAEAAAYaVy4AAAAA"]
According to this log entry, this rule is in the file /etc/httpd/conf/crs/modsecurity_crs_40_generic_attacks.conf on line 221. At this point you have two options:
In our example the rule is simple and very specific: SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\/etc\/" \. To go with option 1, use the directive SecRuleRemoveById 958700. To go with option 2, remove just REQUEST_FILENAME. This will ensure the web server is protected against attacks in other parts of clients' requests.
SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\/etc\/" \
ModSecurity offers everything a WAF can offer and more. However, configuring it is not easy, and the software lacks a graphical interface. That's why some organizations with substantial IT budgets may prefer other commercial solutions such as F5's Big-IP Application Security Manager. Such commercial alternatives run on separate hardware units with additional features such as proxying and content acceleration.
Allowed tags: <a> link, <b> bold, <i> italics