About ModSecurity WAF

13th March 2018 by Christian Folini

Many web applications depend on a web-application firewall (WAF) as an important part of their security strategy. There are a few free-software options in the WAF space, but they are all limited in scope. The only multi-purpose project is ModSecurity, which has been around for over 15 years now. In fact, ModSecurity is often the base that is used by commercial WAF offerings because of its flexibility and the granular control that it offers. But readers may not be familiar with ModSecurity, so an introduction to it is in order.

In 2006, the payment-card industry (PCI) mandated the use of a WAF in order to have a secure online offering, but did not specify a particular WAF implementation. That allowed many companies to offer WAFs of varying quality as the key component for PCI compliance. That variance gave WAFs a bad name; ModSecurity is one of the few brands that stands out from the rest.

ModSecurity has a variety of features, but the rule language is by far the most important one. Let's think of it as a domain-specific language for ModSecurity. The SecRule directive gives access to the full requests and responses via over one hundred different variables. Naturally, this covers all of the headers but it also allows access to individual arguments by parsing the payload of requests and responses as well. This feature also handles XML and JSON request content types, giving fine-grained access to individual parameters in the requests.

But rule writing is hard and takes some experience. That's why most people rely on pre-defined rule sets with the OWASP ModSecurity Core Rule Set (CRS for short) being the most peopular one.

The CRS is a set of generic blacklisting rules, that work with a scoring mechanism, where individual rules do not block requests directly but, instead, raise an anomaly score. When all the rules have been executed, a user-defined threshold is applied and the request is blocked if it exceeds the value.

The CRS is a set of about 200 rules that try to detect attacks against web applications in a generic way. It does not know about individual exploits, but it knows the typical building blocks that are often used to construct attacks, such as those described by the OWASP Top Ten project.

One example might be hex-encoded payloads. Various SQL servers are known to decode and execute hex-encoded queries. Hex-encoded payloads are thus a good entry point for SQL injection attacks. That is why the CRS has a rule that detects a hex-encoded payload and flags it as a potential attack.

This is clearly a heuristic approach. Of course, not all hex-encoded payloads are an attack and sometimes you cannot even be sure something is really hex-encoded or just looks that way. So, in real life, there is always the chance of a false alarm: a false positive of the detection mechanism. When this happens you need to handle it with care. Either you manage to convince the application developers to change the way their application works, or you will need to disable certain rules or checks.

Disabling individual rules is always a compromise. The idea is to keep the disruption of the rule set to a minimum and, by reducing the false positives in such a way, allow people to actually run their applications. There is extensive documentation guiding you through the process of handling false positives in a successful way.

Combine this with the second edition of the ModSecurity Handbook that I had the pleasure to co-write and you get everything you need to run the CRS successfully.

Links:
https://www.netnea.com/cms/apache-tutorials/
https://www.feistyduck.com/books/modsecurity-handbook/