Difference between revisions of "Category:OWASP ModSecurity Core Rule Set Project"

Revision as of 22:01, 11 September 2009 (view source) Rcbarnett (talk | contribs) ← Older edit		Revision as of 16:51, 20 September 2009 (view source) Paulo Coimbra (talk | contribs) Newer edit →
Line 236:		Line 236:
	<br>		<br>
		+	==== Project Details ====
		+	{{:Key Project Information:OWASP ModSecurity Core Rule Set Project}}
	__NOTOC__		__NOTOC__
Line 243:		Line 245:
−	{{:Key Project Information:OWASP ModSecurity Core Rule Set Project}}
	[[Category:OWASP Project]]		[[Category:OWASP Project]]
	[[Category:OWASP Document]]		[[Category:OWASP Document]]
	[[Category:OWASP Alpha Quality Document]]		[[Category:OWASP Alpha Quality Document]]

---

Revision as of 16:51, 20 September 2009

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

Content In order to provide generic web applications protection, the Core Rules use the following techniques: 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 these 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.

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

Ryan Barnett

Project Contributors

Brian Rectanus

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 Ryan Barnett	Project Contibutors Brian Rectanus (add account link, please)	Mailing List Subscribe here Use here	License GNU General Public License	Project Type Document	Sponsor

Release Status	Main Links	Related Projects
Apha Quality Please see here for complete information.	add here.	ModSecurity-Open Source Web Application Firewall OWASP Securing WebGoat using ModSecurity

---

The CRS is an open source rule set licensed under GPLv2. ModSecurity Core Rule Set works with ModSecurity 2.5 and above.