Better Living Through Mod Security

posted onJuly 3, 2004

by hitbsecnews

By:Dhillon A. K. (dhillon -at- hackinthebox.org)

We’ve all heard of web application level firewalls, and they’re certainly not something new, with several good commercial offerings available for quite some time. Most of these products will offer some kind of web based administration and reporting facilities to allow simple and straight forward management.

On the open source end of the scale we have a project named ModSecurity. According to the Mod Security website (http://www.modsecurity.org), ModSecurity is an open source intrusion detection and prevention engine for web applications. Operating as an Apache Web server module, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.

Getting the code

The current version of ModSecurity is 1.7.6 with the 1.8 release slated for April 2004. You can grab the latest copy from http://www.modsecurity.org/download/index.html. While you’re at it, you might as well grab a copy of the Documentation or take a look at some of the sample scripts provided to get you started.

Installing ModSecurity

While ModSecurity can be installed via a dynamic library module, I personally prefer to compile the modules I want and need statically into the apache binary. If you’re running a handful of sites, getting ModSecurity installed and running for all your sites shouldn’t be too difficult, however in the case of hosting providers and the like, a properly planned migration would be in order… In this article we shall be using Apache 1.3.29 (http://www.apache.org) and ModSecurity 1.7.6 as examples.

Untar your Apache source package and run the usual pre-configure routine.

tar –xvzf apache-1.3.29.tar.gz
cd apache-1.3.29/
./configure
cd ..

Untar your ModSecurity Package

tar –xvzf mod_security-1.7.6.tar.gz
cd mod_security-1.7.6

Now if you’re using Apache 2.0 you’ll need to copy out the mod_security.c file from the Apache2 directory. In our case, we’ll be using the Apache1 module. As such, copy the mod_security.c file into your apache extra modules directory.

cp apache1/mod_security.c ../apache-1.3.29/src/modules/extra/
cd ..

Now it’s time to build and configure Apache with ModSecurity

cd apache-1.3.29
../configure –-prefix=/usr/local/apache –-activate-module=src/modules/extra/mod_security
make
make install

In order to get ModSecurity activated, you’ll need to modify your Apache httpd.conf file and define rules for ModSecurity to act upon. The source package includes a converted set of snort rules in the util directory named snortmodsec_rules.txt. I personally do not recommend you cut and paste the entire contents of the file as a starting reference to your mod_security ruleset without first reading through it and determining what rules you actually need and which you don’t. Enabling ALL those rules will essentially break almost any application in some way or another. Further to this, you’ll also run the risk of having false positives as the ModSecurity engine would flag for attacks that may not affect your machine (can be a good thing, read on). Below is a barebones sample that should serve well to get you started on writing your own rule sets.

Just add the following into your httpd.conf file. ModSecurity also works on a per-virthost, per-directory or per-IP basis, so really the choice is yours in terms of how you’re going to set this up…

    # Turn the filtering engine On or Off
    SecFilterEngine On
    
    # Make sure that URL encoding is valid
    SecFilterCheckURLEncoding On
    
    # Unicode encoding check
    SecFilterCheckUnicodeEncoding Off
    
    # Only allow bytes from this range
    SecFilterForceByteRange 0 255
    
    # Only log suspicious requests
    SecAuditEngine RelevantOnly
    
    # The name of the audit log file
    SecAuditLog logs/audit_log
    # Debug level set to a minimum
    SecFilterDebugLog logs/modsec_debug_log    
    SecFilterDebugLevel 0
    
    # Should mod_security inspect POST payloads
    SecFilterScanPOST On
    
    # By default log and deny suspicious requests
    # with HTTP status 500
    SecFilterDefaultAction "deny,log,status:500"

Doing Stuff

Now on its own, the sample config above will already offer you some level of protection but to really get the best out of ModSecurity, you’re going to need to write your own rules. This in itself is a fairly simple affair. There are two different types of rules you can write. Either a fixed Filter rule or a FilterSelective rule. The syntax of each is illustrated below:

SecFilter “What you want to filter” “What you want to do as an action”
SecFilterSelective “What you want to filter” “optional chain command to give a sort of IF conditional” “What you want to do as an action”

Protecting your applications can be pretty easy but it depends on how the application was coded in the first place. If you’re running a forum or interactive system which requires user input, having a rule set that is very restrictive will pretty much guarantee that you’ll end up with a broken application. That being said, I personally prefer to set a strict ruleset matching for syntaxes that do not affect me (for example setting up filters for Windows based attacks when I am running Apache), and then slowly ease up on the rigidity till things start working again. Although filtering for attacks that do not affect my system increases the false positives however it does provide for a better overall understanding of WHAT kind of attacks are coming in, where they’re originating from and how often they occur. Besides, its funny to see the number of people who launch Windows based attacks REPEATEDLY against a UNIX based target :D.

While the audit_log provided by Mod Security is good, and even captures the POST data (something Apache does not normally log), having the log in a text only format is not very user friendly not to mention impossible to use if you wanted to make some form of analysis of threats over say, a 2 week period. As such, I have included a PHP script which will parse the audit_log and place each variable into a MySQL database (see the end of the article for the download link). I will leave it as an exercise to the user to write an engine to output some nifty reports!

Conclusion

While not perfect, Mod Security does offer some form of protection that as they say, is better than nothing. While there will certainly be a small level of performance hit, in the four odd weeks that I’ve been using it, I have not really noticed any significant performance degradation.

On a side note with regards to the audit_log file, do note that setting the SecAuditEngine to On instead of RelevantOnly can result in a very HUGE log clogging up your system especially for high traffic sites. With the parser in place, I had over a million records in the database in less than 2 weeks (and we all know MySQL really starts to drag at this point without some serious SQL optimization). You have been warned.

ModSec2Mysql Parser: modsec2mysql.tar.gz.

1.) Reducing "Human Factor" Mistakes - Dancho Danchev
2.) Virtual File System - /proc - Danny “Dr.T”
3.) Hiding Files - [in]visible
4.) Better Living Through Mod Security - L33tdawg
5.) Guide to ARP Spoofing - Barfbag
6.) SMOKE="gentoo" - mel
7.) Nessus - Doing more with Less - christian