mod_security is an apache module that uses regex rules to increase the security of an Apache web-server.

The recommended version at the time of writing is:

1. the stable release 2.5
2. the core rules for 2.5.

that includes a set of pre-made rules for Apache.

Compiling the module is pretty straight-forward:

cd modsecurity-apache_2.5.12
cd apache2
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
make 
make install

Next, we add the rules to a subfolder in the apache2 subdirectory /etc/apache2/mod_security:

mkdir -p /etc/apache2/mod_security
tar -zxpvf modsecurity-core-rules_2.5-1.6.0.tar.gz

Now we need to edit the modsecurity_crs_10_config.conf file and either comment-out or set a log-directory for the following two directives:

SecAuditLog
SecDebugLog

LoadModule security2_module libexec/apache2/mod_security2.so
LoadModule unique_id_module   libexec/apache2/mod_unique_id.so 
...
ServerTokens Full
...
<IfModule mod_security2.c>
     Include "/etc/apache2/mod_security/*.conf"
</IfModule>

The ServerTokens directive is meant to hide the web-server version. The version that the web-server will display can be changed in the configuration file at /etc/apache2/mod_security/modsecurity_crs_10_config.conf.

Now open modsecurity_crs_10_config and add at the end:

SecPcreMatchLimit 50000
SecPcreMatchLimitRecursion 50000

of most of the rules will fail.

Although this guide serves as a reference for installing mod_security, we definitely do NOT recommend using mod_security at all and rather going for something like suhosin instead. mod_security is conceptually broken since it works by creating extensive blacklists instead of, more reasonably, whitelists.

mod_security functions on a pattern-matching principle, where rules can be added by "anybody" in order to increase the security of a web-server. However, this is also the reason why mod_security is in fact inherently insecure.

The very comprehensive OWASP rule-set provides enough rules so that almost any web-based application is out of the question and the web-server will end up serving HTML-only content with no dynamic pages. The OWASP rules are so excessive that they block even useful requests that belong to the web-application itself. When confronted, the usual answer is to make up your own rules which then implies that you are already fully aware of the thousands of thousands of attacks out on the Internet, as well as taking about a life-time to craft regular expressions to trap all those attacks - all the while having in mind not to block your own legitimate requests.

What usually happens in practical scenarios, is that people will start to hack around the rules, commenting some, removing others in order to get their web-application to work. Of course, this leads to an insecure server with holes left open and also additionally misleading the administrator to believe that they have secured their server.

During our tests, we used the following PHP file to simulate an attack:

<?php #
    $text=$_GET['file']; 
    echo "Content of File $text";
    echo `cat $text`;
 
?> 

Then we queried the web-server with dumb.php?file=/etc/passwd. The OWASP rules responded great, and the attack was blocked immediately which did not happen without mod_security enabled.

At the same time, we tested Drupal and Wordpress, however the same rules prevented the functionality of those platforms. From the logs, since only a few rules were the reason for the ill functionality of those platforms, we stated commenting out rules and got Drupal and Wordpress to work.

However, after the hacks, we came back to dumb.php and the exploit worked fine this time around.

Generally, if you have a different option, ditch mod_security because the protection is flawed by design. You will never really catch all the exploits (since there are always new ones) and those that you can write rules for will block some proper functionality of your web-applications. Furthermore, you never really know what those rules may hide - for example, one user reported that some OWASP rules were blocking the Google crawler, which is something you do not want to put to the test on a popular and productive website.

The concept is rather funny, especially when mod_security inspects POST data - which generally means that you will get blocked if you dare to write on your website /etc/passwd. Very funny. Sure, if you have nothing better to do, you can dedicate a year or so and write your own rules.