Book review: Magnus Mischel – ModSecurity 2.5

It’s been quite a while since I received my review copy of Magnus Mischel’s ModSecurity book titled “ModSecurity 2.5” but I finally found the time to read it and write up my review. As the title suggest it’s a book about the ModSecurity Web Application Firewall (WAF) module for Apache and about version 2.5 of it specifically. There are some books about the 1.x series of ModSecurity. It’s great that there is a book about the 2.x ModSecurity series now as ModSecurity 2.x is very different from the 1.x series.

The ModSecurity module is very powerful but also very complex. It’s pretty trivial to add a few rules blocking some attacks, but when trying to protect large web applications such as OWA things get complicated very quickly. But even with a smaller system like WordPress I found that finding the right approach is not trivial. While there is an online manual and there are an array of blogposts (some written by me even), a good overview of ModSecurity’s features and how to really deploy it properly and effectively in complex environments is lacking. This is what I hoped to find in this book.

Giving this expectation the book slightly disappointed me. But let me start out with what I liked about the book.

The book gives a broad overview of how ModSecurity can be used. It deals with the obvious parts like compilation, installation and setting up, but also handles more interesting parts like virtual patching, performance profiling, the difference between “positive” and “negative” security approaches, REMO (a web based open source ModSecurity rule editor) and more. I learned quite a bit here, for example about directives to deal with credit card numbers.

Where it falls short is mostly in the lack of depth. It touches a lot of subjects, but most of them only pretty briefly. Next to this a view chapters could be organized a little better, especially in the first couple of chapters. I think what would really improve this book is adding the approach done by my favorite ModSecurity book so far, Ryan C. Barnetts “Preventing Web Attacks With Apache”. In that book a flawed application is introduced (Buggy Bank) and much time is spend on explaining how things are broken and where ModSecurity can and cannot help.

My verdict is that “ModSecurity 2.5” is a good introductionary book into ModSecurity, but that it’s missing some depth to be much more than that. Being someone that has quite a bit of ModSecurity experience, including writing pretty complex rulesets, I had hoped for more help on dealing with those. But all being said, I still recommend this book to anyone that is in need of a good introduction into ModSecurity. I recommend picking up Ryan C. Barnetts “Preventing Web Attacks With Apache” book alongside with it, even though it deals with ModSecurity 1.x. I think together they will provide enough depth to deal with a real world environment.

On a final note I’d like to mention that Ivan Ristic, the original ModSecurity creator, has also written a new book on ModSecurity. I haven’t read that yet, but Ivan’s first book was excellent.

Setting up Subversion for Snort_inline

A reason for the slow development of Snort_inline is that we still weren’t using a version control system. Being sick of this, I decided to setup a private Subversion server to see how we could best use it. One thing that complicates the use of such a system is the fact that we maintain a patch on top of source code not maintained by ourselves. So the system must be able to deal with upstream sourcecode updates.

In the excellent book Practical Subversion, Garrett Rooney suggests the use of so called vendor branches. In this setup the vanilla sources of the upstream Snort would be in the svn repository as well. I’ve decided to experiment with this, and this is how I found it to work.

There are two branches in the svn:


In vendor, the vanilla source is imported, with tags to the specific releases. So for Snort you will have:


The trunk is first initialized as a copy of vendor/current, after which the Snort_inline specific code is added to the trunk. All modifications to our Snort_inline patch will be done in trunk/.

Where this approach shines is when there is a new upstream version. The procedure is this:

  1. checkout vendor/current
  2. update your working copy to the new version
  3. commit
  4. create a new tag for the new version.

For going to, this also meant removing a few files. After this, you have:


After this, checkout the trunk, and do a merge of the two vanilla trees ( and into the trunk. This will update our Snort_inline code with the new ‘vendor’ version. This will create a number of conflicts that will have to be resolved manually (because of our changes in Snort_inline), but resolving this turns out to be a lot simpler and less time comsuming than our old method of just copy-pasting the Snort_inline code into the new Snort release.

Anyway, since Will and I were happy about this approach, we have decided to move to the SVN server, which now contains a trunk with Snort_inline code, soon to be released as Snort_inline BETA 1. But don’t wait for us, you can also checkout your own copy from:

Check it out! 🙂

Books: Preventing Webattacks with Apache

I just finished Preventing Webattacks with Apache by Ryan C. Barnett. Even though the title says it is about Apache it is really mostly about Mod_Security, and this is why i really love the book.

Especially cool is the part of the book where the author challenges the user to setup his ‘Buggy Bank’ example application to play with the vulnarebilities and with the possible counter measures.

This book got me even more exited about Mod_Security, which I use already to protect one webserver. I plan to check out setting up a reverse filtering web proxy soon.