|
|
| (221 intermediate revisions by 11 users not shown) |
| Line 1: |
Line 1: |
| − | <br> | + | =Main= |
| | + | <div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div> |
| | + | {| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |- |
| | + | | valign="top" style="border-right: 1px dotted gray;padding-right:25px;" | |
| | | | |
| − | ==== About ==== | + | ==OWASP ModSecurity Core Rule Set (CRS)== |
| | | | |
| − | <table width="100%" valign="top"><tr><th width="50%"> </th><th> </th></tr><tr valign="top"><td>
| + | '''The 1st Line of Defense Against Web Application Attacks''' |
| − | [[Image:ModSecuriity.JPG|200px|right]]
| |
| − | '''Overview''' | |
| | | | |
| − | [http://www.modsecurity.org/ 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. | + | {| style="width: 100%;" |
| | + | | style="vertical-align:top;" | The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with [https://modsecurity.org ModSecurity] or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the [[Top10|OWASP Top Ten]], with a minimum of false alerts. The CRS provides protection against many common attack categories, including SQL Injection, Cross Site Scripting, Locale File Inclusion, etc. |
| | | | |
| − | 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.
| + | [[File:CRS-logo-full_size-512x257.png|512px|link=https://coreruleset.org]] |
| | | | |
| − | '''Why The Core Rule Set?''' | + | '''The offical website of the project can be found at [https://coreruleset.org https://coreruleset.org]. |
| | | | |
| − | 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.
| + | | style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]] |
| − | *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.
| |
| | | | |
| − | </td><td>
| + | ==Getting Started / Tutorials== |
| − | ;
| |
| − | <br>'''Content'''
| |
| | | | |
| − | In order to provide generic web applications protection, the Core Rules use the following techniques:
| + | The following tutorials will get you started with ModSecurity and the CRS v3. |
| − | *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.
| |
| | | | |
| − | </td></tr>
| + | * [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity] |
| − | </table>
| + | * [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set] |
| | + | * [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set] |
| | | | |
| − | ==== Download ====
| + | These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]]. |
| − | https://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/ | |
| | | | |
| − | ==== Bug Tracker ====
| + | More Information about the rule set is available at the official website, [https://coreruleset.org https://coreruleset.org]. |
| − | https://www.modsecurity.org/tracker/browse/CORERULES | |
| | | | |
| − | <form action="/" method="post">
| + | ==Licensing== |
| − | <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>
| |
| | | | |
| | + | OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one. |
| | | | |
| − | ==== Installation ==== | + | == Reporting Issues == |
| − | '''Quick Start'''
| |
| | | | |
| − | Core Rule Set Structure & Usage
| + | * If you think you've found a false positive in commercially available software and want us to take a look, submit an issue on [https://github.com/SpiderLabs/owasp-modsecurity-crs/ our Github] |
| − | ====================================
| + | |
| | | | |
| − | To activate the rules for your web server installation:
| |
| | | | |
| − | 1) The modsecurity_crs_10_global_config.conf file includes directives that
| + | == Project Sponsors == |
| − | 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
| + | {| class="wikitable" |
| − | 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
| + | ! Trustwave !! Avi Networks || cPanel, Inc |
| − | files. This will determine when you log and block events.
| + | |- |
| | + | | [[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]] || [[Image:Avi_Networks.jpg|200px|link=https://avinetworks.com/]] || [[Image:CPanel logo.svg.png|200px|link=https://cpanel.com/]] |
| | + | |} |
| | | | |
| − | Additionally you may want to edit modsecurity_crs_30_http_policy.conf
| + | | valign="top" style="padding-left:25px;width:200px;" | |
| | | | |
| − | 2) Add the following line to your httpd.conf (assuming
| + | == Website == |
| − | you've placed the rule files into conf/modsecurity/):
| |
| | | | |
| − | Include conf/modsecurity/*.conf
| + | [https://coreruleset.org https://coreruleset.org] |
| − | Include conf/modsecurity/base_rules/*conf
| |
| | | | |
| − | 3) Restart web server.
| + | == Social Channels == |
| | | | |
| − | 4) Make sure your web sites are still running fine.
| + | [https://twitter.com/coreruleset?lang=en Twitter @CoreRuleSet] |
| | | | |
| − | 5) Simulate an attack against the web server. Then check
| + | [https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mailing List] |
| − | 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
| + | == Project Members == |
| − | to ModSecurity Console in real time, check the alert was
| |
| − | correctly recorded there too.
| |
| | | | |
| − | ==== Documentation ====
| + | Project Leaders: |
| − | *New Rules & Features:
| + | * [[:User:Chaim_sanders|Chaim Sanders]] |
| − | - Use of Block Action
| + | * [[:user:Dune73|Christian Folini]] |
| − | Updated the rules to use the "block" action. This allows the Admin to globally
| + | * [[:User:lifeforms|Walter Hop]] |
| − | set the desired block action once with SecDefaultAction in the *10* config file
| + | Contributors: |
| − | rather than having to edit the disruptive actions in all of the rules or for
| + | * Christoph Hansen |
| − | the need to have multiple versions of the rules (blocking vs. non-blocking).
| + | * Felipe 'Zimmerle' Costa |
| − | - Fine Grained Policy
| + | * Franziska Bühler |
| − | The rules have been split to having one signature per rule instead of having
| + | * Victor Hora |
| − | all signatures combined into one optimized regular expression.
| + | * Federico Schwindt |
| − | This should allow you to modify/disable events based on specific patterns
| + | * Felipe Zipitría |
| − | instead of having to deal with the whole rule.
| + | * Manuel Spartan |
| − | - 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
| + | == Quick Download == |
| − | [[modsecurity_crs_10_config.conf | modsecurity_crs_10_config.conf]]
| |
| − | modsecurity_crs_10_global_config.conf
| |
| | | | |
| − | ./base_rules:
| + | [https://coreruleset.org/installation/ Installation Tutorial] |
| − | 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:
| + | [https://hub.docker.com/r/owasp/modsecurity-crs/ Docker Image] |
| − | modsecurity_crs_42_comment_spam.conf
| |
| − | modsecurity_crs_42_tight_security.conf
| |
| − | modsecurity_crs_55_marketing.conf
| |
| | | | |
| − | ./util:
| + | == Source Code Repo == |
| − | httpd-guardian.pl
| |
| − | modsec-clamscan.pl
| |
| − | runav.pl
| |
| | | | |
| | + | [https://github.com/SpiderLabs/owasp-modsecurity-crs GitHub Project] |
| | | | |
| − | ==== Presentations and Whitepapers ==== | + | == News and Events == |
| − | Ofer Shezaf's [http://www.owasp.org/images/2/21/OWASPAppSec2007Milan_ModSecurityCoreRuleSet.ppt presentation] and [https://www.owasp.org/images/0/07/OWASP6thAppSec_ModSecurityCoreRuleSet_OferShezaf.pdf 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 ====
| + | We publish a monthly newsletter on the official website at [https://coreruleset.org/ https://coreruleset.org] |
| − | [http://www.modsecurity.org/ ModSecurity-Open Source Web Application Firewall]<br>[[:Category:OWASP Securing WebGoat using ModSecurity Project|OWASP Securing WebGoat using ModSecurity]] | |
| | | | |
| | + | ==Classifications== |
| | | | |
| − | ==== Latest News and Mail List ==== | + | {| width="200" cellpadding="2" |
| − | '''Current Stable Version CRS 2.0.2'''
| + | |- |
| | + | | align="center" valign="top" width="50%" rowspan="2"| [[File:Owasp-flagship-trans-85.png|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]] |
| | + | | align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]] |
| | + | |- |
| | + | | colspan="2" align="center" width="50%" | [http://www.apache.org/licenses/LICENSE-2.0.html License: ASLv2] |
| | + | |- |
| | + | | colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]] |
| | + | |} |
| | | | |
| − | --------------------------
| + | ==Donate== |
| − | Version 2.0.2 - 09/11/2009
| + | <paypal>ModSecurity Core Rule Set Project</paypal> |
| − | --------------------------
| |
| | | | |
| − | 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:
| + | __NOTOC__ <headertabs /> |
| − | - Rule 958297 - Fixed Comment SPAM UA false positive that triggered only on mozilla.
| |
| − | https://www.modsecurity.org/tracker/browse/CORERULES-15
| |
| | | | |
| − | | + | [[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]] |
| − | '''Project Mail List'''<br>[ https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set Subscribe here]<br>[ mailto: [email protected] Use here] | |
| − | | |
| − | ==== Contributors, Users and Adopters ====
| |
| − | '''Project Leader'''
| |
| − | | |
| − | [[:User:Rcbarnett|Ryan Barnett]]
| |
| − | | |
| − | '''Project Contributors'''
| |
| − | | |
| − | [[:User:Brectanus|Brian Rectanus]]
| |
| − | | |
| − | '''The Core Rule Set (CRS) project is sponsored by:'''
| |
| − | <br>
| |
| − | [http://www.breach.com/resources/breach-security-labs/index.html http://www.owasp.org/images/5/56/BreachSecurityLabs.jpg]
| |
| − | <br>
| |
| − | | |
| − | ==== Project Details ====
| |
| − | {{:Key Project Information:OWASP ModSecurity Core Rule Set Project}}
| |
| − | | |
| − | __NOTOC__
| |
| − | <headertabs/>
| |
| − | | |
| − | ''The CRS is an open source rule set licensed under GPLv2. ModSecurity Core Rule Set works with ModSecurity 2.5 and above.''
| |
| − | | |
| − | | |
| − | [[Category:OWASP Project]] | |
| − | [[Category:OWASP Document]] | |
| − | [[Category:OWASP Alpha Quality Document]] | |
