ModSecurity Core Rules

Overview

ModSecurity is a web application firewall engine. Being the Swiss army knife of application firewalls it can do everything but requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, ModSecurity includes the Core Rule Set, an open source rule set licensed under GPLv2. ModSecurity Core Rule Set works with ModSecurity 2.1 and above.

Unlike intrusion detection and prevention systems, which rely on signature specific to known vulnerabilities, the Core Rules is based on generic rules in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded.

As a generic negative security rule set, the Core Rule Set is only one layer in your application protection. You can learn more about the pros and cons of a negative security model in the presentation “The Core Rule Set: Generic detection of application layer”, presented at OWASP Europe 2007. In addition to the Core Rule Set you may want to harden your Apache installation, for which you can consult Ivan Ristic's book, Apache Security. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. Breach Security can provide you with training and professional services to assist you in doing that. On additional methodologies which complement the Core Rule Set including positive security and virtual patching you can read in Ryan Barnett’s book, Preventing Web Attacks with Apache

Why The Core Rule Set?

• Performance - The Core Rule Set is optimized for performance. The amount and content of the rules used predominantly determines the performance impact of ModSecurity, so the performance optimization of the rule set is very important.
• Quality - While there will always be false positives, a lot of effort is put into trying to make the Core Rule Set better. Some of the things done are:
• Regression tests - a regression test is used to ensure that every new version shipped does not break anything. Actually every report of a false positive, once solved, gets into the regression test.
• Real traffic testing – A large amount of real world capture files have been converted to tests and sent through ModSecurity to detect potential false positives.
• Generic Detection - The core rule set is tuned to detect generic attacks and does not include specific rules for known vulnerabilities. Due to this feature the core rule set has better performance, is more "plug and play" and requires less updates.
• Event Information - Each rule in the Core Rule Set has a unique ID and a textual message. In the future rules are also going to be classified using a new tag action in ModSecurity, as well as longer information regarding each rule using comments in the files themselves.
• Plug and Play – The Core Rule Set is designed to be as plug and play as possible. Since its performance is good and it employs generic detection, and since the number of false positives is getting lower all the time, the Core Rule Set can be installed as is with little twisting and tweaking.

Quick Start

• Extract the Core Rule Set content into a directory called modsecurity under your Apache configuration directory.
• Edit and customize modsecurity_crs_10_config.conf. This file contains comments which explain how to set up each directive. You may also want to edit modsecurity_crs_30_http_policy.conf which sets rules specific to your application.
• Add the directive Include conf/modsecurity/*.conf to your httpd.conf after the line where ModSecurity itself it loaded.
• Restart Apache.
• Check that the server works normally, and simulate an attack by browsing to the URL http://yourhost/cmd.exe. Instead of a “page not found” error, you should get a “Method Not Implemented” error.

Content

Protocol compliance:

• HTTP request validation - This first line of protection ensures that all abnormal HTTP requests are detected. This line of defense eliminates a large number of automated and non targeted attacks as well as protects the web server itself.
• HTTP protocol anomalies - Common HTTP usage patterns are indicative of attacks.
• Global constraints - Limiting the size and length of different HTTP protocol attributes, such as the number and length of parameters and the overall length of the request. Ensuring that these attributed are constrained can prevent many attacks including buffer overflow and parameter manipulation.
• HTTP Usage policy – validate requests against a predefined policy, setting limitations request properties such as methods, content types and extensions.

Attack Detection:

• Malicious client software detection - Detect requests by malicious automated programs such as robots, crawlers and security scanners. Malicious automated programs collect information from a web site, consume bandwidth and might also search for vulnerabilities on the web site. Detecting malicious crawlers is especially useful against comments spam.
• Generic Attack Detection - Detect application level attacks such as described in the OWASP top 10. These rules employ context based patterns match over normalized fields. Detected attacks include:
• SQL injection and Blind SQL injection.
• Cross Site Scripting (XSS).
• OS Command Injection and remote command access.
• File name injection.
• ColdFusion, PHP and ASP injection.
• E-Mail Injection
• HTTP Response Splitting.
• Universal PDF XSS.
• Trojans & Backdoors Detection - Detection of attempts to access Trojans & backdoors already installed on the system. This feature is very important in a hosting environment when some of this backdoors may be uploaded in a legitimate way and used maliciously.

Other:

• Error Detection - Prevent application error messages and code snippets from being sent to the user. This makes attacking the server much harder and is also a last line of defense if an attack passes through.
• XML Protection – The Core Rule Set can be set to examine XML payload for most signatures.
• Search Engine Monitoring - Log access by search engines crawlers to the web site.

Handling False Positives

Every Rule Set can have false positive when installed in new environments. Therefore every new installation should be put in monitoring mode for an initial period of time as outlined in the quick start section.

An alert triggered for a valid request is called a false positive and requires a rule to be written in order to prevent such false positives in the future. Such a rule is referred to as an exception. The article “Handling False Positives and Creating Custom Rules” discuss creating such exceptions.

Keep in mind that a false positive may be specific to your application but might also be common to all applications and require a modification to the Core Rule Set. If you think the later is the case, we would love to hear about it so we can fix. Just send an audit log record of the false positive either directly to us at security@modsecurity.org or to the ModSecurity mailing list.