What is the CRS?
The OWASP ModSecurity Core Rule Set (CRS) is a set of firewall rules, which can be loaded into ModSecurity or compatible web application firewalls. The CRS consists of various
.conf files, each containing generic signatures for a common attack category, such as SQL Injection (SQLi), Cross Site Scripting (XSS), et cetera. It uses string matching, regular expression checks, and the libinjection SQLi/XSS parser.
What is ModSecurity?
ModSecurity is an open source Web Application Firewall (WAF). It can be installed as a module inside the Apache, Nginx or IIS web servers.
What is the difference between ModSecurity and CRS?
ModSecurity is a firewall engine which can inspect traffic on your web server. It can log and block requests. However, an engine does nothing without a certain policy. The CRS delivers a policy where requests to your web applications are inspected for various attacks, and malicious traffic is blocked.
For whom is the CRS intended?
The CRS is aimed at web server administrators. You must run your own web server (Apache, Nginx, or IIS), be able to install web server modules (ModSecurity) and insert custom configuration into your web server (the CRS rule files).
Is there a full tutorial on working with the CRS?
Christian Folini has provided a comprehensive Apache, ModSecurity and CRS tutorial. It details everything about installing and configuring a complete Apache, ModSecurity, and CRS setup. The tutorials on installing ModSecurity, configuring the CRS and handling false positives provide in-depth information on these topics.
What are benefits of using the CRS?
The CRS aims to protect your web applications by blocking a wide range of common attacks. Besides blocking, the audit log will also record attack attempts, allowing you to monitor when an application is under attack. Running the CRS on your own server ensures that you do not have to send your web traffic to a third party WAF provider. The CRS contains many generic attack patterns, which means that many newly discovered web application vulnerabilities are caught automatically without requiring frequent rule updates. Since you can control the configuration, you can adjust the strictness of the CRS to your liking and make fine-grained exceptions to the policy.
What are drawbacks of using the CRS?
The CRS can be quite strict in detecting certain attacks. This means that sometimes a normal, bona fide, request may be blocked as a false alert or false positive, for instance, if it contains suspicious character sequences. We aim to minimize false positives as much as possible, but in some situations it may be necessary for you to write an exclusion rule which selectively disables some CRS checks. CRS is updated from time to time in order to address false positives and add new protections, which requires you to replace the files with a new release. Furthermore, the CRS adds some, usually minor, processing overhead to any request.
Does the CRS protect against all vulnerabilities?
No, the CRS scans only for generic, commonly occurring, malicious patterns. Application-specific vulnerabilities, such as logic bugs or missing authorization checks, cannot be detected by generic firewall rules. The CRS is therefore not a replacement for patching web applications. To increase your protection against current web application vulnerabilities, you can combine the CRS with a commercial rule set such as the Trustwave ModSecurity Rules. Such a rule set contains specific virtual patches for many common web applications.
I represent a project or web application, can the CRS add support for my application?
What is the license of the CRS? Can I use CRS in my product?
The Core Rule Set is free software, distributed under Apache Software License version 2. You can use the CRS in your product, provided you adhere to the terms of the license.