Blog

Securing web applications with modsecurity on Debian Wheezy

Tags: , , , , , , , , , , ,
You are currently viewing Securing web applications with modsecurity on Debian Wheezy

Mod-security is a (third party) module of Apache (recently Microsoft IIS and NGINX) offering intrusion detection and (some kind of) prevention for web applications, acting as a web application firewall. The modsecurity module created by Ivan Ristic (writer of the relevant book), but, now, is actually a service of Trustwave.

Indicative types of attacks:

  • SQL injection attacks
  • XSS cross-site scripting
  • path traversal attacks
  • file inclusion
  • Denial of service (DOS) attack (experimental)
  • Brute force attack (experimental)

Mod-security module ifself does… nothing! To provide protection some rules must be given. The basic rules are the Core Rule Set (CRS) and are available free from the Open Web Application Security Project (OWASP) here. Also valilable on Github.

Mod-security Core Rule Set (CRS) is also available on Debian repositories and you can update them using apt. But, Debian version is not necessarily the latest version.

Is this enough?

No.

First things first: you must ALWAYS sanitize user input in every GET of POST variable.

Simple rules to make your code secure:

But you cannot be sure that these checks applied in every case from every person which writes code in your organization. So you need a tool to do the hard work for you. Mod-security is a great choice.

Installing mod-security module and using of CRS from Debian repositories is the first step to secure your web application. This is the subject of this post.

However, if you run a critical web application and security is very important, you have to ask for professional advice, so you will have

  • more rules (commercial rules, not only the basic set)
  • the latest version of the rules using an easy mechanism to update them
  • commercial support

Some option you have:

Installation and configuration

Simple steps to enable and configure mod-security Apache module on Debian Wheezy, using Core Rule Set (CRS). After setup, modsecurity will block any suspicious url and “403 forbidden” page will be displayed.

Install Apache modsecurity module

apt-get install libapache2-modsecurity

Add rules

Copy CRS

cp -rp  /usr/share/modsecurity-crs/* /etc/modsecurity

So, the directory structure will seem like

ls -la /etc/modsecurity


total 64K
drwxr-xr-x  8 root root 4.0K Apr 10 14:08 .
drwxr-xr-x 89 root root 4.0K Apr 13 23:09 ..
drwxr-xr-x  2 root root 4.0K Apr 10 17:45 activated_rules
drwxr-xr-x  2 root root 4.0K Apr 10 13:53 base_rules
drwxr-xr-x  2 root root 4.0K Apr 10 13:53 experimental_rules
drwxr-xr-x  2 root root 4.0K Apr 10 13:53 lua
-rw-r--r--  1 root root 7.3K Jul 25  2014 modsecurity.conf-recommended
-rw-r--r--  1 root root  14K Jul  2  2012 modsecurity_crs_10_setup.conf
drwxr-xr-x  2 root root 4.0K Apr 10 13:53 optional_rules
drwxr-xr-x  3 root root 4.0K Apr 10 13:53 util

Then create symbolic links to folder activated_rules

for f in `ls base_rules/` ; do ln -s /etc/modsecurity/base_rules/$f activated_rules/$f ; done
for f in `ls optional_rules/` ; do ln -s /etc/modsecurity/optional_rules/$f activated_rules/$f ; done

If you want, create additional symbolic links for experimental_rules

Configuration files

cd /etc/modsecurity
cp modsecurity.conf-recommended modsecurity.conf

create your custom configuration file

nano /etc/apache2/conf.d/modsecurity

with contents

<IfModule security2_module>
    Include /etc/modsecurity/*.conf
    Include /etc/modsecurity/activated_rules/*.conf

    # enable suspicious URL blocking
    SecRuleEngine On

    SecResponseBodyAccess Off
    SecRequestBodyLimit 13107200
    SecRequestBodyNoFilesLimit 131072
    SecRequestBodyInMemoryLimit 131072

    # uncomment on production
    #SecAuditEngine Off
</IfModule>

Enable Apache headers module

a2enmod headers

Apache headers module is required by some rules. For example: testing your Apache configuration without headers module

apachectl configtest

you will get something like this:

Syntax error on line 30 of /etc/modsecurity/activated_rules/modsecurity_crs_49_header_tagging.conf:
Invalid command 'RequestHeader', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.

Restart Apache

service apache2 restart

or using systemd (recommended)

systemctl restart apache2.service

Check audit log

In this file you can see what URLs are blocked by modsecurity and why they are blocked (check the rule id)

tail -f /var/log/apache2/modsec_audit.log

Detect modsecurity false positives

Sometimes modesecurity will block a url of your web application with no clearly suspicious items (false positive). If you are sure that your code has no security holes, just exclude the relevant rule after checking the log file (/var/log/apache2/modsec_audit.log)

Create whitelist file

nano /etc/modsecurity/activated_rules/modsecurity_crs_99_whitelist.conf

and use SecRuleRemoveById or other similar directives

# whitelist IP:
SecRule REMOTE_ADDR "^192.168.1.10" phase:1,nolog,allow,ctl:ruleEngine=off
# deactivate rule XXXXXX
SecRuleRemoveById XXXXXX

Remeber to restart Apache after every change.

Remarks

Sometimes modsecurity will block Googlebot. So, if your web site is using Adsense and you note in audit log that Googlebot is blocked, it is not a wise decision to use modsecurity. But you must be sure that your code has no security holes, otherwise you are in great danger of hacking.

To verify that the blocked IP is Googlebot, see Verifying Googlebot