Securing web applications with modsecurity on Debian Wheezy
Never trust user input
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 using
apt. But, Debian version is not necessarily the latest version.
Is this enough?
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
WHERESQL 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:
- ModSecurity Rules and Support from Trustwave SpiderLabs
- Atomicorp's Realtime Gotroot ModSecurity Rules
- Other managed security services
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
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
cd /etc/modsecurity cp modsecurity.conf-recommended modsecurity.conf
create your custom configuration file
<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
Apache headers module is required by some rules. For example: testing your Apache configuration without headers module
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.
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
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.
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
You may also be interested in