Protect And Audit Your Web Server With ModSecurity

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 Installation

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:

1. Ensure that httpd and httpd-devel are installed along with all their dependencies.

1. Enable unique_id_module in Apache. To do so, edit the file /etc/httpd/conf/httpd.conf and uncomment the line containing LoadModule unique_id_module modules/mod_unique_id.so. You must reload Apache for the change to take effect.

1. Download the latest version of ModSecurity from the project's site.

1. Extract the downloaded package and go inside the newly created directory modsecurity-apache_2.x.x, where x.x is the latest branch of ModSecurity.

1. Go through the standard steps for installing a source package: ./configure && make && make install.

1. If the above commands finish successfully, ModSecurity will be installed on the system. A new Apache module will be in /etc/httpd/modules/mod_security2.so, while ModSecurity's executables will be in /usr/local/modsecurity/bin/.

1. To load the new ModSecurity module, edit Apache's configuration file, /etc/httpd/conf/httpd.conf. Find the part where all modules are loaded by looking for LoadModule. At the end of that part, add LoadModule security2_module modules/mod_security2.so.

1. Restart Apache. Ensure that ModSecurity is correctly installed by running apachectl -D DUMP_MODULES |grep security and look for security2_module (shared) in the output.

At this point ModSecurity is installed but not enabled or configured – so let's configure it.

ModSecurity Configuration

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):

Include /etc/httpd/conf/crs/*.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.conf
cp ~/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.

Testing and Debugging ModSecurity

 

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:

1. Disable the whole rule by using the directive SecRuleRemoveById. This statement should be placed in a file that loads after all other ModSecurity files and rules. Create modsecurity_crs_70_exceptions.conf and place it in /etc/httpd/conf/crs. This file is meant to remain compatible between versions and consistent over time, so when ModSecurity's rules are updated, the ignored rules will be remembered.
   
   Disabling this rule, however, may not be a smart move, since this rule does more than block just /etc/ directories. When the rule is disabled, the server is exposed to certain attacks, such as Remote File Access.

1. A better alternative for security and reliability may be to edit the rule and remove the conflicting part. However, it is not always easy to edit rules because they often use complex regular expressions. Also, future updates overwrite old ModSecurity rules and files, including all customizations.

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.

Conclusion

 

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.

Follow @openlogic
Follow @CloudSwing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.Follow @openlogic
Follow @OSCloudServices

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.