Introduction

ModSecurity is an embeddable web application firewall or WAF. It can be installed as part of your existing web server infrastructure.

ModSecurity is available as a package for different Linux distributions but these versions are often outdated. I installed ModSecurity from source on Ubuntu 12.0.4 LTS.

Download, configure, compile and install

Start by downloading the source tarball from the ModSecurity website. The full code is available via GitHub and the links to the tarballs are available from the home page.

You need a number of packages installed before the configure and compile process will complete.
If you get an error

configure: looking for Apache module support via DSO through APXS
configure: error: couldn't find APXS

then you will have to install apache2-prefork-dev.
I installed these packages :

apt-get install libxml2-dev
apt-get install libcurl4-openssl-dev
apt-get install liblua5.1-0 liblua5.1-0-dev

Additionally, if you have never compiled a package on your system then you will also have to install the compiler environment.

apt-get install build-essential

Download (version omitted from command below) and extract the package and then run the configure command.

cd /usr/local/src
wget wget https://www.modsecurity.org/tarball/modsecurity-apache.tar.gz
tar zxvf modsecurity-apache.tar.gz
cd modsecurity-apache
./configure --prefix=/usr/local

When the config command finishes without errors you can start the compile process.

make && make install

This will install the files for ModSecurity in /usr/local.

Apache configuration

The next step is to add the necessary files to load the module in apache. On Ubuntu, the module configuration files are in /etc/apache2/mods-available/. You will need to add a file /etc/apache2/mods-available/mod_security.load with this content

LoadFile /usr/lib/i386-linux-gnu/libxml2.so
LoadFile /usr/lib/i386-linux-gnu/liblua5.1.so

LoadModule security2_module /usr/local/lib/mod_security2.so
<IfModule !mod_security2.c>
error_mod_security_is_not_loaded
</IfModule>

<IfModule mod_security2.c>
Include "/etc/modsecurity/activated_rules/*.conf"
Include /etc/modsecurity/*.conf
</IfModule>

Note that the first two lines contain i386-linux-gnu. Depending on your system architecture you might have to change this. The easiest way to find out were the XML2 and Lua libraries are stored is with the find command.

find /usr/lib -iname "libxml*"

Once you have the apache module configuration file (mod_security.load) in the available module lists you can enable the module. The ModSecurity modules also needs unique_id to be enabled.

a2enmod unique_id
a2enmod mod_security

Removing Ubuntu ModSecurity files

If you had previously installed ModSecurity through a Ubuntu package than you will have to remove some files. These files contain instructions to include configuration files but similar instructions are already available in other files. Including the same files multiple times will cause an error.

rm /etc/apache2/conf.d/modsecurity2.conf
rm /etc/apache2/mods_available/mod-security.load
rm /etc/apache2/mods_available/mod-security.conf

(notice that there’s a ‘-‘ (minus) instead of an underscore.)

Module configuration

Create configuration directories

The next step is to proceed with the module configuration. Create the necessary directories and copy the basic configuration file.

mkdir /etc/modsecurity
mkdir /etc/modsecurity/activated_rules
cp /usr/local/src/modsecurity-apache/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
cp /usr/local/src/modsecurity-apache/unicode.mapping /etc/modsecurity/

Spiderlabs rulesets

ModSecurity needs a number of rules to work properly. Download them from the GitHub account.

cd /etc/modsecurity
wget https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master
tar zxvf master
ln -s SpiderLabs-owasp-modsecurity-crs-4ed6347 spiderlabs

Now you can make symlinks from the downloaded ruleset to the activated_rules folder. That folder will contain all the activated rules.

cd /etc/modsecurity/activated_rules
for f in /etc/modsecurity/spiderlabs/base_rules/* ; do ln -s $f . ; done

This will activate the basic rules. There are a number of other interesting rules in the folders optional_rules and slr_rules. If you run a CMS (Joomla, WordPress) you can enable the relevant rules from the slr_ruleset by using a symlink. For example to enable the WordPress rules do

cd /etc/modsecurity/activated_rules
ln -s /etc/modsecurity/spiderlabs/slr_rules/modsecurity_46_slr_et_wordpress.data .
ln -s /etc/modsecurity/spiderlabs/slr_rules/modsecurity_crs_46_slr_et_wordpress_attacks.conf .

Ruleset configuration file

Next you’ll have to download the basic ruleset configuration file to your ModSecurity directory.

cd /etc/modsecurity/
wget -O modsecurity_crs_10_setup.conf https://raw.githubusercontent.com/SpiderLabs/owasp-modsecurity-crs/master/modsecurity_crs_10_setup.conf.example 

This file sets the allowed methods, HTTP versions and provides necessary configuration settings for the ruleset.

Custom rules

Some web applications (for example the Drupal maintenance cron job) have a cron job that is run via a local web request but can trigger a ModSecurity rule. This will polute your logs. You can exclude (‘whitelist’) hosts. Create a file myruleset.conf in /etc/modsecurity

SecRule REMOTE_ADDR "@ipMatch 127.0.0.1" "phase:1,nolog,allow,id:'999001'"

Notice the ‘999001’ at the end. That must be a unique number identifying the rule (more on that later).

Disable rules

SecRuleRemoveById

You can disable rules globally or per virtual host with the SecRuleRemoveById directive. If you want to disable a rule globally then add this to the file myruleset.conf. For example to disable the rule 960015 (block requests that do not have an Accept Header) you should do

SecRuleRemoveById 960015

Disable rules per location

For some files you might want to disable ModSecurity entirely or disable a subset of rules. You can do this with the Apache directive LocationMatch. For example to prevent ModSecurity to block access to the robots.txt or favicon.ico files you could add to myruleset.conf :

<LocationMatch "/(robots.txt|favicon.ico)">
  <IfModule mod_security2.c>
    SecRuleEngine Off
  </IfModule>
</LocationMatch>

If you want to disable a list of rules for multiple web resources then you can add

<LocationMatch "/(login.asp|admin)">
  <IfModule mod_security2.c>
    SecRuleRemoveById 981172 981173
  </IfModule>
</LocationMatch>

I disabled a rule and it is not working

We mentioned the file /etc/apache2/mods-available/mod_security.load before. Look at the sequence of command. We first include all the rules and then we specify which rules to delete. If you change the order of inclusions you have the possibility that some rules get applied even though you indicated to ignore them.
So the rule of thumb is, first include all the rules and then include the file with the configuration to remove specific rules.

Logrotate the audit file

If you have enabled the logging to an audit file then you need to logrotate that file also. The audit log file setting is SecAuditLog in modsecurity.conf. Add a line to /etc/logrotate.conf

/var/log/modsec_audit.log {
    missingok
    weekly
    rotate 4
    compress
}

Found another rule with the same id

If you get a message similar to

Syntax error on line 60 of /etc/modsecurity/activated_rules/modsecurity_crs_46_slr_et_wordpress_attacks.conf:
ModSecurity: Found another rule with the same id
Action 'configtest' failed.
The Apache error log may have more information.
   ...fail!

then this means that you have multiple rules with the same id. Remember the ‘id’ field mentioned earlier if you want to whitelist hosts? It is the same id field that needs to be unique.

Change the server signature

You can change the Apache server signature with SecServerSignature.

SecServerSignature "Apache/1.2.3 (Unix)"

Test your ModSecurity rules

After all these configuration steps it is important to test if your ModSecurity setup is working as expected. Do a tail on your web server error log

tail -f /var/log/apache2/error_log

and do some of these web requests. They should all trigger an alert and you should receive a 403 or 500 HTTP error message.

/?abc=../../
/test=1+OR+1%3D1
/?<script>alert(1)</script>

Traditional vs. Anomaly Scoring Detection Modes

The newer versions of ModSecurity provide a different scoring methods. In the traditional method the rules are “self-contained.” Just like HTTP itself, the individual rules are stateless. In the Anomaly Scoring Detection, the rules will contribute to a transactional anomaly score collection. These resources provide useful reading material

• Traditional vs. Anomaly Scoring Detection Modes
• Exception Handling