Trustwave has been dedicated to supporting ModSecurity and the associated community for the better part of a decade. Over this time, ModSecurity and the associated OWASP Core Rule Set (CRS) have seen major advances and are currently positioned as leading WAF solutions.
Our goal since taking over leadership of this project has been to prevent stagnant and continuously lead the industry with innovative solutions that help secure the next generation of web applications.
It is with this in mind that we are pleased to announce the first release candidate for CRS 3.0. This RC represents the culmination of a large effort to improve the CRS project and is currently nearly 500 commits ahead of the current 2.2.9 rolling release. Some of the features that stand out are:
CRS 3.0 Release Candidate (RC) one is a significant milestone for the OWASP Core Rule Set. However, it still requires involvement from you to ensure that it reaches its full potential! Our initial plan is to have an open evaluation period that will last approximately one month. Depending on the feedback received we expect to generate a second release candidate which will hopefully become the final release in early October.
With the release of CRS version 3, CRS 2.x will become a legacy release. In this environment only bug and security fixes are accepted, although any other proposed changes will be evaluated on an individual basis. As a result, users who are currently using 2.x or are updating from the master repository are advised to prepare to switch to the 3.0 final release. Additional messages will be provided to the ModSecurity mailing lists as this change approaches.
Upgrading from CRS 2.x may present as a limited challenge for some. Due to the use of new features, OWASP CRS 3.0 requires ModSecurity version 2.8 or higher, which includes compatibility with the upcoming ModSecurity v3 (libmodsecurity). In addition, all rule files have been renamed and rules have been renumbered. For the first release, we intend to not overlap rule IDs to allow both rule sets to be run simultaneously. We have also included documentation that specifies what each ID has been changed to, if the rule was present in the 2.2.9 ruleset, along with a script for converting exclusions.
Despite changes, installing or upgrading is easy! After ModSecurity is installed just follow the following steps:
If you need a little more guidance, check out the INSTALL file or the revamped documentation. Still running into problems? Spot a bug? We encourage everyone to use our GitHub page to report bugs or false positives. While some false positives are unavoidable, we are always interested in seeing if it is possible to make OWASP CRS a better project for everyone. To open a bug, or false positive report, or just to get some help - navigate to https://github.com/SpiderLabs/owasp-modsecurity-crs/issues and open a new issue. You can also get help by messaging our mailing list at owasp-modsecurity-core-rule-set@lists.owasp.org. Or by joining us on freenode IRC at #modsecurity.
As with all new releases we are particularly interested in speed. Speed is always hard to quantify for WAFs, especially because it depends on many factors including the performance of the computer, the connection to the host, the request being made, and what actions the webserver must take as a result of that request. In the tests below we clearly show this by testing OWASP CRS version 2 and 3 on a static page and then testing a stock WordPress without ModSecurity enabled.
The following tests were performed using JMeter on a Lenovo x220 with an Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz, 8GB of RAM running Fedora 23, Apache/2.4.23, and ModSecurity 2.9.1. Jmeter was run using 10 threads for 30-second runs. In this configuration, CRS v3rc1 ran through 65101 packets with an average of 2169.7 TPS.
It should be clear that certain actions such as hitting a database can severely reduce performance far more than what ModSecurity's overhead will incur. Additionally, various settings in ModSecurity may also lead to different performance results, for instance using XML requests, which go through different pre-processing, or enabling ModSecurity's debug logging (which shouldn't be done in production) would yield significantly different results.
Let's break down where the heavy performance hitters are:
As we can see from the data above our protocol enforcement (file 20) is a performance hog bringing down our performance by ~500 Tps. As we go forward we will be paying special attention to which rules in this file lead to the most issues. If you'd like to generate your own performance data we have included the JMeter test plan we used for generating our data here (note it requires the jp@gc plugins).
OWASP CRS has always been designed to be integrated into an environment with the help of an administrator. For many, this was seen as too high of a barrier to entry. In order to address these concerns, the OWASP CRS team has worked hard to reduce false positives, improve rule quality, and introduce the anomaly scoring mode as the default. Additionally, one of the big improvements to CRS v3 is the reintroduction of paranoia levels. While some tuning may still be required, it is now easier than ever to get started and over time increase the paranoia level to match your security maturity. Below you can see a comparison of false positives as we browse a stock Wordpress install. (Selenium test available here).
CRS version 3 ends up with 8 total alerts - 3 of those are just alert correlation information, a result of the new anomaly mode, and all of the alerts stem from the modification and submission of a PHP file. From a security perspective, without any context, this is literally PHP injection and should be caught by any WAF. These types of false positives can be quickly tuned out by adding exclusions for the administrator's computer. More information can be found in the documentation or in the following blog post: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-advanced-topic-of-the-week-updated-exception-handling/.
Meanwhile, CRS v2 ended with 59 rules triggered, because the default mode in CRSv2 is not anomaly mode all of these results are triggered rules many of them crippling false positives. We have seen such a great reduction in false positives by testing our rules against large data sources with the help of organizations like cPanel, and due to our dedicated contributors who bring their own data and expertise to help improve both the rules and the project. We think you'll agree that this is a marked increase in overall quality.
We are thankful for the many hours of diligent work from the many supporters who have contributed to this update and we look forward to a smooth transition to CRS v3. I'd like to take this opportunity to give a special thanks to Walter Hop and Christian Folini who worked tirelessly spending hours of their free time to ensure that CRS v3 would be delivered at a tremendously high build quality.
We really do appreciate our supporters and anyone can get started contributing, there is no need to be a ModSecurity all-star! If you have ever been interested in supporting an open-source project, OWASP CRS is a great choice for all levels with a small and friendly community, lots of work, a great reputation, and no coding experience needed. Feel free to stop by on IRC or by opening a Github issue to introduce yourself.
See you there!