![[FCO]FreeCoursesOnline](https://onehack.us/uploads/default/original/3X/b/4/b4d2fc8468becec1e9976784dba394e5a378ec81.jpg){kind=small}
Introduction
ModSecurity is a tool that will help you secure your web applications. No, scratch that. Actually, ModSecurity is a tool that will help you sleep better at night, and I will explain how. I usually call ModSecurity aweb application firewall (WAF), because that’s the generally accepted term to refer to the class of products that are specifically designed to secure web applications. Other times I will call it an HTTP intrusion detection tool, because I think that name better describes what ModSecurity does. Neither name is entirely adequate, yet we don’t have a better one. Besides, it doesn’t really matter what we call it. The point is that web applications—yours, mine, everyone’s—are terribly insecure on average. We struggle to keep up with the security issues and need any help we can get to secure them.
The idea to write ModSecurity came to me during one of my sleepless nights—I couldn’t sleep because I was responsible for the security of several web-based products. I could see the web application security storm on the horizon. (We were then largely in the age of innocence when it came to web application security.) I could see how most web applications were just slapped together with little time spent on design and little time spent on understanding the security issues. Furthermore, not only were web applications insecure, but we had no idea how insecure they were or if they were being attacked. Our only eyes were the web server access and error logs, and they didn’t say much.
Which brings me to my point. ModSecurity will help you sleep better at night because, above all, it solves the visibility problem: it lets you see your web traffic. That visibility is key to security: once you are able to see HTTP traffic, you are able to analyze it in real time, record it as necessary, and react to the events. The best part of this concept is that you get to do all of that without actually touching web applications. Even better, the concept can be applied to any application—even the one to which you don’t have access to the source code.
There are four guiding principles on which ModSecurity is based, as follows:
Flexibility
I think that it’s fair to say that I built ModSecurity for myself: a security expert who needs to intercept, analyze, and store HTTP traffic. I didn’t see much value in hard-coded functionality, because real life is so complex that everyone needs to do things just slightly differently. ModSecurity achieves flexibility by giving you a powerful rule language, which allows you to do exactly what you need to, in combination with the
ability to apply rules only where you need to.
Passiveness
ModSecurity will take great care to never interact with a transaction unless you tell it to. That is simply because I didn’t trust a tool, even the one I built, to make decisions for me. That’s why ModSecurity will give you plenty of information, but ultimately leave the decisions to you.
Predictability
There’s no such thing as a perfect tool, but a predictable one is the next best thing. Armed with all the facts, which you will find in the reference manual, the posts on the ModSecurity Blog, or here, you can understand ModSecurity’s weak points and work around them.
Feature quality over quantity
Over the course of six years spent working on ModSecurity, we came up with many ideas for what ModSecurity could do. We didn’t act on most of them. We kept them for later. Why? Because we understood that we have limited resources available at our disposal and that our minds (ideas) are far faster than our implementation abilities. We chose to limit the available functionality, but do really well at what we decided to keep in.
There are bits in ModSecurity that fall outside the scope of these four principles. For example, ModSecurity can change the way Apache identifies itself to the outside world, confine the Apache process within a jail, and even implement an elaborate scheme to deal with an once-infamous universal XSS vulnerability in Adobe Reader. Although it was I who added those features, I now think that they detract from the main purpose of ModSecurity, which is a reliable and predictable tool that allows for HTTP traffic inspection.
Brief History
Like many other open source projects, ModSecurity started out as a hobby. Software development had been my primary concern back in 2002, when I realized that producing secure web applications is virtually impossible. As a result, I started to fantasize about a tool that would sit in front of web applications and control the flow of data in and out. The first version was released in November 2002, but a few more months were needed before the tool became useful. Other people started to learn about it, and the popularity of ModSecurity started to rise.
Happy learning!