The OWASP Core Rule Set (CRS) team is excited to announce the immediate availability of the OWASP Core Rule Set Version 3.0.0 stable release. This release represents over two and a half years of effort with nearly 1000 commits and countless hours of development. It is also our first major version release since 2013 (CRS 2.2.9), representing a large change in many areas including support of new rules, development strategies, and underlying technology. With this in mind, I am pleased to share with you some of the exciting improvements to the OWASP CRS.
About OWASP CRS - "The 1st Line of Defense"
The OWASP Core Rule Set is a collection of generic rules for Web Application Firewalls (WAFs) written in ModSecurity's SecRules language. While in the past these rules were designed for security administrators, we have worked diligently in this release to make them applicable to web application administrators. These rules are designed to be used as part of a defense in depth solution to help protect web applications against threats like those in the OWASP Top 10. While CRS is most often used with ModSecurity, many other WAFs leverage these rules as either a baseline or as part of their protection mechanisms. Traditionally these rules have been broken down into a number of different categories:
- HTTP protocol level protection
- Blacklisting of known malicious hosts
- HTTP denial of service protections
- Common web attacks protection (SQL injection, XSS…)
- Automation detection
- Error and information disclosure prevention
Top 5 OWASP CRS Version 3.0 improvements
Improved and More Precise Detection Coverage
An area of constant improvement for us is attack coverage. While the total number of rules is only slightly up (from 282 rules in CRS 2.2.9 to 284 rules in 3.0.0), many rules have been combined using automated regular expression generation and optimization frameworks. We reworked problematic rules to provide the same level of protection with a vastly lower number of false alerts. Many new rules have been added to protect against threats such as Shellshock (with help from Red Hat), HTTPoxy, Local File Injection, Remote Code Execution, PHP code injection, metadata/outbound error detection and suppression, alerting on malicious extension requests. Detection for traditional vulnerabilities like Cross Site Scripting (XSS) and SQL Injection has also been expanded, for instance through the use of the libinjection SQLi/XSS parser.
Reduced False Positives and the Introduction of Paranoia Levels
Another big area of focus for CRS version 3 was the reduction of false positives (false alerts). We found that often what was preventing both large scale customers like CDNs and new users was the inability to quickly deploy CRS within production environments with minimal interruption and maximum effectiveness. To that end, Christian Folini led the development of CRS's paranoia level feature. These paranoia levels will allow administrators to start off with the most reliable and effective rules at Level 1, and if an administrator intends to adopt a more strict policy, they can raise the Paranoia Level on a per-server or per-application basis, to enable additional rules that feature more narrow whitelists. However, running in higher Paranoia Level modes may bring false positive alerts that will require tuning. This optional feature will allow advanced administrators time to define, test, and adjust their policies exceptions, while still providing the strongest baseline of protection available with low administrator effort.
Anomaly Scoring Mode
Perhaps one of the most significant changes in version 3.0 is that anomaly scoring mode is enabled by default. In this mode, each rule adds to a final anomaly score rather than blocking as soon as a single rule is triggered. This allows administrators to better tailor CRS to their environment, especially when starting a new CRS deployment, while allowing us as developers more control over the types of activities to detect. While this mode was first introduced in version 2.0.0, developers at the time opted to make it optional as the rules were not well designed to leverage this functionality. It is, of course, still possible to enable traditional blocking mode, but we now use anomaly mode by default to provide better coverage and configurability.
Simplified User Experience
The OWASP Core Rule Set has always been simple to deploy. The major effort when using CRS has typically arisen from technical aspects surrounding its implementation (such as adding rule exclusions or initial configuration). To combat this, we have reworked the configuration experience. Users are still strongly recommended to review the setup configuration file, however, updated documentation, safe and sensible default settings, and well-documented options should vastly simplify all aspects of maintenance.
Additionally, in order to facilitate easier tuning, CRS now ships with prepackaged common exclusion rules to combat false positives in major web application platforms. Currently we officially support for WordPress Core and Drupal, two of the most commonly used (and attacked) web applications, but we are excited about the capability to add more with the help of the community.
New Remote Code Execution Rules
The last feature I'd like to highlight marks the first stepping stone on a path to rebuilding our rules using a more test driven approach. Walter Hop spearheaded the effort to refactor the Remote Code Execution (RCE) and PHP Code Injection rules to better account for the threats to a modern web application. The new rules are a fantastic improvement over the previous rules and offer insights into the advanced level of protection that a well focused team and methodology can produce. We look forward to applying the same methods to other types of rules.
Bonus: Improved Layout, Documentation, and Testing
Of course, what is an open source project without documentation and in version 3 we have added more documentation. This effect can be seen in a number of forms including the new CRS documentation project (https://github.com/SpiderLabs/OWASP-CRS-Documentation/), as well as overall project organization. As a result, the team has spent hours outlining new documentation for CRS along with developing new tutorials (https://www.netnea.com/cms/apache-tutorials/) and integrating new testing procedures such as the use of continuous integration practices. Some of these changes will be noticeable to newcomers and experienced developers alike. Many of the configuration files have been reorganized to best suit the needs of the end user, which includes reorganizing the initial configuration process and the relabeling of rule IDs to reflect the file name they reside in.
See It In Action
As part of our first release candidate we demonstrated the difference between OWASP CRS v2.2.9 and OWASP CRS v3 release candidate 1 (). Since that point we have made further strides in reducing false positives with the help of the community. Taking a look at the same test, which runs through a sample Wordpress setup and usage, we think you'll agree!
The RC1 demonstration video for reference: https://www.youtube.com/watch?v=_Yo2ugbb7_A
Download
For more information about the project or to download it, please visit http://www.modsecurity.org/rules.html. You can also always get the code, additional information, report your issues and make pull requests on our Github page at: https://github.com/SpiderLabs/owasp-modsecurity-crs
Download Now: https://github.com/SpiderLabs/owasp-modsecurity-crs/releases/latest
Moving Forward
Moving forward the OWASP CRS team has plenty of ideas, many of those originating from community members. We are going to spend the next few months organizing the numerous ideas and feature requests before beginning the 3.1 development work. This means that now is a great time to start contributing to the project. We always love new help, and starting at the beginning of a new development cycle guarantees you'll be able to pick something that truly peaks your interest.
Of course during this time we will be working with the community to keep the 3.0 release up to date. So please, do test the new release and let us know of any issues or feedback you have. We are always interested in hearing any bug reports, false positive alert reports, evasions, usability issues, and suggestions for new attacks to detect.
Lastly, please note that at this time the CRS 2.x branch has been moved to a historical branch (v2/master). New features will not be backported to it, and bug fixes will be reviewed on a case by case basis. Security fixes for CRS v2 will still be merged if they occur, but we encourage all of our users to upgrade to 3.x at their earliest convenience. We'll be working with package managers in order to get 3.x into OS repositories as soon as possible.
ModSecurity Commercial Rules
The OWASP Core Rule Set is a community project that is maintained by volunteers, among them members of the Trustwave Spiderlabs Web Server Security team. The free support for the project is provided by community. If you find that you need a higher level of support, Trustwave offers commercial level support contracts for ModSecurity deployments with and without the CRS deployed. Trustwave also maintains a Commercial Rule Set that is designed to provide rules that are targeted against specific vulnerabilities and supports additional protection mechanisms. Because of the nature of the commercial rules, they require no tuning and minimal configuration changes to get started. They can also run in conjunction with the OWASP Core Rule Set and serve to offer another level of defense in depth for users of the ModSecurity WAF. For more information on the Commercial Rules, please see http://modsecurity.org/commercial-rules.html
Acknowledgments
Rob "Mubix" Fuller was giving a keynote when he once said "time is precious, be careful who you give it to. Be grateful of those who give it to you." I can think of no better quote to summarize the love and admiration I have for the many people who've given their valuable time and effort into making CRS the project it is today.
I'd like to thank the CRS team, without whom none of this would be possible. Especially Christian Folini and Walter Hop, who gave up weekends and days off that they could have been spending their time working on other projects in order to help make this release successful.
I'd also like to thank the myriad of supporters who have become part of our CRS family: Christian Peron, Christoph Hansen, Jose Nazario, Zack Allen, Kate Flavel, Ryan Barnett, Felipe "Zimmerle" Costa, @shimshon70 and the countless others who dedicated their time and effort to developing and testing during the creation of version 3.0.0. A free and open project like CRS is only possible with the help of these many people and organizations.
The OWASP CRS project is always looking for new contributors. You can get involved by reaching out to us via our mailing list, on IRC, or on GitHub. The CRS is a great project to get started with, even if you don't like programming or aren't very familiar with security. We look forward to seeing you there!
GitHub: https://github.com/SpiderLabs/owasp-modsecurity-crs
IRC: #modsecurity on irc.freenode.net
Mailing List: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
