Securing web applications with modsecurity on Debian Wheezy

Mod-security is a (third party) module of Apache (recently Microsoft IIS και 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 usingapt. 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:

When you expect a number from your user, you must be sure that a number has been given. See an example How to find whether a variable is a (positive) integer with PHP
When you expect an alphanumeric text from your user, you must be sure that a alphanumeric text has been given. See an example Sanitize User Input Text with PHP
quote and escape any "string" from user input which will be used in WHERE SQL statement. For example, use mysqli::real_escape_string or any other similar function.
display any saved "string" using htmlspecialchars

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

Search This Blog

KINJE TAARIFA