FAQs

The OWASP 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.

ModSecurity is an open source Web Application Firewall (WAF). It can be installed as a module inside the Apache, Nginx or IIS web servers.

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.

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).

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.

The CRS aims to protect your web applications by detecting a wide range of common attacks, such as SQL injections. 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.

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.

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.

The Paranoia Level (PL) setting in crs-setup.conf allows you to choose the desired level of rule checks. You can adjust the Paranoia Level on a per-website basis, by copying rule 900000 from the crs-setup.conf file into the respective <VirtualHost> section of your webserver configuration (giving it a new rule id).

With each paranoia level increase, the CRS enables additional rules, giving you a higher level of security. However, higher paranoia levels also increase the possibility of blocking some legitimate traffic due to false alarms (also named false positives or FPs). If you use higher paranoia levels, it is likely that you will need to add some exclusion rules for certain applications that need to receive complex input patterns.

• A paranoia level of 1 (PL1) is default. In this level, most core rules are enabled. PL1 is advised for beginners, installations covering many different sites and applications, and for setups with standard security requirements. At PL1 you should face FPs rarely, and therefore it is recommended for all sites and applications. If you encounter FPs, please open an issue on the CRS GitHub site. Don’t forget to attach your complete Audit Log record containing the request with the issue. Be sure to scrub any personal data and sensitive information!
• Paranoia level 2 (PL2) includes many extra rules, for instance enabling many regexp-based SQL and XSS injection protections, and adding extra keywords checked for code injections. PL2 includes some rules which were present by default in CRS 2.x, but excluded in the default level in CRS 3.x because of common false positive complaints. Nevertheless, these rules will add extra protection against advanced and obfuscated attacks which may evade the rules of PL1. PL2 is advised for moderate to experienced users who desire more complete coverage, and for all installations with elevated security requirements. PL2 may also be a good choice for existing CRS 2.x users, as the level of FPs will be comparable to a CRS 2.x installation. PL2 may cause some FPs which you need to handle.
• Paranoia level 3 (PL3) enables more rules and keyword lists that cover less common attacks. PL3 also tweaks limits on all special characters used, which provides high coverage against unknown attack types, obfuscated attacks and attempted WAF bypasses. PL3 is aimed at users who are experienced at the handling of FPs and at installations with high security requirements. PL3 may regularly cause FPs which you need to handle.
• Paranoia level 4 (PL4) further restricts special characters. PL4 is advised for experienced users protecting installations with very high security requirements. Running PL4 will likely produce a very high number of FPs which have to be treated before the site can go productive.

We are interested in improving support for popular web applications. Some types of applications, like content management systems, tend to produce false alerts in administration panels, as administrators submit complex HTML, CSS and JavaScript, which tends to trigger various rules in the CRS. We would like to minimize these by shipping default exclusion profiles for these applications, which can optionally be enabled by the user. Create an issue on GitHub if you are interested in working with us to create and test such a profile.

Yes! As a project in order to support activities like summits, hackathons, and speaking at conferences we need sponsors. If you appreciate the work we do, or you use it heavily, you should consider sponsoring. If you are interested, please get in touch with CRS Co-Lead Christian Folini via christian.folini /at/ netnea.com. He is in charge of sponsoring contacts.

This error can happen when you are using ModSecurity 3.0.0 to 3.0.2. Support for the URLENCODED body processor was only added in ModSecurity 3.0.3. Please upgrade your ModSecurity to at least 3.0.3.

From CRS 3.2.2, 3.3.3 and up, ModSecurity 2.9.6 or 3.0.8 (or versions with backported patches) are required due to the addition of new protections. We recommend upgrading your ModSecurity as soon as possible. If your ModSecurity is too old, your webserver will refuse to start with an Unknown variable: &MULTIPART_PART_HEADERS error. If you are in trouble, you can temporarily delete file rules/REQUEST-922-MULTIPART-ATTACK.conf as a workaround and get your server up, however, you will be missing some protections. Therefore we recommend to upgrade ModSecurity before deploying a new CRS release.

The CRS 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.