ModSecurity for Apache 2.0.0-beta-3 now available!

I have been awfully quiet recently, having made my last post to this blog in late March. I have a very good excuse - I have been very busy re-writing ModSecurity. But, now that the new code base is in a good shape, it is time to share the new features with the others. It is time to ask you, the users, to share your comments, ideas, and bug reports with me.

ModSecurity 2.x is a big deal. The project grew organically since 2003, with features added on top of the existing architecture. At some point we hit a limit of what is possible with the old code base. It's when I decided the time was ripe to break ModSecurity into pieces and re-assemble it into a brand new code base. ModSecurity 2.x is a result of a year of planning and several months of execution. The new code is nice, tidy, and modular. More importabtly, the new code is no longer tightly intergrated with Apache, which allows it to be ported to other web servers. (Yes, this will be happening later this year.)

But you are probably more interested in what's in it for *you* :) There were so many changes that it is very difficult to make a list, let alone prioritise it. Probably the first thing you will notice is that 2.x is not backward compatible with 1.x. I am sorry but I just had to do it. I thought long and hard about this one but ultimately decided it is not possible to preserve the old syntax without making the new one a big mess. There were no radical changes. You are going to continue to do things in the same way only slightly differently. On the positive side, I used the opportunity to remove a number of inconsistencies that accumulated over time. I understand that, because of this, many of you will not jump onto 2.x. After all, there is no reason to change what is already working. That is why I expect to support 1.9.x for at least several months after 2.x is published.

Finally, here is a brief list of improvements:

• Five processing phases (where there was only one in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those of you that wanted to do things at the earliest possible moment can do them now.
• Per-rule transformation options (previously normalisation was implicit and hard-coded). Many new transformation functions were added.
• Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, etc.
• Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and appliction users).
• Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).
• Support for web applications and session IDs.
• Regex backreferences.
• There are now many functions that can be applied to the variables (where previously one could only use regular expressions).
• XML support (parsing, validation, XPath).

Overall, you will find ModSecurity now does very little, if anything, implicitly. You will be expected to configure it explicitly to work as you want it to work. I realise this is going to make life more difficult for a casual user, but I also believe the change was necessary to make ModSecurity into a tool that can properly mitigate web application security issues.

You can download ModSecurity 2.x from the Thinking Stone Network (free registration, no spam). The manual is included in the distribution. While you're there, be sure to check ModSecurity Console 1.0.0-beta-1, a nice looking daemon/GUI tool for ModSecurity audit log centralisation, which I will cover in a future post. Both programs are available for download in the Early Access section.