We all know that publishing a website or web based application is the start to a long journey. A lot of care and effort goes into making sure everything is just right. The idea of being “safe” or “secure” is just that, an idea; a pipe-dream if you will. The sooner you realize that you’re always behind, the sooner you can let go and focus on the things that matter. What matters more than anything is understanding what is going on with your site. This means knowing the basics:

  • Who is accessing your site?
  • How are they using it?
  • Are there any errors while they are using it?

There are lots of other things to take into consideration, but we can start here. Like most things, knowledge is the key to being successful in securing the stuff you put on the web. I have talked quite a bit in the past about secure coding practices, and doing what you can to prevent attacks by improving software security. While this is something that we should always strive for, it’s not really enough to provide us with a good understanding of what attacks might be in play at any given moment. There are a number of tools out there to help with this, but I want to talk about one of my favorite free and open source tools, ModSecurity.

For those of you who are already familiar with ModSecurity, you might be thinking that this is obvious. Just put a web application firewall in place. OWASP even says so. While it is true that web application firewalls can help stop would be intruders at the gates, I don’t actually take much stock in their ability to do so. There have been a few hints that using a WAF might even give away a too much information about you and help attackers zero in on you faster. The question is how do we understand what is going on and still protect ourselves from people trying to break down our defenses? For me the answer isn’t really obvious. I am still working on new ideas every day, but since we have to start somewhere, let’s start with setting up ModSecurity and exploring some of its features.

Initial Setup

All of the examples that follow will be using Ubuntu 12.04 LTS Server and Apache. I simply created a new virtual machine for this experiment and worked from there. You can go about this any way you would like, but I found this to be the fastest and easiest setup of all the distro/web server combinations I tried. ModSecurity does run on IIS and nginx, but it requires quite a few more steps to get going. With all of that said, let’s get to work.

I’m assuming a fresh install of Ubuntu server, so the following packages will be the everything needed. If you’re working from an existing system, you might already have these things installed.

$ sudo apt-get install libxml2 libxml2-dev libxml2-utils
$ sudo apt-get install libaprutil1 libaprutil1-dev
$ sudo apt-get install libapache-mod-security apache2

Now we just need to put the configuration into place:

$ sudo mv modsecurity.conf-recommended modsecurity.conf

Along with installing ModSecurity we also want to install the core rule set.

$ wget http://downloads.sourceforge.net/project/mod-security/modsecurity-crs/0-CURRENT/modsecurity-crs_2.2.5.tar.gz
$ tar xvzf modsecurity-crs_2.2.5.tar.gz
$ sudo cp -R modsecurity-crs_2.2.5/* /etc/modsecurity/
$ sudo mv /etc/modsecurity/modsecurity_crs_10_setup.conf.example  /etc/modsecurity/modsecurity_crs_10_setup.conf
$ cd /etc/modsecurity/base_rules
$ for f in * ; do sudo ln -s /etc/modsecurity/base_rules/$f /etc/modsecurity/activated_rules/$f ; done
$ cd /etc/modsecurity/optional_rules
$ for f in * ; do sudo ln -s /etc/modsecurity/optional_rules/$f /etc/modsecurity/activated_rules/$f ; done

After everything is in place, we need to tell ModSecurity to load the OWASP core rules that we just copied in. Open /etc/apache2/mods-available/mod-security.conf and add the following:

Include "/etc/modsecurity/activated_rules/*.conf"

Just in case the headers and mod-security modules aren’t enabled for some reason, we can give them a nudge with a2enmod and restart Apache:

$ sudo a2enmod headers
$ sudo a2enmod mod-security
$ sudo service apache2 restart

With everything in place we can give it a try. First, try hitting your server by ip address. You will notice that everything is displayed properly. Looking at /var/log/apache2/error.log presents an entirely different story though. Let’s take a look at one of the log entries:

[Sat Jan 05 20:20:55 2013] [error] [client] ModSecurity: Warning. Operator LT matched 5 at TX:inbound_anomaly_score. [file "/etc/modsecurity/activated_rules/modsecurity_crs_60_correlation.conf"] [line "33"] [id "981203"] [msg "Inbound Anomaly Score (Total Inbound Score: 2, SQLi=, XSS=): Host header is a numeric IP address"] [hostname ""] [uri "/favicon.ico"] [unique_id "UOjfh38AAQEAAAkJAboAAAAB"]

This rule is triggered because we hit the server directly by its IP address. Since our web application will most likely be served from a real name, this is a good rule to keep in place. You might be wondering now why all that happened was a log entry. This is because we haven’t yet told ModSecurity to deny requests that trigger alerts. Let’s turn that on now. Open /etc/modsecurity/modsecurity.conf and make the following change:

- SecRuleEngine DetectionOnly
+ SecRuleEngine On

Then simply restart Apache

sudo service apache2 restart

If you reload the page you will get a forbidden message. You are now stopping potentially bad traffic using ModSecurity. In the next installment we will take a look at the rules that are triggered in the default install and learn how to configure the default install to not deny legitimate traffic.