ModSecurity is an open source web application firewall that runs as an Apache module, and version 2.0 offers many new features and improvements. Federico Biancuzzi interviewed Ivan Ristic to discuss the new logging system, events tracking and correlation, filtering AJAX or AFLAX applications, and just-in-time patching for closed
source applications.


...once you decide an IP address is suspicious you could place it on the 'IP addresses to watch' list and start logging every transaction performed, even for requests that come several days/weeks/months later. My favorite is the ability to move the entire session or user account to a honeypot system, then you can record their actions in an environment where they can not do you any harm.


Ivan Ristic

Could you introduce yourself?

Ivan Ristic:
I am a web application security specialist and have been referred to as a web application firewall guy. In truth, I have many diverse interests (most of them related to technology) but I tend to deal with only one at a time. We live in exciting times when there is so much to do; wherever you look there is room for improvement.

My background is in software development and I have spent significant time architecting
software systems. However, over the last couple of years I became focused exclusively
on security. Today I am probably best known for my work on ModSecurity,
which is an open source web application firewall, and my book, Apache Security,
which was published by O'Reilly in 2005.

As a result of the recent acquisition of ModSecurity by Breach Security,
I moved to work for them as their Chief Evangelist. My job is mainly going to be to working on ModSecurity
(which Breach Security are going to continue to develop as an open source product) along with extending
Breach Security's web application security products and promoting web application firewalls in general.

Ivan Ristic:
It all started back in 2002. Back then the awareness of web application security issues wasn't nearly as high as it is today. I realized there were many vulnerable web applications out there and wondered if there was something I could do to help secure them. I also understood that educating the market about this problem was going to take some time and that a solution was needed now. At the same time, I realized from my experience as a programmer that even when you understand web security it is difficult to produce secure code, especially when working under the pressure so common in today's software development projects. [editor's note: Ivan wrote an Infocus technical article on ModSecurity back in 2003]

So, I thought it would be very useful to have something sitting in front of a web application to screen the requests as they come in. I now realize that I was thinking about a web application firewall but I did not know it at the time. I understood my security world well, but at the time I was not up-to-date with the state of the art in security (such as security products, papers, etc). If similar products existed, as a programmer I wasn't aware of them at that time.

I had to make my biggest decision at the beginning of the project: do I make it a standalone program (a reverse proxy), a Snort plug-in, or an Apache plug-in? Those were my three choices.

I did not like the reverse proxy idea because I would be forced to spend a lot of work dealing with raw HTTP, which was not very exciting. The Snort plug-in approach did not appeal to me because of Snort's orientation toward lower network layers and there was (and is) an issue with it being unable to see through SSL.

With Apache, however, I could dive straight in and start achieving my goals. Since ModSecurity can be embedded into Apache, the audience is much bigger. Not everyone can afford to put a reverse-proxy in front of their web server(s) (and you need two to avoid a central point of failure). Over the years I actually spent a lot of time wrestling with Apache and its APIs (especially in Apache 1.3.x) because my requirements were not typical. Apache 2.x has a much better architecture, but I was working with it at a time when it was pretty new and there was no documentation to speak of.

Today ModSecurity is recognized as the world's most widely deployed web application firewall. It is referred to as the "Swiss-army knife" of web security and people are using it for a wide range of functions, from web application monitoring and web intrusion detection and prevention. It works especially well for what I call "just-in-time" patching, where you provide a temporary fix working outside the vulnerable web application.

What's new in ModSecurity 2.0?

Ivan Ristic:
The 2.0 version of ModSecurity is very important because it is a complete rewrite. It's the next generation code. Since its inception in late 2002 ModSecurity was based on the same code base. I am pleased that the original architecture lasted for several years but it is now time to move on. The new architecture builds on top of everything I have learned during the past four years with ModSecurity 1.9.x. and opens the door to many exciting new features.

One such feature is portability. ModSecurity 1.9.x is an Apache-only product. I have always wanted to port it to [Microsoft's] Internet Information Server but the same issues that enabled me to start working very fast at the beginning (tight integration with Apache) prevented me to do the port later on. It took a complete rewrite to pull ModSecurity out of Apache and into a portable code base. So I am expecting an IIS/ISA version to be available fairly soon.

Feature-wise, there are many improvements and I don't really know where to start. Some of the major improvements include:

Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.

Per-rule transformation options (previously normalization 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, and so on.

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 application users).

Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).

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).

More than ever, ModSecurity is a precision tool: it does not stand in your way but allows you to do what you want, when you want it. There is very little, if anything, happening implicitly. And I think that is a good thing. I really like the fact that ModSecurity does not give you anything by default. There are so many tools that give the illusion of security along with simplicity, but they don't tell you that there are circumstances when they don't work as expected. So we end up with the majority of users not knowing about the weak aspects. But the bad guys know that stuff well and use it regularly.

On the other hand, I received feedback that ModSecurity is becoming more difficult to use. I think a correct way to address this problem is through a console. I believe in the separation of concerns: the core engine must address the security issues and the GUI should address the ease of use. The ModSecurity Community Console will be available soon and will begin to address this problem. [editor's note: the ModSecurity Console v1.0 was just released]