The OWASP ModSecurity Core Rule Set 3.0

A defensive approach to web-application security generally relies on an onion architecture, with multiple layers of defense. One of those layers is often a web-application firewall (WAF), such as a WAF created using ModSecurity. As we saw in last week's article, though, writing ModSecurity rules for a web application can be an overwhelming task. For that reason, many turn to the OWASP ModSecurity Core Rule Set, or CRS for short; that project has just released CRS 3.0 with many improvements—notably for false-positive elimination.

Some background

The CRS is a set of generic blacklisting rules. Ofer Shezaf started the project almost exactly ten years ago by pulling in regular expressions from various other defense projects and writing new rules of his own. Later, Ryan Barnett took over and introduced the CRS scoring mechanism, where individual rules no longer 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.

Barnett also steered the project into the arms of the Open Web Application Security Project (OWASP), where it is supported as a flagship project. It has become the most widespread WAF rule set on the internet. Last winter, Chaim Sanders took over and revived the project which had slowed down a bit.

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.

A typical example in this regard is session cookies: web applications use cookies to identify users by assigning their browser session a random string as a token. The browser will then submit this identification string with every request and the application server is able to link the request to a session. Many applications generate random session identifiers in a way that does not raise suspicion (e.g. simple hex strings without any "0x"). But there are applications that use the full alphabet and the numbers 0-9 for session identifiers. So there is some chance that the token string will contain "0x" followed by some hexadecimal numbers. The rule watching out for hex-encoded payloads will score a hit now and potentially block the user.

And that was exactly how this would play out in all CRS releases in the 2.x series. ModSecurity would alert on every request of the session with messages pointing to rule 981260 "SQL Hex Encoding Identified" (rule). It does not take much imagination to see that false positives are a major roadblock for WAF deployments and especially ModSecurity CRS deployments. However, with the new CRS 3.0 release, this is largely not the case.

New features of the 3.0 release

For the Core Rule Set 3.0 release, Sanders made the fight against false positives a priority. This was really needed, as false positives like the notorious "SQL Hex Encoding Identified"—or its partners in crime 981172 "Restricted SQL Character Anomaly Detection Alert: Cookies" (rule) and 981173 "Restricted SQL Character Anomaly Detection Alert: Request Parameters" (rule)—buried many system administrators under an avalanche of reports. False positives combined with a lack of documentation and guidance on how to fight them effectively would often lead to frustration and a full stop to the ModSecurity adventure. Or the WAF was put in detection-only mode with nobody looking at the alerts anymore. With the release of CRS 3.0, over 95% of false positives in the default install are gone. How was this achieved?

First, the rule set was consolidated for the CRS 3.0 release. This process began when Barnett was still running the project. The rules were categorized and only those that contributed substantially to the detection rate made the cut. Second, a wide group of SQL-injection and cross-site scripting (XSS) rules was abandoned in favor of Nick Galbreath's libinjection library, which does a far better job than the previous heuristics.

This year, the project closed existing holes in its detection capabilities. Walter Hop extended the rules fighting remote command execution (RCE) substantially and introduced a small group of highly efficient rules to detect PHP injection attempts. This is a delicate area as the most widespread content management systems (CMS) are written in PHP and their installations regularly fall victim to all sorts of attacks.

Of course, a CMS protected by the CRS used to cause many false positives, so the new rules had to be diligent in avoiding them. On top of this, the new release comes with a set of optional rule exclusions for the core installations of WordPress and Drupal. These are optional configuration files that tune the rules to avoid false positives for these applications. This means it switches off certain rules for certain requests or parameters where it is known that ModSecurity would trigger an alert.

Disabling individual rules in this way 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 ModSecurity for WordPress and Drupal. Formerly, installations of CRS 2.x were usually disabled rather quickly unless the system administrator invested a lot of time and effort into the badly documented tuning process. The CRS 3.0 release also updates the documentation with a series of tutorials hosted at netnea, guiding users through the ModSecurity installation, the inclusion of the Core Rule Set, and handling the remaining false positives. Combine this with the second edition of the ModSecurity Handbook that has been released as a preview and you can see that the documentation situation has improved a great deal.

The default CRS 3.0 install is generally meant to be mostly void of false positives and it has detection capabilities at least on par with the CRS 2.x release line. Once the anomaly scoring threshold has been reduced to the minimum, if a higher security level is desired, more rules that are disabled by default can be enabled. This is called "Paranoia Mode". It is configured via the Paranoia Level (PL) configuration item.

Paranoia Level, which defaults to one, controls the selection of rules applied to a request. At PL1, you get about 150 rules known to have a high detection ability and that are unlikely to provoke false positives. Raise that to PL2 and you get an additional set of 30 rules that are a bit more aggressive—a bit more paranoid, so to speak. They cover more attacks, effectively raising the security level, but the system will likely receive a few false alarms in return, so the security comes at a price. The standard procedure is to look at these false positives and write rule exclusions.

Go to PL3 to get another 15 rules and now quite a few false positives with them. At PL3, one will become quite proficient at handling false positives. Finally, raising to PL4 reaches the maximum level of paranoia. Here, half a dozen additional rules go crazy with anything that does not look totally innocent.

For example, PL4 defines a small range of byte values it accepts in a request body. Every file upload and most special characters outside of letters and numbers will provoke an alert in an extremely paranoid way. If you write the necessary rule exclusions, you end up with an efficient way of protecting your application, with special characters limited to the places where they are really mandatory for the online application.

The definition of the byte range is also present in PL1, PL2, and PL3, but it is much more lax. With every new PL, new rules are applied that restrict the character set more and more. Think of it as a relaxed base rule and a set of stricter siblings.

The Paranoia Levels are meant to be mapped to the security level of a site. A private blog does not have same resources to put into security that a site processing credit card data does. The project envisions a future where security officers and auditors regularly assign CRS Paranoia Levels to online services: "This is a PL3 service. Please reserve time in the project for the handling of false positives."

False positives are not the only obstacle on the road to a tight CRS setup. Often, system administrators are afraid of the performance impact. This is a serious concern. There is typically a performance loss of a few percentage points when introducing ModSecurity with the CRS. The exact value is hard to know in advance and depends on the situation.

The new Sampling Mode allows enabling the CRS for a limited percentage of requests in order to get a feeling for it. That makes it possible to observe the behavior and performance of an installation on a controllable number of requests. With growing confidence and possible performance problems weeded out, the sampling percentage can slowly be raised until 100%, which is the default value.

Overall, the kinds of attacks that the CRS targets are the major problem areas for web applications today, which is unsurprising. SQL injection, cross-site scripting, PHP code injection, and shell command injection are the types of attacks where the CRS has the strongest protections. Within the many rules, however, there are also rules covering protocol violations and alerting on back-end error messages reaching attackers.

With these new features and the false-positive problem solved to a large extent, the Core Rule Set is now ready for prime time. The times where only ModSecurity experts succeeded with their setups are gone. Well-tested beginner-level documentation, in the form of the tutorials mentioned above, and professional courses are available. So the project believes that the rule set is ready for wide adoption. This CRS 3.0 release is thus aimed at mainstream installations. The project has highlighted this with a release poster (seen at right) aimed at mainstream adoption.

Plans for the future

The mainstreaming of the CRS will also allow the project to bring new people into the community to help with the plans it has for the future. The developers want to reduce the remaining false negatives by using new detection methods. The project also wants to follow the development of new exploits and bypasses more attentively so that holes can be closed more quickly.

CRS 3.0 demonstrates that a predefined set of rule exclusions allows for a simple installation for WordPress and Drupal core. The project hopes to join forces with developers and security teams to expand this to the standard plugins for these systems and for a wider set of standard online applications that would be supported with optional rule exclusion files in future CRS releases.

The CRS documentation has improved a great deal. But the project won't stop until every rule is documented individually with an explanation of the mechanism, as well as examples of payloads triggering the rule, and unit tests safeguarding against errors in future pull requests. Eventually, the CRS project sees the rule set rolled out as the first line of defense against web-application attacks in the same way that hosting providers are now installing free TLS certificates from Let's Encrypt by default: simple, smooth, and with no nasty side effects, but a big improvement in terms of security.