Apache DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


What's New in ModSecurity
Pages: 1, 2, 3, 4

Stateful Request Monitoring

People often ask me what ModSecurity can do about denial-of-service (DoS) attacks. Until recently, the answer was, "Not very much." It can help with the detection part or help you sort the bad requests from the good ones, but that was about it. To do more, ModSecurity would have to remember a thing or two between requests (at the moment, like Apache, it does not remember anything).



There is a bigger problem here. Even if ModSecurity were stateful, defending from a DoS attack on the web-server level is not the best possible option. The fact is that by the time you decide a request is a part of a DoS attack, it has mostly completed its purpose--it has engaged one web server instance to deal with it. A better option is to move the defense to the network level; for example, to a firewall that is nearest to the attacker. Deploying DoS defense at the network firewall is probably the best option. But if that's not an option for you, deploying in the host firewall will do almost equally well. We designed the improvements in ModSecurity 1.9 to handle both issues described here.

The multi-process nature of the Apache prefork execution model is usually an advantage (one process can go down while leaving the remaining processes unaffected; the controlling parent process simply creates another child). But there is a drawback: it is very difficult to share information between processes. Without information sharing, it is impossible to detect several classes of attack (for example, denial-of-service attacks).

One way to solve the problem of information sharing is to go the shared memory route. This approach is somewhat difficult to implement portably (although the APR library used to develop Apache 2.x helps a lot), but, ultimately, does not solve the problem entirely. Even if you manage to share the information between processes that are running on the same machine, what about the cases when you have several web servers working as part of a cluster?

I made a decision to use the piped logging mechanism, already well-supported in Apache, to export the relevant information out of ModSecurity to an external process that shared among all Apache processes. I named the new facility the Guardian log. In its first release I coupled the Guardian log mechanism together with a tool called httpd-guardian, whose goal is to defend against denial-of-service attacks. This is how they work together:

SecGuardianLog "|/path/to/httpd-guardian"

The next time you start (or restart) Apache you will find the httpd-guardian process running alongside it. This process will monitor the requests coming, watching for DoS attacks. The script keeps two counters for every IP address it sees: one counter for the most recent one-minute interval and another for the most recent five-minute interval. If an IP address sends too many requests in a measured period, httpd-guardian will take an action against it. By default, the action is a mere warning, but you can configure httpd-guardian to talk to your firewall to add the offending IP address to the blacklist (using iptables, pf, or SnortSam).

If you have to restart Apache on regular basis, you will be happy to know that httpd-guardian saves the counter values to a file on regular basis and reloads them the next time Apache starts.

If you need to deploy DoS protection for a cluster, you could the Spread Toolkit to centralize Guardian log output at a single location, and run only one copy of httpd-guardian (which supports Spread directly) there. Problem solved.

Other Improvements

There have been many smaller improvements throughout and it is difficult to list them all in a meaningful way. So I will just conclude the article with a list of the more interesting ones:

  • Support for HTTP methods other than GET and POST (such as PUT).
  • Performance measurement that not only measures the time it takes ModSecurity to do its thing, but also measures the communication speed of the clients and the time it takes to generate the request.
  • Integration with ClamAV to scan files being uploaded for viruses.
  • A dozen or so new variables that allow ModSecurity to look at every, even the smallest, bit of each request.
  • Support for output status code filtering in Apache 2.x.

Conclusion

ModSecurity has come a long way, with widespread deployments in the last two years. We've done a lot, but there is still a lot to do. The 1.9 release has brought several big improvements that extend the areas where ModSecurity is useful. The wealth of smaller improvements have increased the flexibility, which is what really matters to handle specific web application security problems. ModSecurity is now a well-established tool for web intrusion detection (traffic auditing and monitoring) and for just-in-time patching (reducing the window of opportunity for the attacker). As for the future, the real problem we are facing is deciding which of the features on our list to do first!

Two features are already scheduled for immediate development. Because ModSecurity does not come with a default rule set, many of its users have complained they don't know how to start using it. To solve this problem, we will soon release a generic rule set that works as a deployment guide, but also configures ModSecurity to work as a web-intrusion-detection tool. This rule set will first appear as a standalone project. It will be a part of all subsequent releases. The focus of the 2.0 release, scheduled for Q1 2006, will be the addition of the positive security model and the surrounding tools to profile web application traffic and automatically create protection rules.

Ivan Ristic is a Web security specialist and the author of ModSecurity, an open source intrusion detection and prevention engine for web applications, and the author of O'Reilly's Apache Security.


Return to the Apache DevCenter.



Sponsored by: