Mod Security 2.5

One of my favorite things about mod_security is that (amongst other things), it provides logging where none was provided. In fact, there is a whole chapter dedicated to it (chapter 4 on audit logging). And thus the first chapter I went to (just for fun). So I started flipping back and forth between chapters 2 (writing rules) and 4 (audit logging) to create my ruleset. I quickly realized that it was going to be a pain to do it that way. So I sucked it up and started reading the book. I normally hate doing that because typically technical books read like watching paint dry, but this one read fairly easily. I also happen to really like the type face conventions used by Packt Publishing to make examples separate from text separate from whatever else needs to stand out.

I skimmed chapter 1 because I not only have built programs including Apache modules in my time, but I have also setup mod_security 1 before. This is why I was so excited to dive into this book since it has been a while and I wanted to see what has changed in mod_security over the years.

Right into chapter 2, I wrote a few logging rules and some protection from SQL injection. And then I tried out the recipe to stop all visitors from the US from accessing the web site. Needless to say that worked, so I apologize for the few min of downtime you all may have experienced.

Chapter 3 was inevitably about performance. This is always a concern amongst admins. Most of your fears are assuaged by chart after comparison chart of how Apache works under the load of httperf along with a few experience based suggestions on how to reduce Apache’s memory footprint and other helpful items. It even tails off with optimizing how you employ regular expressions.

Now chapter 4 again, audit logging. The logs themselves have quite a bit of information in them. Although they can be read, it can be pretty tedious. The mod_security console discussed in the book makes this a lot easier.

Virtual patching is an interesting concept that allows for the ability to apply a patch for a vulnerability without one being supplied by the vendor. There are a few examples, including the Twitter worm of 2009 of where it can be practically applicable. It is covered pretty extensively in chapter 5.

Chapter 6 is actually the meat of the book. It is where the commonly used recipes are. In fact, I have added more than a few of these recipe to some of the various web servers I run.

As a admin, one is usually concerned with security. Let’s face it, why else would you be looking into mod_security? If you are into host security, then have a look at chapter 7 about using chroot jails. There is a section discussing where this is appropriate and if it is, how to implement it without having to put Apache fully in a chroot jail.

Just like any tool with an archaic interface for rules (like the original days of SELinux or configuring Nagios), there inevitably comes GUI tools. Remo is one of those tools. One of the coolest things about Remo (in my opinion) is that its written in Rails and can therefore be run using either Webrick or another Rails engine (like Phusion Passenger in Apache or Mongrel). If you don’t want to dive too heavily into the Apache config files, then give Remo a shot.

The book finishes up by showing an fairly detailed example ruleset for a live web application. And really, who doesn’t have one of those (live web application).

Other than the one major editing flaw of labeling chapter 5 as chapter 9, the book was excellent. Not only would I recommend this book to other SAs, I already have. Besides being very readable, there are many recipes in this book that are immediately applicable and easily implemented. Mod_security has a fairly low barrier to entry and the simplicity in this book proves it. With the type of data and the amount of data being stored in web applications these days, extra security is a must.

You can purchase the book from Amazon or find other locations through Packt Publishing.

Related posts:

1. Modsecurity 2.5 Review Coming
2. MySQL for Python
3. Building Telephony Systems With Asterisk

If you don’t know anything about mod_security, I encourage you to read up on it in the interim.

Stay tuned for the review.

Related posts:

1. Mod-Security 2.5 by Magnus Mischel

Check for DDos:

Using this command will produce a list of hostnames that have a connect to the machine in an ESTABLISHED state. This is handy for creating a firewall rule either on the host (iptables, ipfw) or a little further away from the machine (at the edge router).

Check for web attacks:

By using this command, you will get a hostname lookup on the IP sorted by total hit count descending. As when checking for DDos attacks, you can use this information to write firewall rules.

More web attack checks:

The difference between this check and the previous check is that this time, you may have a lot more logfiles to go through. I am also assuming that they are stored by .. They will print out which file its scanning and the top 2 issues from that file.

Referrer Check:

This last check will get the referrer for a page from the logs and count up the number of times that exact referrer drives traffic to your page. Although this may initially appear to be only tangentially useful, if you are getting DDos, it may be hard to track down. Let’s say that you have some static content like a funny image and want to know why everyone is going to that image. Maybe your getting Dugg or ./ and this will help you tell (and find out what your page is so you can Digg yourself if you’re into that sort of thing).

Related posts:

1. Sys::Hostname
2. Cleaning Up Long Conditionals With Grep
3. Checking Roles in Views Using RoleRequirement

Since there aren’t too many clear HOWTOs on this, it took a bit of fudging. Here is what you need to know.

Let’s create the host http://port8080.lubow.org/ to go to http://8080.lubow.org:8080/.

The first thing is a fairly common default configuration of NameVirtualHost option. This is so you can have multiple virtual hosts per IP. Unless you are crazy (or have a really good reason), you do not want to create an open proxy. So you need to globally configure the ProxyRequests variable to be off. Do the base setup for a VirtualHost of ServerName and ServerAdmin.

Setup the proxy authorizations (similar to the apache allow/denys). In order for the right HTTP headers to make it to the proxy’d virtual host, the headers will need to be rewritten. This needs to happen both going to the host and coming back from the host going to the client. This is why there is the ProxyPass and ProxyPassReverse. The first argument is the URL that on the virtual host that should match the URL (second argument) on the proxy’d virtual host. The ProxyPreserveHost option is generally not needed (but it is for the specific application I am running. Click the link above to read the description to determine whether it is right for you.

Putting it all together, you will get a file that looks like below. Make sure you replace your IPs and hostnames with what’s appropriate for your environment.

Related posts:

1. A Few Apache Tips