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

From OWASP
Jump to: navigation, search
m (OWASP ModSecurity Core Rule Set (CRS))
(added a link)
(45 intermediate revisions by 2 users not shown)
Line 5: Line 5:
  
 
==OWASP ModSecurity Core Rule Set (CRS)==
 
==OWASP ModSecurity Core Rule Set (CRS)==
 +
 +
'''The 1st Line of Defense Against Web Application Attacks'''
  
 
The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.
 
The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application.
Line 10: Line 12:
 
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 aims to protect web applications from a wide range of attacks, including the [[Top10|OWASP Top Ten]], with a minimum of false alerts.
  
==Introduction==
+
More information at [https://modsecurity.org/crs https://modsecurity.org/crs].
 +
 
 +
==Description==
 +
 
 +
{| style="width: 100%;"
 +
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
 +
* SQL Injection (SQLi)
 +
* Cross Site Scripting (XSS)
 +
* Local File Inclusion (LFI)
 +
* Remote File Inclusion (RFI)
 +
* Remote Code Execution (RCE)
 +
* PHP Code Injection
 +
* HTTP Protocol Violations
 +
* Shellshock
 +
* Session Fixation
 +
* Scanner Detection
 +
* Metadata/Error Leakages
 +
* Project Honey Pot Blacklist
 +
* GeoIP Country Blocking
 +
 
 +
More Information at [https://modsecurity.org/crs https://modsecurity.org/crs].
 +
 
 +
| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
 +
|}
 +
 
 +
==Getting Started / Tutorials==
  
The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform [http://www.modsecurity.org/ ModSecurity] Web Application Firewall (WAF).
+
The following tutorials will get you started with ModSecurity and the CRS v3.
 +
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
 +
* [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]
  
==Description==
+
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]].
  
The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
+
More Information about the rule set at [https://modsecurity.org/crs https://modsecurity.org/crs] and a full list of all the rules in the Core Rule Set at [https://netnea.com/crs https://netnea.com/crs].
*HTTP Protection - detecting violations of the HTTP protocol and a locally defined usage policy.
 
*Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
 
*HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
 
*Common Web Attacks Protection - detecting common web application security attack.
 
*Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
 
*Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
 
*Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
 
*Trojan Protection - Detecting access to Trojans horses.
 
*Identification of Application Defects - alerts on application misconfigurations.
 
*Error Detection and Hiding - Disguising error messages sent by the server.
 
  
 
==Licensing==
 
==Licensing==
 
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.
 
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.
  
==Open HUB==
+
| valign="top"  style="padding-left:25px;width:200px;" |
https://www.openhub.net/p/owasp-modsecurity-crs
 
  
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
 
  
== What is OWASP ModSecurity CRS? ==
 
  
OWASP ModSecurity CRS provides
+
== Project Members ==
* the '''1st line of defense against web application attacks''' like the [[Top10 | OWASP Top Ten]].
+
 
 +
Project Leaders:
 +
* [[:User:Chaim_sanders|Chaim Sanders]]
 +
* [[:user:Dune73|Christian Folini]]
 +
* [[:User:lifeforms|Walter Hop]]
 +
Contributors:
 +
* Christoph Hansen
 +
* Felipe 'Zimmerle' Costa
 +
* Franziska Bühler
 +
* Victor Hora
  
 
== Presentation ==
 
== Presentation ==
Line 45: Line 71:
 
*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
 
*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
 
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]
 
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]
 
== Project Leader ==
 
 
Project Leader:
 
* [https://www.owasp.org/index.php/User:Chaim_sanders Chaim Sanders]
 
 
Contributors:
 
*[[:User:Rcbarnett|Ryan Barnett]]<br>
 
*[[:user:Dune73|Christian Folini]]<br>
 
*[[:User:lifeforms|Walter Hop]]<br>
 
  
 
== Related Projects ==
 
== Related Projects ==
Line 62: Line 78:
 
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]
 
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]
  
| valign="top"  style="padding-left:25px;width:200px;" |
+
== Quick Download ==
  
== Quick Download ==
+
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]
  
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)] (FIXME)
+
| valign="top"  style="padding-left:25px;width:200px;" |
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)] (FIXME)
 
  
 
== Source Code Repo ==
 
== Source Code Repo ==
Line 74: Line 90:
  
 
== News and Events ==
 
== News and Events ==
* [10 Nov 2016] - CRS3 Released (FIXME: Link to announcement)
+
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]
  
 
== Mailing List ==
 
== Mailing List ==
Line 97: Line 113:
 
|}
 
|}
  
=FAQs=
+
=Getting Started=
  
== Who Leads the ModSecurity Project? ==
+
The following tutorials will get you started with ModSecurity and the CRS v3.
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
+
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
+
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
*Felipe Zimmerle Costa - ModSecurity Lead Developer
+
* [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]
  
Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [http://lists.sourceforge.net/lists/listinfo/mod-security-users].
+
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]].
  
== Background and Support ==
+
More Information at [https://modsecurity.org/crs https://modsecurity.org/crs].
  
=== What exactly is ModSecurity? ===
+
=FAQs=
 
 
ModSecurity™is an open source, free web application firewall (WAF) Apache module. With over 70% of all attacks now carried out over the web application level, organizations need all the help they can get in making their systems secure. WAFs are deployed to establish an external security layer that increases security, detects and prevents attacks before they reach web applications. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure.
 
 
 
=== Where do I get more help on ModSecurity? ===
 
 
 
The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.
 
 
 
==== Open Source/Free Help ====
 
*ModSecurity Users Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-users
 
*ModSecurity Developers Mail-list (SourceForge) - http://lists.sourceforge.net/lists/listinfo/mod-security-developers
 
*OWASP ModSecurity Core Rules Mail-list (OWASP) - https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
 
*You can also join the #modsecurity channel on irc.freenode.net.
 
==== Commercial Help ====
 
*Commercial Support through Trustwave's Technical Assistance Center (TAC) - https://www3.trustwave.com/modsecurity-rules-support.php
 
*Professional Services offer by Trustwave SpiderLabs Research Team
 
*ModSecurity Training
 
 
 
=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===
 
 
 
Yes, only subscribers are able to post messages. As mentioned in the previous section, you will need to visit the mail-list website to register.
 
 
 
=== Is there anything that I should do prior to sending emails to the mail-list? ===
 
 
 
Yes. There is a good chance that the issue you are facing has already been discussed and, most likely, a fix has already been presented. You can review the mail-list archive online at the ModSecurity project site on SourceForge. You can also use the Search interface available for topic threads that are archived to the various mirror sites. For example, if you had a question about Exceptions and ModSecurity, you could use the following search to find past mail-list threads on this topic. If you can not find an answer to your question after doing some research, you should then send an email to the mod-security-users mail-list.
 
 
 
=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===
 
 
 
The open source mod-security-users mail-list is "best effort" support meaning that we will aspire to respond to emails as quickly as possible however the actual response time may vary depending on factors such as time of day, time of week and complexity of the question. If your email is sent on the week-end or if your question involves setting up test systems, unique configurations or interactions with a custom application then it may take some time to respond.
 
 
 
=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===
 
 
 
No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.
 
 
 
=== Where can I find books about Web Application Firewalls and ModSecurity? ===
 
 
 
==== ModSecurity Handbook ====
 
ModSecurity Handbook is "The definitive guide to the popular open source web application firewall", written by Ivan Ristic (original author of ModSecurity). The book is available from Feisty Duck in hard copy or with immediate access to the digital version which is continually updated.
 
 
 
==== Web Application Defender's Cookbook: Battling Hackers and Defending Users ====
 
The Web Application Defender's Cookbook: Battling Hackers and Protecting Users is a book written by the ModSecurity Project Lead and OWASP ModSecurity Project Lead Ryan Barnett. The book outlines critical defensive techniques to protect web applications and includes example ModSecurity rules/scripts.
 
 
 
==== ModSecurity 2.5 ====
 
ModSecurity 2.5 is "A complete guide to using ModSecurity", written by Magnus Mischel. The book is available from Packt Publishing in both hard copy and digital forms.
 
 
 
==== Apache Security ====
 
Apache Security is a comprehensive Apache Security resource, written by Ivan Ristic for O'Reilly. Two chapters (Apache Installation and Configuration and PHP) are available as free download, as are the Apache security tools created for the book.
 
 
 
==== Preventing Web Attacks with Apache ====
 
Preventing Web Attacks with Apache. Building on his groundbreaking SANS presentations on Apache security, Ryan C. Barnett reveals why your Web servers represent such a compelling target, how significant exploits are performed, and how they can be defended against.
 
 
 
== Getting Started ==
 
 
 
=== What type(s) of security models does ModSecurity support? ===
 
 
 
There is a common misconception that ModSecurity can only be used for negative policy enforcement. This is not the case. ModSecurity does not have any default security model "out-of-the-box." It is up to the user to implement appropriate rules to achieve the desired security model. That being said, these are the security models which are most often employed:
 
 
 
*Negative Security Model - looks for known bad, malicious requests. This method is effective at blocking a large number of automated attacks, however it is not the best approach for identifying new attack vectors. Using too many negative rules may also negatively impact performance.
 
 
 
*Positive Security Model - When positive security model is deployed, only requests that are known to be valid are accepted, with everything else rejected. This approach works best with applications that are heavily used but rarely updated.
 
 
 
*Virtual Patching - Its rule language makes ModSecurity an ideal external patching tool. External patching is all about reducing the window of opportunity. Time needed to patch application vulnerabilities often runs to weeks in many organizations. With ModSecurity, applications can be patched from the outside, without touching the application source code (and even without any access to it), making your systems secure until a proper patch is produced.
 
 
 
*Extrusion Detection Model - ModSecurity can also monitor outbound data and identify and block information disclosure issues such as leaking detailed error messages or Social Security Numbers or Credit Card Numbers.
 
 
 
=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===
 
 
 
There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:
 
 
 
In order to use the OWASP ModSecurity Core Rules, you must use the 2.x version of ModSecurity as it takes advantage of specific features not available in previous versions.
 
 
 
Five processing phases (where there were only two in 1.9.x). These are: request headers, request body, response headers, response body, and logging. Those users who wanted to do things at the earliest possible moment can do them now.
 
 
 
Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.
 
 
 
Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.
 
 
 
Data persistence (can be configured any way you want although most people will want to use this feature to track IP addresses, application sessions, and application users).
 
 
 
Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).
 
 
 
Support for web applications and session IDs.
 
 
 
Regular Expression back-references (allows one to create custom variables using transaction content).
 
 
 
There are now many functions that can be applied to the variables (where previously one could only use regular expressions).
 
 
 
XML support (parsing, validation, XPath).
 
 
 
For more information, it is suggested that you review the SecurityFocus interview that Ivan Ristic gave on ModSecurity 2.0 as it outlines these new features in more detail.
 
 
 
=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===
 
 
 
Due to the many changes in the ModSecurity 2.0 rules language, you can not directly use existing rulesets. You will need to translate the functionality of any custom rules into the new rules language. A migration matrix is available here [http://www.modsecurity.org/documentation/ModSecurity-Migration-Matrix.pdf] that will assist with this process.
 
 
 
=== How do I install ModSecurity 2.0? ===
 
 
 
The installation procedures for installing ModSecurity 2.5 has changed from previous versions. It now includes a configure script that should help to identify all local settings. After running configure, you then run the make and make install commands. You no longer use apxs directly.
 
 
 
=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===
 
 
 
The term "embedded" simply refers to the fact that ModSecurity, running as an Apache module, is running inside the webserver process. Most WAFs function as totally separate hosts and sit in front of the web servers. Running in embedded-mode has some advantages and disadvantages that should be considered:
 
 
 
*Advantages
 
Easy to add to an existing Apache server.
 
 
 
Not a point of failure with respect to traffic.
 
 
 
*Disadvantages
 
ModSecurity can only protect the local web server.
 
 
 
ModSecurity will consume local resources such as CPU and RAM.
 
 
 
Management of log files and configurations can become difficult if you have multiple installations.
 
 
 
=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===
 
 
 
The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.
 
 
 
*Advantages
 
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.
 
 
 
Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.
 
 
 
Increased performance – if SSL accelerators/caching used.
 
 
 
You can implement vulnerability filters to protect and vulnerable web server or application on the back-end (IIS, Netscape, ASP, PHP, etc...). See related section on Virtual Patching.
 
 
 
*Disadvantages
 
A potential traffic bottleneck if the reverse proxy can not handle the network load.
 
 
 
A potential point of failure - if the reverse proxy goes down it may cause a denial of service to the web applications that are behind it.
 
 
 
Requires changes to the network.
 
 
 
== Configuring ModSecurity ==
 
 
 
=== Should I initially set the SecRuleEngine to On? ===
 
 
 
No. Every Ruleset can have false positive in new environments and any new installation should initially use the log only Ruleset version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode.
 
 
 
=== How do I get ModSecurity to inspect request and response bodies? ===
 
 
 
You need to set the the following two directives:
 
 
 
SecRequestBodyAccess On
 
 
 
SecResponseBodyAccess On
 
 
 
=== How can I verify exactly how ModSecurity is processing rules and requests? ===
 
 
 
You need to enable the debug log with SecDebugLog and increase the log level with SecDebugLogLevel. It you set the debug log level to 9, it will tell you exactly what tasks it is completing along with what data it is acting upon. Do be aware that while the increased debug log level does help from a troubleshooting perspective, it does negatively impact performance.
 
  
 
== ModSecurity Rules Language ==
 
== ModSecurity Rules Language ==
Line 278: Line 143:
  
 
In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.
 
In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.
 
=== Can I use the Core Rules with ModSecurity 1.x? ===
 
 
Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.
 
  
 
=== How do I whitelist an IP address so it can pass through ModSecurity? ===
 
=== How do I whitelist an IP address so it can pass through ModSecurity? ===
  
 
The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):
 
The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address):
 
+
background-color: #ffffcc;
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off
+
SecRule REMOTE_ADDR "@ipMatch 192.168.110" id:1,phase:1,nolog,pass,ctl:ruleEngine=Off
  
 
If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -
 
If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -
Line 296: Line 157:
  
 
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off
 
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off
 
=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===
 
 
Yes there are. Many of these differences are outlined in the Migration Matrix document listed previously. Another common rule difference issue that arises is when you want to create white-listed ModSecurity rulesets which enforce that certain headers/variables are both present and not empty. In ModSecurity 1.x, you could create one rule that handles this while in ModSecurity 2.x you would need to write a chained rule.
 
 
On the surface, you might think "The 1.x rules way is better since you only need 1 rule..." however you need to realize that anytime you have rules or directives that implicitly enforce certain capabilities, you run the risk of having false positives as it could match things that you didn't want them to. For instance, what if you have a situation where certain web clients (such as mobile devices) legitimately include some headers, however they are empty? Do you want to automatically block these clients? With the ModSecurity 1.x Rule Language, you would have to remove the entire rule. With the ModSecurity 2.x Rule Language, however, you are able to create rules to more accurately apply the logic that you desire.
 
 
Please refer to the following blog post for more information.
 
  
 
=== How do I handle False Positives and creating Custom Rules? ===
 
=== How do I handle False Positives and creating Custom Rules? ===
Line 313: Line 166:
  
 
Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.
 
Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance.
 
+
background-color: #ffffcc;
 
=== What is a Virtual Patch and why should I care? ===
 
=== What is a Virtual Patch and why should I care? ===
  
Line 335: Line 188:
  
 
= Acknowledgements =
 
= Acknowledgements =
 +
 
== Project Leader ==
 
== Project Leader ==
  
[[:User:Rcbarnett|Ryan Barnett]]
+
[[:User:Chaim_sanders|Chaim Sanders]]
  
 
== Project Contributors ==
 
== Project Contributors ==
  
<br>
+
*[[:User:Chaim_sanders|Chaim Sanders]]
[[:User:Chaim_Sanders|Chaim Sanders]]<br>
+
*[[:user:Dune73|Christian Folini]]
[[:User:Josh Amishav-Zlatin|Josh Zlatin]]<br>
+
*[[:User:lifeforms|Walter Hop]]
[[:User:Brian_Rectanus|Brian Rectanus]]<br>
+
*[[:User:Rcbarnett|Ryan Barnett]]
[[:user:Roberto_Salgado|Roberto Salgado]]<br>
+
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
Nick Galbreath
+
*[[:User:Brian_Rectanus|Brian Rectanus]]
 +
*[[:user:Roberto_Salgado|Roberto Salgado]]
 +
*Nick Galbreath (libinjection)
 +
 
 +
See changelog for more contributors.
  
 
== Project Users ==
 
== Project Users ==
Line 371: Line 229:
 
== Project Sponsors ==
 
== Project Sponsors ==
  
[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
+
[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]
<br>
+
 
 +
= Getting Involved =
 +
 
 +
The CRS project is a small community within the bigger OWASP community. We have a successful project with a wide user base and with the CRS3 release cycle, we have put the development on new feet.
 +
 
 +
We have big plans and there is a need for all sort of contributions from people on a beginner and from people on an expert level alike.
 +
 
 +
 
 +
'''Code''' : https://github.com/SpiderLabs/owasp-modsecurity-crs <br />
 +
'''Issues''' : https://github.com/SpiderLabs/owasp-modsecurity-crs/issues <br />
 +
'''Feature Requests''' : https://github.com/SpiderLabs/owasp-modsecurity-crs/issues (interleaved the issues, look for the right tag, currently ''candidate issue'')<br />
 +
 
 +
 
 +
== Summary of GitHub Shortcuts / Bookmarks ==
 +
 
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/labels/v3.0-dev%20Development Open Issues 3.0.x]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/labels/False%20Positive False Positives]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+label%3A%22False+Negative+-+Evasion%22 False Negatives]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+label%3A%22v3.1.0-rc1+Candidate+Issue%22 Feature Requests for 3.1]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?q=is%3Aissue+is%3Aopen+-label%3A%22v3.1.0-rc1+Candidate+Issue%22 All Issues but not Feature Requests for 3.1]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/labels/Published%20Research Published research affecting project]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20no%3Alabel Open Issues without a label / tag]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20label%20no%3Aassignee Open Issues with a label, but without assignee]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20created%3A%3C2015-01-01 Open Issues before 2015]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20created%3A%3C2016-01-01 Open Issues before 2016]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20created%3A%3C2016-11-10 Open Issues before CRS3 was released (2016-11-10)]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/issues?utf8=%E2%9C%93&q=type%3Aissue%20is%3Aopen%20created%3A%3C2017-01-01 Open Issues before 2017]
 +
 
 +
== Plans for AppSecEU 2017 ==
 +
 
 +
 
 +
See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]
 +
 
 +
== Archive: v3.0 Detection Concepts / Goals ==
  
= Road Map and Getting Involved =
 
 
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.
 
This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.
  
== v3.0 Detection Concepts ==
 
This page documents the goals/ideas for the next major version of the CRS.
 
 
== Goals ==
 
 
These are not listed in any particular order.
 
These are not listed in any particular order.
 
# '''Add New Detection Logic'''
 
# '''Add New Detection Logic'''
Line 398: Line 284:
 
## Reorder/Regroup rule into new file names
 
## Reorder/Regroup rule into new file names
  
== Detection Logic/Flow Concepts ==
+
== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
 
This section outlines the processing flow and associated points of detection and actions taken.
 
This section outlines the processing flow and associated points of detection and actions taken.
 
# '''IP Reputation'''
 
# '''IP Reputation'''
Line 447: Line 333:
 
=Project About=
 
=Project About=
 
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}   
 
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}   
 +
 +
=CRS3 Poster=
 +
 +
The CRS3 poster was designed by [[:User:Hugo_Costa|Hugo Costa]], OWASP's graphical designer. It can be reused under a CC BY-ND license.
 +
 +
The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).
 +
 +
 +
[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]
 +
  
 
__NOTOC__ <headertabs />  
 
__NOTOC__ <headertabs />  
  
 
[[Category:OWASP Project]]  [[Category:OWASP_Defenders]]  [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]
 
[[Category:OWASP Project]]  [[Category:OWASP_Defenders]]  [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Revision as of 01:27, 27 June 2017

Flagship big.jpg

OWASP ModSecurity Core Rule Set (CRS)

The 1st Line of Defense Against Web Application Attacks

The OWASP ModSecurity CRS Project's goal is to provide an easily "pluggable" set of generic attack detection rules that provide a base level of protection for any web application. The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. The CRS aims to protect web applications from a wide range of attacks, including the OWASP Top Ten, with a minimum of false alerts.

More information at https://modsecurity.org/crs.

Description

The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
  • SQL Injection (SQLi)
  • Cross Site Scripting (XSS)
  • Local File Inclusion (LFI)
  • Remote File Inclusion (RFI)
  • Remote Code Execution (RCE)
  • PHP Code Injection
  • HTTP Protocol Violations
  • Shellshock
  • Session Fixation
  • Scanner Detection
  • Metadata/Error Leakages
  • Project Honey Pot Blacklist
  • GeoIP Country Blocking

More Information at https://modsecurity.org/crs.

CRS3-movie-poster-thumb.jpeg

Getting Started / Tutorials

The following tutorials will get you started with ModSecurity and the CRS v3.

These tutorials are part of a big series of Apache / ModSecurity guides published by netnea. They are written by Christian Folini.

More Information about the rule set at https://modsecurity.org/crs and a full list of all the rules in the Core Rule Set at https://netnea.com/crs.

Licensing

OWASP ModSecurity CRS is free to use. It is licensed under the 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.


Project Members

Project Leaders:

Contributors:

  • Christoph Hansen
  • Felipe 'Zimmerle' Costa
  • Franziska Bühler
  • Victor Hora

Presentation

Related Projects

Quick Download

Source Code Repo

News and Events

Mailing List

Classifications

Owasp-flagship-trans-85.png Owasp-defenders-small.png
License: ASLv2
Project Type Files CODE.jpg

<paypal>ModSecurity Core Rule Set Project</paypal>

The following tutorials will get you started with ModSecurity and the CRS v3.

These tutorials are part of a big series of Apache / ModSecurity guides published by netnea. They are written by Christian Folini.

More Information at https://modsecurity.org/crs.

ModSecurity Rules Language

What are the OWASP ModSecurity Core Rules (CRS) and why should I use them?

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave's SpiderLabs is sponsoring the OWASP ModSecrity Core Rule Set (CRS) Project. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

What attacks do the Core Rules protect against?

In order to provide generic web applications protection, the Core Rules use the following techniques:

  • HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
  • Common Web Attacks Protection - detecting common web application security attack.
  • Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
  • Trojan Protection - Detecting access to Trojans horses.
  • Errors Hiding – Disguising error messages sent by the server

In addition the ruleset also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site.

How do I whitelist an IP address so it can pass through ModSecurity?

The first issue to realize is that in ModSecurity 2.0, the allow action is only applied to the current phase. This means that if a rule matches in a subsequent phase it may still take a disruptive action. The recommended rule configuration to allow a remote IP address to bypass ModSecurity rules is to do the following (where 192.168.1.100 should be substituted with the desired IP address): background-color: #ffffcc; SecRule REMOTE_ADDR "@ipMatch 192.168.110" id:1,phase:1,nolog,pass,ctl:ruleEngine=Off

If you want to allow uninterrupted access to the remote IP address, however you still want to log rule alerts, then you can use this rule -

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly

If you want to disable both the rule and audit engines, then you can optionally add another ctl action:

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off

How do I handle False Positives and creating Custom Rules?

It is inevitable; you will run into some False Positive hits when using web application firewalls. This is not something that is unique to ModSecurity. All web application firewalls will generate false positives from time to time. The following Blog post information will help to guide you through the process of identifying, fixing, implementing and testing new custom rules to address false positives. http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

Will using a large amount of negative filtering rules impact performance?

Yes. Each and every rule that you implement will consume resources (RAM, CPU, etc...). The two most important factors to consider with creating ModSecurity rules are the total number of rules and the Regular Expression optimizations. A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions. Unfortunately, it is quite easy to create inefficient RegEx patterns. Optimizing RegExs by utilizing Grouping Only/Non-Capturing Parentheses can cut the validation time by up to 50%. The Core Ruleset is optimized for performance. background-color: #ffffcc;

What is a Virtual Patch and why should I care?

Fixing identified vulnerabilities in web applications always requires time. Organizations often do not have access to a commercial application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time. This leaves a window of opportunity for the attacker to exploit. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls as they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design and in most cases it can be done in less than 15 minutes.

https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet

Managing Alerts

How do I manage ModSecurity logs if I have multiple installations?

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the mlogc program. It comes with the ModSecurity source code and can be used to send individual audit log entries to a remote host in near real-time.

Is there an open source Console to send my audit logs to?

Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.

Can I send ModSecurity alert log data through Syslog?

Yes. If you already have a central Syslog infrastructure setup and/or if you are using some sort of SIEM application, then you might want to include the short version ModSecurity alert messages that appear in the Apache error_log file. You can easily reconfigure Apache to send its error logs through Syslog onto a remote, central logging server. However, the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files.

Project Leader

Chaim Sanders

Project Contributors

See changelog for more contributors.

Project Users

OWASP/WASC Distributed Web Honeypot Project uses the Core Rule Set - https://www.owasp.org/index.php/OWASP_WASC_Distributed_Web_Honeypots_Project

cPanel distributes the OWASP CRS with their ModSecurity package - https://documentation.cpanel.net/display/CKB/OWASP+ModSecurity+CRS

Akamai's WAF Service is based on a previous version of the Core Rule Set - http://www.akamai.com/html/about/press/releases/2009/press_121409.html

CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS - https://www.cloudflare.com/waf http://blog.cloudflare.com/cloudflares-new-waf-compiling-to-lua/

Verizon/EdgeCast WAF uses ModSecurity and the OWASP ModSecurity CRS - http://www.edgecast.com/services/security/#waf

Varnish Web Cache/Accelerator uses a converted version of the CRS - https://github.com/comotion/security.vcl

Project Sponsors

SpiderLabs Logo 2011.JPG

The CRS project is a small community within the bigger OWASP community. We have a successful project with a wide user base and with the CRS3 release cycle, we have put the development on new feet.

We have big plans and there is a need for all sort of contributions from people on a beginner and from people on an expert level alike.


Code : https://github.com/SpiderLabs/owasp-modsecurity-crs
Issues : https://github.com/SpiderLabs/owasp-modsecurity-crs/issues
Feature Requests : https://github.com/SpiderLabs/owasp-modsecurity-crs/issues (interleaved the issues, look for the right tag, currently candidate issue)


Summary of GitHub Shortcuts / Bookmarks

Plans for AppSecEU 2017

See separate page: Plans for AppSecEU 2017

Archive: v3.0 Detection Concepts / Goals

This page outlines development projects which would add new functionality to ModSecurity that could be leveraged by the OWASP ModSecurity Core Rule Set.

These are not listed in any particular order.

  1. Add New Detection Logic
    1. Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
    2. User Profiling (GeoIP/Browser Fingerprinting)
    3. HoneyTraps
  2. Increase Rule Accuracy
    1. Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
    2. Reduce False Negatives - we need to constantly improve detection so that we don't miss attacks (http://blog.spiderlabs.com/2011/07/modsecurity-sql-injection-challenge-lessons-learned.html)
  3. Increase Performance/Reduce Latency
    1. Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
    2. Optimize individual @rx SecRules into less optimized versions
    3. Review all regular expression rules for performance (non-capturing/greediness).
  4. Improve Rule Management
    1. Make it easier for user to enable/disable the desired rules for their platform
    2. Update rule formatting for easier readability
    3. Reorder/Regroup rule into new file names

Archive: Detection Logic/Flow Concepts in the Request Header Phase

This section outlines the processing flow and associated points of detection and actions taken.

  1. IP Reputation
    1. Data inspected: REMOTE_ADDR
    2. Use @rbl to check against remote RBLs
    3. Use @pmf to check a local file if bad IPs
    4. Use GeoIP Data to assign fraud scores
    5. Actions
      1. Deny
      2. Increase TX anomaly score
      3. Tag client as "suspicious" in IP collection
  2. Request Method Analysis
    1. Data inspected: REQUEST_METHOD
    2. Compare the REQUEST_METHOD specified against:
      1. Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
      2. Request methods allowed per-resource (GET vs. POST)
    3. Actions
      1. Deny
      2. Increase TX anomaly score
      3. Tag client as "suspicious" in IP collection
  3. Request Header Analysis
    1. Data inspected: REQUESTE_HEADERS
    2. Check for existence of malicious headers (User-Agent of scanners, etc..)
    3. Check for the absence of required headers (Host, User-Agent, Accept)
    4. Request Header Ordering Anomalies detects non-browsers/bots
    5. Actions
      1. Deny
      2. Increase TX anomaly score
      3. Tag client as "suspicious" in IP collection

Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

  • Contribute on the mail-list by answering questions from the community
  • Report issues to our GitHub Issue tracker

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on github. The release is planned for the first quarter 2016. It brings incorporation of the @detectsqli and @detectxss operators and a general reduction of false positives for default setups.

Infos about 3.0.0

Development

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP ModSecurity Core Rule Set Project (home page)
Purpose: 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.

License: Apache Software License v2 (ASLv2)
who is working on this project?
Project Leader(s):
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation: View
Mailing list: Mailing List Archives
Project Roadmap: View
Main links:
Key Contacts
  • Contact the GPC to report a problem or concern about this project or to update information.
current release
ModSecurity 2.2.8 - 06/30/2013 - (download)
Release description: == Version 2.2.8 - 06/30/2013 ==

Security Fixes:

Improvements:

  • Updatd the /util directory structure
  • Added scripts to check Rule ID duplicates
  • Added script to remove v2.7 actions so older ModSecurity rules will work
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/43
  • Added new PHP rule (958977) to detect PHP exploits (Plesk 0-day from king cope)
 - http://seclists.org/fulldisclosure/2013/Jun/21
 - http://blog.spiderlabs.com/2013/06/honeypot-alert-active-exploits-attempts-for-plesk-vulnerability-.html


Bug Fixes:

  • fix 950901 - word boundary added
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/48
  • fix regex error
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/44
  • Updated the Regex in 981244 to include word boundaries
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/36
  • Problem with Regression Test (Invalid use of backslash) - Rule 960911 - Test2
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/34
  • ModSecurity: No action id present within the rule - ignore_static.conf
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/17
  • "Bad robots" rule blocks all Java applets on Windows XP machines
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/16
  • duplicated rules id 981173
 - https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/18
Rating: Projects/OWASP ModSecurity Core Rule Set Project/GPC/Assessment/ModSecurity 2.2.8
last reviewed release
ModSecurity 2.0.6 - 2010-02-26 - (download)
Release description: ModSecurity is a web application firewall that can work either embedded or as a reverse proxy. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
Rating: Greenlight.pngGreenlight.pngGreenlight.png Stable Release - Assessment Details


other releases
}

The CRS3 poster was designed by Hugo Costa, OWASP's graphical designer. It can be reused under a CC BY-ND license.

The large version has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).


CRS3-movie-poster-small.jpg