This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Category:OWASP ModSecurity Core Rule Set Project
About
Overview ModSecurity is an Apache web server module that provides a web application firewall engine. The ModSecurity Rules Language engine is extrememly flexible and robust and has been referred to as the "Swiss Army Knife of web application firewalls." While this is certainly true, it doesn't do much implicitly on its own and requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, we have developed the Core Rule Set (CRS) which provides critical protections against attacks across most every web architecture. Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS is based on generic rules which focus on attack payload identification in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded. Why The Core Rule Set? The focus of the core rule set is to be a "rule set" rather than a set of rules. What makes a rule set different than a set of rules?
|
In order to provide generic web applications protection, the Core Rules use the following techniques:
|
Download
https://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/
Bug Tracker
https://www.modsecurity.org/tracker/browse/CORERULES
<form action="/" method="post">
<fieldset> <textarea name="test" rows="6" cols="60"></textarea> </fieldset> <fieldset> <input type="checkbox" id="html" name="html" /> <label for="html">Harmless HTML is allowed</label> </fieldset> <fieldset> <input type="checkbox" id="json" name="json" /> <label for="json">Input is JSON encoded</label> </fieldset> <fieldset> <input id="submit" type="submit" value="Send" /> </fieldset> </form>
Installation
Quick Start
Core Rule Set Structure & Usage
========================
To activate the rules for your web server installation:
1) The modsecurity_crs_10_global_config.conf file includes directives that can only be initiated once by Apache and thus this should be included within the main httpd.conf file context.
The modsecurity_crs_10_config.conf, on the other hand, includes directives that can be included within virtual host containers. Pay attention to the SecRuleEngine setting (On by default) and that the SecDefaultAction directive is set to "pass". All of the rules use the "block" action which inherits this setting. The effectively means that you can toggle the SecDefaultAction setting to decide if you would like to deny on a rule match or if you want to run in anomaly scoring/correlation mode (which is the new default).
Should also update the appropriate anomaly scoring level in the modsecurity_crs_49_enforcement.conf and modsecurity_crs_60_correlation.conf files. This will determine when you log and block events.
Additionally you may want to edit modsecurity_crs_30_http_policy.conf
2) Add the following line to your httpd.conf (assuming you've placed the rule files into conf/modsecurity/):
Include conf/modsecurity/*.conf Include conf/modsecurity/base_rules/*conf
3) Restart web server.
4) Make sure your web sites are still running fine.
5) Simulate an attack against the web server. Then check the attack was correctly logged in the Apache error log, ModSecurity debug log (if you enabled it) and ModSecurity audit log (if you enabled it).
6) If you configured your audit log entries to be transported to ModSecurity Console in real time, check the alert was correctly recorded there too.
Documentation
- New Rules & Features:
- Use of Block Action
Updated the rules to use the "block" action. This allows the Admin to globally set the desired block action once with SecDefaultAction in the *10* config file rather than having to edit the disruptive actions in all of the rules or for the need to have multiple versions of the rules (blocking vs. non-blocking).
- Fine Grained Policy
The rules have been split to having one signature per rule instead of having all signatures combined into one optimized regular expression. This should allow you to modify/disable events based on specific patterns instead of having to deal with the whole rule.
- Anomaly Scoring Mode Option
The rules have been updated to include anomaly scoring variables which allow you to evaluate the score at the end of phase:2 and phase:5 and decide on what logging and disruptive actions to take based on the score.
- Correlated Events
There are rules in phase:5 that will provide some correlation between inbound events and outbound events and will provide a result of successful atttack or attempted attack.
- Updated Severity Ratings
The severity ratings in the rules have been updated to the following: - 0: Emergency - is generated from correlation where there is an inbound attack and an outbound leakage. - 1: Alert - is generated from correlation where there is an inbound attack and an outbound application level error. - 2: Critical - is the highest severity level possible without correlation. It is normally generated by the web attack rules (40 level files). - 3: Error - is generated mostly from outbound leakabe rules (50 level files). - 4: Warning - is generated by malicious client rules (35 level files). - 5: Notice - is generated by the Protocol policy and anomaly files. - 6: Info - is generated by the search engine clients (55 marketing file).
- Converted Snort Rules
Emerging Threat web attack rules have been converted. http://www.emergingthreats.net/
- CRS Rules Files
modsecurity_crs_10_config.conf modsecurity_crs_10_global_config.conf
./base_rules: modsecurity_40_generic_attacks.data modsecurity_41_sql_injection_attacks.data modsecurity_46_et_sql_injection.data modsecurity_46_et_web_rules.data modsecurity_50_outbound.data modsecurity_crs_20_protocol_violations.conf modsecurity_crs_21_protocol_anomalies.conf modsecurity_crs_23_request_limits.conf modsecurity_crs_30_http_policy.conf modsecurity_crs_35_bad_robots.conf modsecurity_crs_40_generic_attacks.conf modsecurity_crs_41_sql_injection_attacks.conf modsecurity_crs_41_xss_attacks.conf modsecurity_crs_45_trojans.conf modsecurity_crs_46_et_sql_injection.conf modsecurity_crs_46_et_web_rules.conf modsecurity_crs_47_common_exceptions.conf modsecurity_crs_48_local_exceptions.conf modsecurity_crs_49_enforcement.conf modsecurity_crs_50_outbound.conf modsecurity_crs_60_correlation.conf
./optional_rules: modsecurity_crs_42_comment_spam.conf modsecurity_crs_42_tight_security.conf modsecurity_crs_55_marketing.conf
./util: httpd-guardian.pl modsec-clamscan.pl runav.pl
Presentations and Whitepapers
Ofer Shezaf's presentation and whitepaper on the Core Rule Set for the latest version of ModSecurity presented at 6th OWASP AppSec conference in Milan, Italy, in May 2007
Related Projects
ModSecurity-Open Source Web Application Firewall
OWASP Securing WebGoat using ModSecurity
Latest News and Mail List
Current Stable Version CRS 2.0.2
Version 2.0.2 - 09/11/2009
Improvements: - Added converted PHPIDS signatures (https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml)
https://www.modsecurity.org/tracker/browse/CORERULES-13
Bug Fixes: - Rule 958297 - Fixed Comment SPAM UA false positive that triggered only on mozilla.
https://www.modsecurity.org/tracker/browse/CORERULES-15
Project Mail List
Subscribe here
Use here
Contributors, Users and Adopters
Project Leader
Project Contributors
The Core Rule Set (CRS) project is sponsored by:
Project Details
PROJECT INFORMATION | |||||||
---|---|---|---|---|---|---|---|
Project Name | OWASP ModSecurity Core Rule Set Project | ||||||
Short Project Description |
The purpose of this project is the documentation and development of the ModSecurity Core Rule Set. Unlike intrusion detection and prevention systems, which rely on signature specific to known vulnerabilities, the Core Rules are 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. | ||||||
Key Project Information |
Project Leader |
Project Contibutors |
Mailing List |
License |
Project Type |
Sponsor |
Release Status | Main Links | Related Projects |
---|---|---|
add here. |
ModSecurity-Open Source Web Application Firewall |
The CRS is an open source rule set licensed under GPLv2. ModSecurity Core Rule Set works with ModSecurity 2.5 and above.
Pages in category "OWASP ModSecurity Core Rule Set Project"
The following 16 pages are in this category, out of 16 total.
M
O
- OWASP ModSec CRS Paranoia Mode
- OWASP ModSec CRS Paranoia Mode Sibling 950001
- OWASP ModSec CRS Paranoia Mode Sibling 950907
- OWASP ModSec CRS Paranoia Mode Sibling 958977
- OWASP ModSec CRS Paranoia Mode Sibling 958980
- OWASP ModSec CRS Paranoia Mode Sibling 960901
- OWASP ModSec CRS Paranoia Mode Sibling 970003
- OWASP ModSec CRS Paranoia Mode Sibling 981049
- OWASP ModSec CRS Paranoia Mode Sibling 981172
- OWASP ModSec CRS Paranoia Mode Sibling 981173
- OWASP ModSecurity rule evaluation framework