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 172.16.39.1] 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 "172.16.39.129"] [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.