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

From OWASP
Jump to: navigation, search
(Roadmap Items)
 
(14 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{OWASP Defenders}}
+
[[File:Flagship_banner.jpg]]
{{Social Media Links}}
+
=Main=
 +
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
 +
| valign="top"  style="border-right: 1px dotted gray;padding-right:25px;" |
  
= Home =
+
==OWASP ModSecurity Core Rule Set (CRS)==
  
{| width="100%"
+
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. 
|-
+
! width="80%" |
+
! width="20%" |
+
|- valign="top"
+
|
+
  
'''Essential Plug-n-Play Protection from Web Application Attacks'''
+
==Introduction==
  
ModSecurity™ is a web application firewall engine that provides very little protection on its own. In order to become useful, ModSecurity™ must be configured with rules. In order to enable users to take full advantage of ModSecurity™ out of the box, the [https://www.owasp.org/index.php/Defenders OWASP Defender Community] has developed and maintains a free set of application protection rules called the OWASP ModSecurity Core Rule Set (CRS). Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS provides '''''generic protection''''' from unknown vulnerabilities often found in web applications.
+
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).
<paypal>ModSecurity Core Rule Set Project</paypal>
+
  
'''Core Rules Content'''
+
==Description==
  
In order to provide generic web applications protection, the Core Rules use the following techniques:
+
The OWASP ModSecurity CRS provides protections if the following attack/threat categories:
 +
*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.
  
*'''HTTP Protection''' - detecting violations of the HTTP protocol and a locally defined usage policy.
+
==Licensing==
*'''Real-time Blacklist Lookups''' - utilizes 3rd Party IP Reputation
+
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.
*'''Web-based Malware Detection''' - identifies malicious web content by check against the Google Safe Browsing API.
+
*'''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.
+
  
|
+
==Open HUB==
[[Image:ModSecurity_Logo_2011.JPG|200px|right|link=http://www.modsecurity.org/]]
+
https://www.openhub.net/p/owasp-modsecurity-crs
  
|}
+
| valign="top"  style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |
  
{| width="100%"
+
== What is OWASP ModSecurity CRS? ==
|-
+
! width="33%" |
+
! width="33%" |
+
! width="33%" |
+
|- valign="top"
+
|
+
== Let's talk here  ==
+
  
[[Image:Asvs-bulb.jpg]]'''ModSecurity Communities'''
+
OWASP ModSecurity CRS provides:
  
Further development of ModSecurity and the Core Rule Set occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please [mailto:ryan.barnett@owasp.org contact us].  
+
* Baseline protection for common web application attacks.
  
*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set CRS mailing list (this is the main list)]
+
== Presentation ==
*[http://lists.sourceforge.net/lists/listinfo/mod-security-users ModSecurity mailing list]
+
  
|
+
*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
== Want to help?  ==
+
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]
  
[[Image:Asvs-waiting.JPG]]'''CRS Development'''
+
== Project Leader ==
  
The CRS project is always on the lookout for volunteers who are interested in contributing. We need help in the following areas:  
+
Project Leader:
 +
* [https://www.owasp.org/index.php/User:Rcbarnett Ryan Barnett]
  
*Documentation of the CRS
+
Contributors:
*New Detection Methods
+
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]<br>
*Updates to existing rules
+
*[[:user:Roberto_Salgado|Roberto Salgado]]<br>
 +
*[https://twitter.com/soaj1664ashar Ashar Javed (@soaj1664ashar)]
  
|
+
== Related Projects ==
== Related resources  ==
+
 
+
[[Image:Asvs-satellite.jpg]]'''OWASP Resources'''
+
  
 
*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]  
 
*[[http://www.owasp.org/index.php/Category:OWASP_Securing_WebGoat_using_ModSecurity_Project OWASP Securing WebGoat using ModSecurity Project]]  
Line 73: Line 61:
 
*[[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 ==
  
= Download =
+
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master Latest CRS (TAR/GZ)]
 +
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master Latest CRS (ZIP)]
  
GitHub Repository is here:
+
== Source Code Repo ==
  
https://github.com/SpiderLabs/owasp-modsecurity-crs
+
* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]
  
Download TAR/GZ Archive:
+
== News and Events ==
https://github.com/SpiderLabs/owasp-modsecurity-crs/tarball/master
+
  
Download ZIP Archive:
+
== Mailing List ==
https://github.com/SpiderLabs/owasp-modsecurity-crs/zipball/master
+
  
= Bug Tracker =
+
*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]
  
GitHub Issues:
+
==Classifications==
  
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues
+
  {| width="200" cellpadding="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=]]
 +
  |}
  
= Demo =
+
==Donate==
 +
<paypal>ModSecurity Core Rule Set Project</paypal>
  
ModSecurity CRS Demonstration/Smoketest page:
+
|}
  
http://www.modsecurity.org/demo/
+
=FAQs=
  
= Contributors and Users =
+
== Who Leads the ModSecurity Project? ==
 +
ModSecurity is supported by Trustwave's SpiderLabs Team [https://www.trustwave.com/spiderLabs.php] and includes the following team members:
 +
*Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
 +
*Felipe Zimmerle Costa - ModSecurity Lead Developer
  
== Project Leader ==
+
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].
  
[[:User:Rcbarnett|Ryan Barnett]]
+
== Background and Support ==
  
== Project Contributors ==
+
=== What exactly is ModSecurity? ===
  
[[:User:Josh Amishav-Zlatin|Josh Zlatin]]<br>
+
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.
[[:User:Brian_Rectanus|Brian Rectanus]]<br>
+
[[:user:Roberto_Salgado|Roberto Salgado]]
+
  
== Project Users ==
+
=== Where do I get more help on ModSecurity? ===
  
WASC Distributed Web Honeypot Project uses the Core Rule Set -
+
The ModSecurity website is the definitive location for all information - http://www.modsecurity.org/help.html.
http://projects.webappsec.org/Distributed-Web-Honeypots
+
  
Akamai's WAF Service is based on a previous version of the Core Rule Set -
+
==== Open Source/Free Help ====
http://www.akamai.com/html/about/press/releases/2009/press_121409.html
+
*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
  
Varnish Web Cache/Accelerator uses a converted version of the CRS -
+
=== Do I need to sign up for the Mod-User Mail-list before I can send emails? ===
https://github.com/comotion/security.vcl
+
  
= Project Sponsors =
+
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.
  
[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
+
=== Is there anything that I should do prior to sending emails to the mail-list? ===
<br>
+
  
= Installation =
+
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.
  
'''Quick Start'''
+
=== Will I always get an immediate answer to my question on the open source mod-security-users mail-list? ===
  
== Core Rule Set Quick Setup ==
+
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.
  
To activate the rules for your web server installation:
+
=== If I don't get an immediate response, should I send an email to the Trustwave Technical Support email address? ===
  
  1) The modsecurity_crs_10_config.conf includes management rules and directives
+
No. The Trustwave Technical Support email address is for commercial ModSecurity customers only.
    that can control important CRS functions. Pay attention to
+
    the SecRuleEngine setting (On by default) and that the SecDefaultAction
+
    directive is set to "pass".  The 49 inbound blocking and 59 outbound blocking
+
    rules files 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 an
+
    anomaly scoring/correlation match.
+
  
    Update the PARANOID_MODE variable setting if you want to become more
+
=== Where can I find books about Web Application Firewalls and ModSecurity? ===
    aggressive in your detection.  Caution - this will cause more false positives.
+
  
    Should also update the appropriate anomaly scoring levels that will be propagated
+
==== ModSecurity Handbook ====
    to the inbound/outbound blocking files.
+
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.
  
    Update the TX policy settings for allowed Request Methods, File Extensions, etc...
+
==== 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.
  
  2) Add the following line to your httpd.conf (assuming
+
==== ModSecurity 2.5 ====
    you've placed the rule files into conf/modsecurity_crs/):
+
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.
  
        <IfModule security2_module>
+
==== Apache Security ====
                Include conf/modsecurity_crs/*.conf
+
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.
                Include conf/modsecurity_crs/base_rules/*.conf
+
        </IfModule>
+
  
  3) Restart web server.
+
==== 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.
  
  4) Make sure your web sites are still running fine.
+
== Getting Started ==
  
  5) Simulate an attack against the web server. Then check
+
=== What type(s) of security models does ModSecurity support? ===
    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).
+
  
 +
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:
  
= Documentation =
+
*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.
  
== ModSecurity Blog Posts ==
+
*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.
  
http://blog.spiderlabs.com/modsecurity/
+
*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.
  
*ModSecurity Advanced Topic of the Week: Traditional vs. Anomaly Scoring Detection Modes
+
*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.
http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html
+
  
*ModSecurity Advanced Topic of the Week: Exception Handling
+
=== What's new in ModSecurity and why should I upgrade if I am already using ModSecurity 1.x? ===
http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html
+
  
== Rule Documentation Template ==
+
There are many significant changes and enhancements in ModSecurity 2.5 over the 1.x branch, including:
  
Each ModSecurity Rule in the CRS has an individual rule description page based on the following template file:
+
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.
  
http://www.owasp.org/index.php/ModSecurity_CRS_Rule_Description_Template
+
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.
  
*Project participants are encouraged to copy this template and create landing pages for each CRS rule
+
Per-rule transformation options (previously normalization was implicit and hard-coded). Many new transformation functions were added.
*Use this template and create a new page using the following format - http://www.owasp.org/index.php?title=ModSecurity_CRS_RuleID-XXXXX (where XXXXX is the CRS ruleID)
+
  
Example:
+
Transaction variables. This can be used to store pieces of data, create a transaction anomaly score, and so on.
  
http://www.owasp.org/index.php/ModSecurity_CRS_RuleID-960911
+
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).
  
== ModSecurity Core Rule Set (CRS) ==
+
Support for anomaly scoring and basic event correlation (counters can be automatically decreased over time; variables can be expired).
  
The ModSecurity Core Rule Set is provided to you under the terms and  
+
Support for web applications and session IDs.
conditions of GPL version 2
+
  
This directory contains the files for Core ModSecurity Rule Set
+
Regular Expression back-references (allows one to create custom variables using transaction content).
The rules are compatible with ModSecurity 2.5 (as of version 1.4.3)
+
  
== Overview ==
+
There are now many functions that can be applied to the variables (where previously one could only use regular expressions).
  
Using ModSecurity requires rules. In order to enable users to take full
+
XML support (parsing, validation, XPath).
advantage of ModSecurity immediately, Trustwave is providing a free
+
Core rule set. 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. This is what we call "Attack
+
Payload Detection."
+
  
Keep in mind that a predefined rule set is only part of the work required to
+
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.
protect your web site. We strongly urge you to consult Ivan Ristic's book,
+
"ModSecurity Handbook" http://store.feistyduck.com/products/modsecurity-handbook
+
and the ModSecurity Reference Manual - http://www.modsecurity.org/documentation/.
+
The CRS is heavily commented to allow it to be used as a step-by-step
+
deployment guide for ModSecurity.
+
  
For more information refer to the OWASP Core Rule Set Project page at
+
=== How do I migrate my rules from the ModSecurity 1.x format into the 2.x format? ===
http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
+
  
Core Rules Mail-list -
+
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.
Suscribe here: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
+
Archive: https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/
+
  
== CRS 2.0 Design Concepts ==
+
=== How do I install ModSecurity 2.0? ===
  
=== CRS < 2.0 - Self-Contained Rules ===
+
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.
  
Older (<2.0) CRS used individual, “self-contained” actions in rules
+
=== I hear that ModSecurity can be run in embedded-mode, what does that mean exactly? ===
- If a rule triggered, it would either deny or pass and log
+
- No intelligence was shared between rules
+
Not optimal from a rules management perspective (handling false positives/exceptions)
+
- Editing the regex could blow it up
+
- Typical method was to copy/paste rules into custom rules files and then edit rule logic
+
  and disable core rule ID.
+
- Heavily customized rules were less likely to be updated by the user
+
Not optimal from a security perspective
+
- Not every site had the same risk tolerance
+
- Lower severity alerts were largely ignored
+
- Individual low severity alerts are not important but several low severity events
+
  in the same transaction are.
+
  
== CRS 2.0 - Collaborative Detection ==
+
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:
  
=== Rules - Detection and Management ===
+
*Advantages
 +
Easy to add to an existing Apache server.
  
Rules logic has changed by decoupling the inspection/detection from the blocking functionality
+
Not a point of failure with respect to traffic.
- Rules log.pass and set transactional variables (tx) to track anomaly scores and to
+
  store meta-data about the rule match
+
- This TX rule match data can be used by other 3rd party rules (converter Emerging Threats
+
  Snort web attack rules) to more accurately correlate identified attacks with their
+
  attack vector locations.
+
- TX data of previous strong rule matches can also be used to conditionally apply weaker signatures
+
  that normally would have a high fasle positive rate.
+
- Rules also increase anomaly scores for both the attack category and global score which allows
+
  users to set a threshold that is appropriate for them.
+
- This also allows several low severity events to trigger alerts while individual ones are suppressed.
+
- Exceptions may be handled by either increasing the overall anomaly score threshold, or
+
  by adding rules to a local custom exceptions file where TX data of previous rule matches
+
  may be inspected and anomaly scores re-adjusted based on the false positive criteria.
+
  
User can now globally update which variables to inspect and the anomaly score settings in the
+
*Disadvantages
modsecurity_crs_10_config.conf file.
+
ModSecurity can only protect the local web server.
- PARANOID_MODE setting which will apply rules to locations that have a higher false positive rate
+
- INBOUND_ANOMALY_SCORE setting will be populated in the inbound blocking file and if a transaction
+
  score at the end of phase:2 is equal to or greater than this number, it will be denied.
+
- OUTBOUND_ANOMALY_SCORE setting will be populated in the outbound blocking file and it a transaction
+
  score at the end of phase:4 is equal to or greater than this number, it will be denied.
+
  
== Inbound/Outbound Blocking ==
+
ModSecurity will consume local resources such as CPU and RAM.
  
The CRS rules themselves are configured with the pass action, which allows all the rules to be processed
+
Management of log files and configurations can become difficult if you have multiple installations.
and for the proposed anomaly scoring/collaborative detection concept to work.  The inbound/outbound anomaly
+
score levels may be set in the modsecurity_crs_10_config.conf file.  These scores will be evaluated in the
+
modsecurity_crs_49_inbound_blocking.conf and modsecurity_crs_59_outbound_blocking.conf files.  
+
  
== Alert Management - Correlated Event Creation ==
+
=== I hear that ModSecurity can be run in reverse proxy-mode, how does that differ from embedded-mode? ===
  
One of the top feedback items we have heard is that the CRS events in the Apache error_log file
+
The only difference with this deployment vs. an embedded one is that Apache itself is configured to function as a reverse proxy.
were very chatty.  This was due to each rule triggering its own error_log entry.  What most people
+
wanted was for 1 correlated event to be generated that would give the user a higher level
+
determination as to what the event category was.
+
  
To that end- each CRS rule will generate an audit log event Message entry but they will not log
+
*Advantages
to the error_log on their own.  These rules are now considered basic or reference events and  
+
Single point of access – functions as a choke point so you consolidate applying security settings and makes management easier.
may be reviewed in the audit log if the user wants to see what individual events contributed
+
to the overall anomaly score and event designation.
+
  
== Inbound/Outbound Correlation ==
+
Network topology is hidden from the outside world - so it will be more difficult for attackers to enumerate your web platforms.
  
After the transaction has completed (in the logging phase), the rules in the
+
Increased performance – if SSL accelerators/caching used.
base_rules/modsecurity_crs_60_correlation.conf file will conduct further post-processing by
+
analyzing any inbound events with any outbound events in order to provide a more
+
intelligent/priority correlated event.
+
  
- Was there an inbound attack?
+
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.
- Was there an HTTP Status Code Error (4xx/5xx level)?
+
- Was there an application information leak?
+
  
If an inbound attack was detected
+
*Disadvantages
and either an outbound application status code error or infolead was detected, then the overall
+
A potential traffic bottleneck if the reverse proxy can not handle the network load.
event severity is raised -
+
  
- 0: Emergency - is generated from correlation where there is an inbound attack and
+
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.
  an outbound leakage.
+
- 1: Alert - is generated from correlation where there is an inbound attack and an
+
  outbound application level error.
+
  
== Core Rule Set Content ==
+
Requires changes to the network.
  
In order to provide generic web applications protection, the Core Rule Set
+
== Configuring ModSecurity ==
uses the following techniques:
+
  
=== HTTP Protocol Validation and Protection ===
+
=== Should I initially set the SecRuleEngine to On? ===
  
Detecting violations of the HTTP protocol and a locally
+
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.
defined usage policy. 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.
+
  
==== base_rules/modsecurity_crs_20_protocol_violations.conf ====
+
=== How do I get ModSecurity to inspect request and response bodies? ===
  
Protocol vulnerabilities such as Response Splitting, Request Smuggling, Premature URL ending
+
You need to set the the following two directives:
- Content length only for non GET/HEAD methods
+
- Non ASCII characters or encoding in headers
+
- Valid use of headers (for example, content length is numerical)
+
- Proxy Access
+
  
==== base_rules/modsecurity_crs_21_protocol_anomalies.conf ====
+
SecRequestBodyAccess On
  
Attack requests are different due to automation
+
SecResponseBodyAccess On
- Missing headers such as Host, Accept, User-Agent
+
- Host is an IP address (common worm propagation method)
+
  
==== base_rules/modsecurity_crs_23_request_limits.conf ====  
+
=== How can I verify exactly how ModSecurity is processing rules and requests? ===
  
Policy is usually application specific
+
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.
- Some restrictions can usually be applied generically
+
- White lists can be build for specific environments
+
  Limitations on Sizes
+
- Request size, Upload size
+
- # of parameters, length of parameter
+
  
==== base_rules/modsecurity_crs_30_http_policy.conf ====  
+
== ModSecurity Rules Language ==
  
Items that can be allowed or restricted
+
=== What are the OWASP ModSecurity Core Rules (CRS) and why should I use them? ===
- Methods - Allow or restrict WebDAV, block abused methods such as CONNECT, TRACE or DEBUG
+
- File extensions – backup files, database files, ini files
+
- Content-Types (and to some extent other headers)
+
  
==== Automation Detection ====
+
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.
  
Automated clients are both a security risk and a
+
=== What attacks do the Core Rules protect against? ===
commercial risk. Automated crawlers collect information from your site, consume
+
bandwidth and might also search for vulnerabilities on the web site. Automation
+
detection is especially useful for generic detection of comments spam.
+
  
Detecting bots, crawlers, scanners and other surface malicious activity.
+
In order to provide generic web applications protection, the Core Rules use the following techniques:
Not aimed against targeted attacks, but against general malicious internet activity
+
- Offloads a lot of cyberspace junk & noise
+
- Effective against comment spam
+
- Reduce event count
+
  
==== base_rules/modsecurity_crs_35_bad_robots.conf ====
+
*HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy.
+
*Common Web Attacks Protection - detecting common web application security attack.
Detection of Malicious Robots
+
*Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity.
- Unique request attributes: User-Agent header, URL, Headers
+
*Trojan Protection - Detecting access to Trojans horses.
- RBL Check of IP addresses
+
*Errors Hiding – Disguising error messages sent by the server
- Detection of security scanners
+
- Blocking can confuse security testing software (WAFW00f)
+
  
==== optional_rules/modsecurity_crs_42_comment_spam.conf ====
+
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.
  
This rules file is only relevant if you are concerned about comment SPAM attacks.
+
=== Can I use the Core Rules with ModSecurity 1.x? ===
The rules file will run an RBL check against the source IP address at SPAMHAUS and will
+
cache the response for 1 day.  If the client sends subsequent requests, it will be denied
+
without having to re-run an RBL check.
+
  
This file will also look for comment SPAM posting attacks which submit URL links.
+
Unfortunately, no. The Core Rules takes advantage of the ModSecurity 2.0 rules language and is therefore not backward compatible.
  
=== Common Web Attacks Protection ===
+
=== How do I whitelist an IP address so it can pass through ModSecurity? ===
  
Common Web Attacks Protection Rules on the second level address the common web
+
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):
application security attack methods. These are the issues that can appear in
+
any web application. Some of the issues addressed are:
+
  
- SQL Injection
+
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off
- Cross-Site Scripting (XSS)
+
- OS Command execution
+
- Remote code inclusion
+
- LDAP Injection
+
- SSI Injection
+
- Information leak
+
- Buffer overflows
+
- File disclosure
+
  
==== base_rules/modsecurity_crs_40_generic_attacks.conf ====
+
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 -
+
- OS command injection and remote command access
+
- Remote file inclusion
+
- Session Fixation
+
  
==== optional_rules/modsecurity_crs_40_experimental.conf ====
+
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly
  
The rules in this file are considered BETA quality as they have not been rigorously tested.
+
If you want to disable both the rule and audit engines, then you can optionally add another ctl action:
They attempt to address advanced attacks such as HTTP Parameter Pollution or use new rule
+
features or techniques.
+
  
==== base_rules/modsecurity_crs_42_tight_security.conf ====
+
SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,ctl:ruleEngine=Off,ctl:auditEngine=Off
  
This rules file attempts to identify all directory traversal variations. It is prone to a high
+
=== Are there rule differences for identify missing/empty variables between ModSecurity 1.x and 2.x? ===
level of false positives so set PARANOID_MODE if you want to run these rules.  
+
  
==== base_rules/modsecurity_crs_41_sql_injection.conf ====
+
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.
  
- SQL injection and blind SQL injection
+
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.
  
==== base_rules/modsecurity_crs_41_xss.conf ====
+
Please refer to the following blog post for more information.
  
- Cross site scripting (XSS)
+
=== How do I handle False Positives and creating Custom Rules? ===
  
=== Trojan Protection ===
+
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
  
ModSecurity Core Rule Set detects access to back doors
+
=== Will using a large amount of negative filtering rules impact performance? ===
installed on a web server. This feature is very important in a hosting
+
environment when some of this backdoors may be uploaded in a legitimate way and
+
used maliciously. In addition the Core Rule Set includes a hook for adding
+
an Anti-Virus program such as ClamAV for checking file uploads.
+
  
==== base_rules/modsecurity_crs_45_trojans.conf ====
+
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.
  
- Check uploading of http backdoor page
+
=== What is a Virtual Patch and why should I care? ===
- Access detection
+
- Known signatures (x_key header)
+
- Generic file management output (gid, uid, drwx, c:\)
+
  
=== InfoLeakages ===
+
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.
  
If all fails, the Core Rule Set will detect errors sent by
+
https://www.owasp.org/index.php/Virtual_Patching_Cheat_Sheet
the web server. Detecting and blocking errors prevents attackers from
+
collecting reconnaissance information about the web application and also server
+
as a last line of defense in case an attack was not detected eariler.
+
  
==== base_rules/modsecurity_crs_50_outbound.conf ====
+
== Managing Alerts ==
  
- HTTP Error Response Status Codes
+
=== How do I manage ModSecurity logs if I have multiple installations? ===
- SQL Information Leakage
+
- Stack Dumps
+
- Source Code Leakage
+
  
=== Request Header Tagging ===
+
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.
  
This concept is similar to anti-SPAM SMTP apps that will add additional mime headers
+
=== Is there an open source Console to send my audit logs to? ===
to emails providing the SPAM detection analysis information.  The CRS is attempting
+
to mimic this concept at the HTTP layer by adding additional request headers that
+
provide insight into any ModSecurity events that may have triggered during processing.
+
The advantage of this approach is that it allows a WAF to be in a detection-only mode
+
while still providing attack data to the destination application server.  The recieving
+
app server may then inspect the WAF request headers and make a determination whether
+
or not to process the transaction.  This concept is valuable in distributed web environments
+
and hosting architectures where a determination to block may only be appropriate at the
+
destination app server.
+
  
==== optional_rules/modsecurity_crs_49_header_tagging.conf ====
+
Christian Bockermann has developed an outstanding free tool called AuditConsole that allows you to centralize and analyze remote ModSecurity audit log data.
  
This rules file will take all of the TX attack variable data and populate Apache ENV
+
=== Can I send ModSecurity alert log data through Syslog? ===
variables that Apache can then use to add X-WAF-Event request header data to the
+
request.
+
  
Example showing the consolidated X-WAF-Events and X-WAF-Score data -
+
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.
  
GET /path/to/foo.php?test=1%27%20or%20%272%27=%272%27;-- HTTP/1.1
+
= Acknowledgements =
Host: www.example.com
+
== Project Leader ==
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
+
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
+
Accept-Language: en-us,en;q=0.5
+
Accept-Encoding: gzip,deflate
+
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
+
X-WAF-Events: TX: / 999935-Detects common comment types-WEB_ATTACK/INJECTION-ARGS:test, TX:999923-Detects JavaScript location/document property access and window access obfuscation-WEB_ATTACK/INJECTION-REQUEST_URI_RAW, TX:950001- WEB_ATTACK/SQL_INJECTION-ARGS:test
+
X-WAF-Score: Total=48; sqli=2; xss=
+
Connection: Keep-Alive
+
  
= Presentations and Whitepapers =
+
[[:User:Rcbarnett|Ryan Barnett]]
  
Current CRS v2 [[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt]] presented at AppSec DC 2010.
+
== Project Contributors ==
  
Ryan Barnett Presenting on the OWASP CRS v2 at AppSec DC 2010 - http://player.vimeo.com/play_redirect?quality=sd&codecs=h264&clip_id=20166971&time=1348856471&sig=6c81604ac26dec6f6e1ae034af18c817&type=html5_desktop_local
+
[[:User:Josh Amishav-Zlatin|Josh Zlatin]]<br>
 +
[[:User:Brian_Rectanus|Brian Rectanus]]<br>
 +
[[:user:Roberto_Salgado|Roberto Salgado]]<br>
 +
Nick Galbreath
  
= Related Projects =
+
== Project Users ==
  
[http://www.modsecurity.org/ ModSecurity-Open Source Web Application Firewall]<br>[[:Category:OWASP Securing WebGoat using ModSecurity Project|OWASP Securing WebGoat using ModSecurity]]<br>[[:Category:OWASP_AppSensor_Project|OWASP AppSensor Project]]
+
WASC Distributed Web Honeypot Project uses the Core Rule Set -
 +
http://projects.webappsec.org/Distributed-Web-Honeypots
  
= Release History =
+
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
  
== OWASP ModSecurity Core Rule Set (CRS) JIRA CHANGELOG ==
+
CloudFlare's WAF uses the logic from the OWASP ModSecurity CRS -
* https://www.modsecurity.org/tracker/browse/CORERULES
+
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
  
== Version 2.2.6 - 09/14/2012 ==
+
== Project Sponsors ==
  
Improvements:
+
[[Image:SpiderLabs Logo 2011.JPG|200px|left|link=https://www.trustwave.com/spiderLabs.php]]
* Started rule formatting update for better readability
+
<br>
* Added maturity and accuracy action data to each rule
+
* Updated rule revision (rev) action
+
* Added rule version (ver) action
+
* Added more regression tests (util/regression_tests/)
+
* Modified Rule ID 960342 to block large file attachments in phase:1
+
* Removed all PARANOID rule checks
+
* Added new Session Fixation rules
+
 
+
Bug Fixes:
+
* Fixed missing ending double-quotes in XSS rules file
+
* Moved SecDefaultAction setting from phase:2 to phase:1
+
* Fixed Session Hijacking SessionID Regex
+
  https://www.modsecurity.org/tracker/browse/CORERULES-79
+
* Changed the variable listing for many generic attack rules to exclude REQUEST_FILENAME
+
  https://www.modsecurity.org/tracker/browse/CORERULES-78
+
 
+
== Version 2.2.5 - 06/14/2012 ==
+
 
+
 
+
Improvements:
+
* Renamed main config file to modsecurity_crs_10_setup.conf
+
* Updated the rule IDs to start from CRS reserved range: 900000
+
* Updated rule formatting for readibility
+
* Updated the CSRF rules to use UNIQUE_ID as the token source
+
* Added the zap2modsec.pl script to the /util directory which converts
+
  OWASP ZAP Scanner XML data into ModSecurity Virtual Patches
+
* Updated the Directory Traversal Signatures to include more obfuscated data
+
* Added Arachni Scanner Integration Lua script/rules files
+
 
+
Bug Fixes:
+
* Added forceRequestBodyVariable action to rule ID 960904
+
* Updated the anomaly scoring value for rule ID 960000 to critical
+
  (Identified by Qualys Vulnerability & Malware Research Labs (VMRL))
+
* Updated Content-Type check to fix possible evasion with @within
+
  (Identified by Qualys Vulnerability & Malware Research Labs (VMRL))
+
 
+
 
+
== Version 2.2.4 - 03/14/2012 ==
+
 
+
 
+
Improvements:
+
* Added Location and Set-Cookie checks to Response Splitting rule ID 950910
+
* Added a README file to the activated_rules directory
+
* Consolidate a number of SQL Injection rules into optimized regexs
+
* Removed multiMatch and replaceComments from SQL Injection rules
+
* Updated the SQLi regexs for greediness
+
* Updated the SQLi setvar anomaly score values to use macro expansion
+
* Removed PARANOID mode rules
+
 
+
Bug Fixes:
+
* Fixed missing comma before severity action in rules 958291, 958230 and 958231
+
* Fixed duplidate rule IDs
+
 
+
 
+
== Version 2.2.3 - 12/19/2011 ==
+
 
+
 
+
Improvements:
+
* Added Watcher Cookie Checks to optional_rules/modsecurity_crs_55_appication_defects.conf file
+
  http://websecuritytool.codeplex.com/wikipage?title=Checks#cookies
+
* Added Watcher Charset Checks to optional_rules/modsecurity_crs_55_application_defects.conf file
+
  http://websecuritytool.codeplex.com/wikipage?title=Checks#charset
+
* Added Watcher Header Checks to optional_rules/modsecurity_crs_55_application_defects.conf file
+
  http://websecuritytool.codeplex.com/wikipage?title=Checks#header
+
 
+
Bug Fixes:
+
* Fixed Content-Type evasion issue by adding ctl:forceRequestBodyVariable action to
+
  rule ID 960010. (Identified by Andrew Wilson of Trustwave SpiderLabs).
+
* Updated the regex and added tags for RFI rules.
+
 
+
 
+
== Version 2.2.2 - 09/28/2011 ==
+
 
+
 
+
Improvements:
+
* Updated the AppSensor Profiling (to use Lua scripts) for Request Exceptions Detection Points
+
* Added new Range header detection checks to prevent Apache DoS
+
* Added new Security Scanner User-Agent strings
+
* Added example script to the /util directory to convert Arachni DAST scanner
+
  XML data into ModSecurity virtual patching rules.
+
* Updated the SQLi Character Anomaly Detection Rules
+
* Added Host header info to the RESOURCE collection key for AppSensor profiling rules
+
 
+
Bug Fixes:
+
* Fixed action list for XSS rules (replaced pass,nolog,auditlog with block)
+
* Fixed Request Limit rules by removing & from variables
+
* Fixed Session Hijacking IP/UA hash captures
+
* Updated the SQLi regex for rule ID 981242
+
 
+
 
+
== Version 2.2.1 - 07/20/2011 ==
+
 
+
 
+
Improvements:
+
* Extensive SQL Injection signature updates as a result of the SQLi Challenge
+
  http://www.modsecurity.org/demo/challenge.html
+
* Updated the SQL Error message detection in reponse bodies
+
* Updated SQL Injection signatures to include more DB functions
+
* Updated the WEAK SQL Injection signatures
+
* Added tag AppSensor/RE8 to rule ID 960018
+
 
+
Bug Fixes:
+
* Fixed Bad Robot logic for rule ID 990012 to further qualify User-Agent matches
+
  https://www.modsecurity.org/tracker/browse/CORERULES-70
+
* Fixed Session Hijacking rules to properly capture IP address network hashes.
+
* Added the multiMatch action to the SQLi rules
+
* Fixed a false negative logic flaw within the advanced_filter_converter.lua script
+
* Fixed missing : in id action in DoS ruleset.
+
* Updated rule ID 971150 signature to remove ;
+
+
 
+
== Version 2.2.0 - 05/26/2011 ==
+
 
+
 
+
Improvements:
+
* Changed Licensing from GPLv2 to Apache Software License v2 (ASLv2)
+
  http://www.apache.org/licenses/LICENSE-2.0.txt
+
* Created new INSTALL file outlining quick config setup
+
* Added a new rule regression testing framework to the /util directory
+
* Added new activated_rules directory which will allow users to place symlinks pointing
+
  to files they want to run.  This allows for easier Apache Include wild-carding
+
* Adding in new RULE_MATURITY and RULE_ACCURACY tags
+
* Adding in a check for X-Forwarded-For source IP when creating IP collection
+
* Added new Application Defect checks (55 app defect file) from Watcher tool (Check Charset)
+
  http://websecuritytool.codeplex.com/wikipage?title=Checks#charset
+
* Added new AppSensor rules to experimental_dir
+
  https://www.owasp.org/index.php/AppSensor_DetectionPoints
+
* Added new Generic Malicious JS checks in outbound content
+
* Added experimental IP Forensic rules to gather Client hostname/whois info
+
  http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
+
* Added support for Mozilla's Content Security Policy (CSP) to the experimental_rules
+
  http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html 
+
* Global collection in the 10 file now uses the Host Request Header as the collection key.
+
  This allows for per-site global collections.
+
* Added new SpiderLabs Research (SLR) rules directory (slr_rules) for known vulnerabilties.
+
  This includes both converted web rules from Emerging Threats (ET) and from SLR Team.
+
* Added new SLR rule packs for known application vulns for WordPress, Joomla and phpBB
+
* Added experimental rules for detecting Open Proxy Abuse
+
  http://blog.spiderlabs.com/2011/03/detecting-malice-with-modsecurity-open-proxy-abuse.html
+
* Added experimental Passive Vulnerability Scanning ruleset using OSVDB and Lua API
+
  http://blog.spiderlabs.com/2011/02/modsecurity-advanced-topic-of-the-week-passive-vulnerability-scanning-part-1-osvdb-checks.html
+
* Added additional URI Request Validation rule to the 20 protocol violations file (Rule ID - 981227)
+
* Added new SQLi detection rules (959070, 959071 and 959072)
+
* Added "Toata dragostea mea pentru diavola" to the malicious User-Agent data
+
  https://www.modsecurity.org/tracker/browse/CORERULES-64
+
 
+
Bug Fixes:
+
* Assigned IDs to all active SecRules/SecActions
+
* Removed rule inversion (!) from rule ID 960902
+
* Fixed false negative issue in Response Splitting Rule
+
* Fixed false negative issue with @validateByteRange check
+
* Updated the TARGETS lising for rule ID 950908
+
* Updated TX data for REQBODY processing
+
* Changed the pass action to block in the RFI rules in the 40 generic file
+
* Updated RFI regex to catch IP address usage in hostname
+
  https://www.modsecurity.org/tracker/browse/CORERULES-68
+
* Changed REQUEST_URI_RAW variable to REQUEST_LINE in SLR rules to allow matches on request methods.
+
* Updated the RFI rules in the 40 generic attacks conf file to remove explicit logging actions.
+
  They will now inherit the settings from the SecDefaultAction
+
 
+
 
+
== Version 2.1.2 - 02/17/2011 ==
+
 
+
 
+
Improvements:
+
* Added experimental real-time application profiling ruleset.
+
* Added experimental Lua script for profiling the # of page scripts, iframes, etc..
+
  which will help to identify successful XSS attacks and planting of malware links.
+
* Added new CSRF detection rule which will trigger if a subsequent request comes too
+
  quickly (need to use the Ignore Static Content rules).
+
 
+
Bug Fixes:
+
* Added missing " in the skipAfter SecAction in the CC Detection rule set
+
 
+
 
+
== Version 2.1.1 - 12/30/2010 ==
+
 
+
 
+
Bug Fixes:
+
* Updated the 10 config conf file to add in pass action to User-Agent rule
+
* Updated the CSRF ruleset to conditionally do content injection - if the
+
  csrf token was created by the session hijacking conf file
+
* Updated the session hijacking conf file to only enforce rules if a SessionID
+
  Cookie was submitted
+
* Fixed macro expansion setvar bug in the restricted file extension rule
+
* Moved the comment spam data file into the optional_rules directory
+
 
+
 
+
== Version 2.1.0 - 12/29/2010 ==
+
 
+
 
+
Improvements:
+
* Added Experimental Lua Converter script to normalize payloads. Based on
+
  PHPIDS Converter code and it used with the advanced filters conf file.
+
* Changed the name of PHPIDS converted rules to Advanced Filters
+
* Added Ignore Static Content (Performance enhancement) rule set
+
* Added XML Enabler (Web Services) rule set which will parse XML data
+
* Added Authorized Vulnerability Scanning (AVS) Whitelist rule set
+
* Added Denial of Service (DoS) Protection rule set
+
* Added Slow HTTP DoS (Connection Consumption) Protection rule set
+
* Added Brute Force Attack Protection rule set
+
* Added Session Hijacking Detection rule set
+
* Added Username Tracking rule set
+
* Added Authentication Tracking rule set
+
* Added Anti-Virus Scanning of File Attachments rule set
+
* Added AV Scanning program to /util directory
+
* Added Credit Card Usage Tracking/Leakage Prevention rule set
+
* Added experimental CC Track/PAN Leakage Prevention rule set
+
* Added an experimental_rules directory to hold new BETA rules
+
* Moved the local exceptions conf file back into base_rules dirctory however
+
  it has a ".example" extension to prevent overwriting customized versions
+
  when upgrading
+
* Separated out HTTP Parameter Pollution and Restricted Character Anomaly Detection rules to
+
  the experimental_rules directory
+
* Adding the REQUEST_HEADERS:User-Agent macro data to the initcol in 10 config file, which will
+
  help to make collections a bit more unique
+
 
+
 
+
 
+
== Version 2.0.10 - 11/29/2010 ==
+
 
+
 
+
Improvements:
+
* Commented out the Anomaly Scoring Blocking Mode TX variable since, by default, the CRS
+
  is running in traditional mode.
+
 
+
Bug Fixes:
+
* Moved all skipAfter actions in chained rules to chain starter SecRules
+
  https://www.modsecurity.org/tracker/browse/MODSEC-159
+
* Changed phases on several rules in the 20 protocol anomaly rules file to phase:1 to avoid FNs
+
 
+
 
+
 
+
== Version 2.0.9 - 11/17/2010 ==
+
 
+
 
+
Improvements:
+
* Changed the name of the main config file to modsecurity_crs_10_config.conf.example so that
+
  it will not overwrite existing config settings.  Users should rename this file to activate
+
  it.
+
* Traditional detection mode is now the current default
+
* Users can now more easily toggle between traditional/standard mode vs. anomaly scoring mode
+
  by editing the modsecurity_crs_10_config.conf file
+
* Updated the disruptive actions in most rules to use "block" action instead of "pass".  This
+
  is to allow for the toggling between traditional vs. anomaly scoring modes.
+
* Removed logging actions from most rules so that it can be controlled from the SecDefaultAction
+
  setting in the modsecurity_crs_10_config.conf file
+
* Updated the anomaly scores in the modsecurity_crs_10_config.conf file to more closely match
+
  what is used in the PHPIDS rules.  These still have the same factor of severity even though
+
  the numbers themselves are smaller.
+
* Updated the 49 and 59 blocking rules to include the matched logdata
+
* Updated the TAG data to further classify attack/vuln categories.
+
* Updated the SQL Injection filters to detect more boolean logic attacks
+
* Moved some files to optional_rules directory (phpids, Emerging Threats rules)
+
+
Bug Fixes:
+
* Fixed Rule ID 960023 in optional_rules/modsecurity_crs_40_experimental.conf is missing 1 single quote
+
  https://www.modsecurity.org/tracker/browse/CORERULES-63
+
* Moved all skipAfter actions in chained rules to the rule starter line (must have ModSec v2.5.13 or higher)
+
  https://www.modsecurity.org/tracker/browse/MODSEC-159
+
* Fixed restricted file extension bug with macro expansion
+
  https://www.modsecurity.org/tracker/browse/CORERULES-60
+
* Updated the SQLI TX variable macro expansion data in the 49 and 60 files so that
+
  it matches what is being set in the sql injection conf file
+
* Fixed typo in SQL Injection regexs - missing backslash for word boundary (b)
+
  https://www.modsecurity.org/tracker/browse/CORERULES-62 
+
 
+
 
+
== Version 2.0.8 - 08/27/2010 ==
+
 
+
 
+
Improvements:
+
* Updated the PHPIDS filters
+
* Updated the SQL Injection filters to detect boolean attacks (1<2, foo == bar, etc..)
+
* Updated the SQL Injection fitlers to account for different quotes
+
* Added UTF-8 encoding validation support to the modsecurity_crs_10_config.conf file
+
* Added Rule ID 950109 to detect multiple URL encodings
+
* Added two experimental rules to detect anomalous use of special characters
+
 
+
Bug Fixes:
+
* Fixed Encoding Detection RegEx (950107 and 950108)
+
* Fixed rules-updater.pl script to better handle whitespace
+
  https://www.modsecurity.org/tracker/browse/MODSEC-167
+
* Fixed missing pass action bug in modsecurity_crs_21_protocol_anomalies.conf
+
  https://www.modsecurity.org/tracker/browse/CORERULES-55
+
* Fixed the anomaly scoring in the modsecurity_crs_41_phpids_filters.conf file
+
  https://www.modsecurity.org/tracker/browse/CORERULES-54
+
* Updated XSS rule id 958001 to improve the .cookie regex to reduce false postives
+
  https://www.modsecurity.org/tracker/browse/CORERULES-29 
+
 
+
 
+
== Version 2.0.7 - 06/4/2010 ==
+
 
+
 
+
Improvements:
+
* Added CSRF Protection Ruleset which will use Content Injection to add javascript to
+
  specific outbound data and then validate the csrf token on subsequent requests.
+
* Added new Application Defect Ruleset which will identify/fix missing HTTPOnly cookie
+
  flags
+
* Added Experimental XSS/Missing Output Escaping Ruleset which looks for user supplied
+
  data being echoed back to user unchanged.
+
* Added rules-updater.pl script and configuration file to allow users to automatically
+
  download CRS rules from the CRS rules repository.
+
* Added new SQLi keyword for ciel() and reverse() functions.
+
* Updated the PHPIDS filters
+
 
+
 
+
Bug Fixes:
+
* Fixed false positives for Request Header Name matching in the 30 file by
+
  adding boundary characters. 
+
* Added missing pass actions to @pmFromFile prequalifier rules
+
* Added backslash to SQLi regex
+
  https://www.modsecurity.org/tracker/browse/CORERULES-41
+
* Fixed hard coded anomaly score in PHPIDS filter file
+
  https://www.modsecurity.org/tracker/browse/CORERULES-45
+
* Fixed restricted_extension false positive by adding boundary characters
+
 
+
 
+
== Version 2.0.6 - 02/26/2010 ==
+
 
+
 
+
Bug Fixes:
+
* Added missing transformation functions to SQLi rules.
+
  https://www.modsecurity.org/tracker/browse/CORERULES-32
+
* Fixed duplicate rule IDs.
+
  https://www.modsecurity.org/tracker/browse/CORERULES-33
+
* Fixed typo in @pmFromFile in the Comment SPAM rules
+
  https://www.modsecurity.org/tracker/browse/CORERULES-34
+
* Added macro expansion to Restricted Headers rule
+
  https://www.modsecurity.org/tracker/browse/CORERULES-35
+
* Fixed misspelled SecMarker
+
  https://www.modsecurity.org/tracker/browse/CORERULES-36
+
* Fixed missing chain action in Content-Type header check
+
  https://www.modsecurity.org/tracker/browse/CORERULES-37
+
* Update phpids filters to use pass action instead of block
+
 
+
 
+
== Version 2.0.5 - 02/01/2010 ==
+
 
+
 
+
Improvements:
+
* Removed previous 10 config files as they may conflict with local customized Mod configs.
+
* Added a new 10 config file that allows the user to globally set TX variables to turn on/off
+
  PARANOID_MODE inspection, set anomaly score levels and http policies.
+
  Must have ModSecurity 2.5.12 to use the macro expansion in numeric operators.
+
* Added Rule Logic and Reference links to rules descriptions.
+
* Added Rule IDs to all rules.
+
* Added tag data mapping to new OWASP Top 10 and AppSensor Projects, WASC Threat Classification
+
* Removed Apache limit directives from the 23 file
+
* Added macro expansion to 23 file checks.
+
* Added @pmFromFile check to 35 bad robots file
+
* Added malicious UA strings to 35 bad robots check
+
* Created an experimental rules file
+
* Updated HTTP Parameter Pollution (HPP) rule logic to concat data into a TX variable for inspection
+
* Removed TX inspections for generic attacks and reverted to standard ARGS inspection
+
  https://www.modsecurity.org/tracker/browse/MODSEC-120
+
* Updated the variable list for standard inspections (ARGS|ARGS_NAMES|XML:/*) and moved the other
+
  variables to the PARANOID list (REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS|TX:HPP_DATA)
+
* Moved converted ET Snort rules to the /optional_rules directory
+
* Created a new Header Tagging ruleset (optional_rules) that will add matched rule data to the
+
  request headers.
+
* Updated Inbound blocking conf file to use macro expansion from the 10 config file settings
+
* Added separate anomaly scores for inbound, outbound and total to be evaluated for blocking.
+
* Updated the regex logic in the (1=1) rule to factor in quotes and other logical operators.
+
* Updated the SPAMMER RBL check rules logic to only check once per IP/Day.
+
* Added new outbound malware link detection rules.
+
* Added PHP "call_user_func" to blacklist
+
  Identified by SOGETI ESEC R&D
+
+
Bug Fixes:
+
* Removed Non-numeric Rule IDs
+
  https://www.modsecurity.org/tracker/browse/CORERULES-28
+
* Updated the variable list on SQLi rules.
+
* Fixed outbound @pmFromFile action from allow to skipAfter to allow for outbound anomaly scoring
+
  and blocking
+
 
+
 
+
== Version 2.0.4 - 11/30/2009 ==
+
 
+
 
+
Improvements:
+
* Updated converted PHPIDS signatures (https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml)
+
* Updated PHPIDS rules logic to first search for payloads in ARGS and then if there is no match found
+
  then search more generically in request_body|request_uri_raw
+
* Updated PHPIDS rules logic to only set TX variables and to not log.  This allows for more clean
+
  exceptions in the 48 file which can then expire/delete false positive TX matches and adjust the
+
  anomaly scores.  These rules will then inspect for any TX variables in phase:5 and create appropriate
+
  alerts for any variable matches that exist. 
+
 
+
Bug Fixes:
+
* Added Anomaly Score check to the 60 correlation file to recheck the anomaly score at the end of
+
  phase:4 which would allow for blocking based on information leakage issues.
+
 
+
 
+
== Version 2.0.3 - 11/05/2009 ==
+
 
+
 
+
Improvements:
+
* Updated converted PHPIDS signatures (https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml)
+
* Create a new PHPIDS Converter rules file (https://svn.php-ids.org/svn/trunk/lib/IDS/Converter.php)
+
* Added new rules to identify multipart/form-data bypass attempts
+
* Increased anomaly scoring (+100) for REQBODY_PROCESSOR_ERROR alerts
+
 
+
Bug Fixes:
+
* Added t:urlDecodeUni transformation function to phpids rules to fix both false positives/negatives
+
  https://www.modsecurity.org/tracker/browse/CORERULES-17
+
* Added new variable locations to the phpids filters
+
  https://www.modsecurity.org/tracker/browse/CORERULES-19
+
* Use of transformation functions can cause false negatives - added multiMatch action to phpids rules
+
  https://www.modsecurity.org/tracker/browse/CORERULES-20
+
* Fixed multipart parsing evasion issues by adding strict parsing rules
+
  https://www.modsecurity.org/tracker/browse/CORERULES-21
+
* Fixed typo in xss rules (missing |)
+
  https://www.modsecurity.org/tracker/browse/CORERULES-22
+
* Fixed regex text in IE8 XSS filters (changed to lowercase)
+
  https://www.modsecurity.org/tracker/browse/CORERULES-23 
+
 
+
 
+
== 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
+
 
+
 
+
== Version 2.0.1 - 08/07/2009 ==
+
 
+
 
+
Improvements:
+
* Updated the transformation functions used in the XSS/SQLi rules to improve performance
+
  https://www.modsecurity.org/tracker/browse/CORERULES-10
+
 
+
* Updated the variable/target list in the XSS rules
+
  https://www.modsecurity.org/tracker/browse/CORERULES-11 
+
 
+
* Added XSS Filters from IE8
+
  https://www.modsecurity.org/tracker/browse/CORERULES-12
+
+
Bug Fixes:
+
* Rule 958297 - Fixed unescaped double-quote issue in Comment SPAM UA rule.
+
  https://www.modsecurity.org/tracker/browse/CORERULES-9
+
 
+
 
+
== Version 2.0.0 - 07/29/2009 ==
+
 
+
 
+
New Rules & Features:
+
* 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.
+
* Converted Snort Rules
+
    Emerging Threat web attack rules have been converted.
+
    http://www.emergingthreats.net/
+
* 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).
+
* Updated Comment SPAM Protections
+
    Updated rules to include RBL lookups and client fingerprinting concepts from
+
    Bad Behavior (www.bad-behavior.ioerror.us)
+
* Creation of Global Collection
+
    Automatically create a Global collection in the *10* config file.  Other rules
+
    can then access it.
+
* 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).
+
* "Possible HTTP Parameter Pollution Attack: Multiple Parameters with the same Name."
+
  http://tacticalwebappsec.blogspot.com/2009/05/http-parameter-pollution.html
+
* Added new generic RFI detection rules.
+
  http://tacticalwebappsec.blogspot.com/2009/06/generic-remote-file-inclusion-attack.html
+
* "Possibly malicious iframe tag in output" (Rules 981001,981002)
+
    Planting invisible iframes in a site can be used by attackers to point users
+
    from the victim site to their malicious site. This is actually as if the
+
    user was visiting the attacker's site himself, causing the user's browser to
+
    process the content in the attacker's site.
+
+
New Events:
+
* Rule 960019 - Expect Header Not Allowed.
+
* Rule 960020 - Pragma Header Requires Cache-Control Header
+
* Rule 958290 - Invalid Character in Request - Browsers should not send the (#) character
+
                as it is reserved for use as a fragment identifier within the html page.
+
* Rule 958291 - Range: field exists and begins with 0.
+
* Rule 958292 - Invalid Request Header Found.
+
* Rule 958293 - Lowercase Via Request Header Found.
+
* Rule 958294 - Common SPAM Proxies found in Via Request Header.
+
* Rule 958295 - Multiple/Conflicting Connection Header Data Found.
+
* Rule 958296 - Request Indicates a SPAM client accessed the Site.
+
* Rule 958297 - Common SPAM/Email Harvester crawler.
+
* Rule 958298 - Common SPAM/Email Harvester crawler
+
 
+
Bug Fixes:
+
* Rule 950107 - Split the rule into 2 separate rules to factor in the
+
                Content-Type when inspecting the REQUEST_BODY variable.
+
* Rule 960017 - Bug fix for when having port in the host header.
+
* Rule 960014 - Bug fix to correlate the SERVER_NAME variable.
+
* Rule 950801 - Increased the logic so that the rule will only run if the web site
+
                uses UTF-8 Encoding.
+
* Rules 999210,999211 - Bug fix to move ctl actions to last rule, add OPTIONS and
+
                        allow the IPv6 loopback address
+
* Rule 950117 - Updated the RFI logic to factor in both a trailing "?" in the ARG
+
                and to identify offsite hosts by comparing the ARG URI to the Host
+
                header.  Due to this rule now being stronger, moved it from optional
+
                tight security rule to *40* generic attacks file.
+
 
+
Other Fixes:
+
* Added more HTTP Protocol violations to *20* file.
+
* Set the SecDefaultAction in the *10* config file to log/pass (This was the
+
  default setting, however this sets it explicitly.
+
* Added SecResponseBodyLimitAction ProcessPartial to the *10* config file.  This
+
  was added so that when running the SecRuleEngine in DetectionOnly mode, it will
+
  not deny response bodies that go over the size restrictions.
+
* Changed SecServerSignature to "Apache/1.3.28"
+
* Fixed the use of SkipAfter and SecMarkers to make it consistent.  Now have
+
  BEGIN and END SecMarkers for rule groups to more accurately allow moving to
+
  proper locations.
+
* Fixed the @pm/@pmFromFile pre-qualifier logic to allow for operator inversion.
+
  This removes the need for some SecAction/SkipAfter rules.
+
* Updated rule formatting to easily show rule containers (SecMarkers, pre-qualifier
+
  rules and chained rules).
+
 
+
 
+
== Version 1.6.1 - 2008/04/22 ==
+
 
+
 
+
* Fixed a bug where phases and transformations where not specified explicitly
+
    in rules. The issue affected a significant number of rules, and we strongly
+
    recommend to upgrade.
+
 
+
 
+
== Version 1.6.0 - 2008/02/19 ==
+
 
+
 
+
New Rulesets & Features:
+
* 42 - Tight Security
+
    This ruleset contains currently 2 rules which are considered highly prone
+
    to FPs. They take care of Path Traversal attacks, and RFI attacks. This
+
    ruleset is included in the optional_rulesets dir
+
* 42 - Comment Spam
+
    Comment Spam is used by the spammers to increase their rating in search
+
    engines by posting links to their site in other sites that allow posting
+
    of comments and messages. The rules in this ruleset will work against that.
+
    (Requires ModSecurity 2.5)
+
* Tags
+
    A single type of attack is often detected by multiple rules. The new alert
+
    classification tags solve this issue by providing an alternative alert type
+
    indication and can serve for filtering and analysis of audit logs.
+
    The classification tags are hierarchical with slashes separating levels.
+
    Usually there are two levels with the top level describing the alert group
+
    and the lower level denoting the alert type itself, for example:
+
    WEB_ATTACK/SQL_INJECTION.
+
 
+
False Positives Fixes:
+
* Rule 960903 - Moved to phase 4 instead of 5 to avoid FPs
+
* Rule 950107 - Will look for invalid url decoding in variables that are not
+
                automatically url decoded
+
 
+
Additional rules logic:
+
* Using the new "logdata" action for logging the matched signature in rules
+
* When logging an event once, init the collection only if the alert needs to log
+
* Using the new operator @pm as a qualifier before large rules to enhance
+
    performance (Requires ModSecurity 2.5)
+
* SQL injection - A smarter regexp is used to detect 1=1,2=2,etc.. and not
+
    only 1=1. (Thanks to Marc Stern for the idea)
+
* New XSS signatures - iframe & flash XSS
+
 
+
 
+
 
+
== Version 1.5.1 - 2007/12/6 ==
+
 
+
 
+
False Positives Fixes:
+
* Protocol Anomalies (file 21) - exception for Apache SSL pinger (Request: GET /)
+
 
+
New Events:
+
* 960019 - Detect HTTP/0.9 Requests
+
  HTTP/0.9 request are not common these days. This rule will log by default,
+
  and block in the blocking version of file 21
+
 
+
Other Fixes:
+
* File 40, Rules 950004,950005 - Repaired the correction for the double
+
  url decoding problem
+
* File 55 contained empty regular expressions. Fixed.           
+
 
+
 
+
== Version 1.5 - 2007/11/23 ==
+
 
+
 
+
New Rulesets:
+
* 23 - Request Limits
+
    "Judging by appearances". This rulesets contains rules blocking based on
+
    the size of the request, for example, a request with too many arguments
+
    will be denied.
+
 
+
Default policy changes:
+
* XML protection off by default
+
* BLOCKING dir renamed to optional_rules
+
* Ruleset 55 (marketing) is now optional (added to the optional_rules dir)
+
* Ruleset 21 - The exception for apache internal monitor will not log anymore
+
 
+
New Events:
+
* 960912 - Invalid request body
+
  Malformed content will not be parsed by modsecurity, but still there might
+
  be applications that will parse it, ignoring the errors.
+
* 960913 - Invalid Request
+
  Will trigger a security event when request was rejected by apache with
+
  code 400, without going through ModSecurity rules.
+
 
+
Additional rules logic:
+
* 950001 - New signature: delete from
+
* 950007 - New signature: waitfor delay
+
 
+
False Positives Fixes:
+
* 950006 - Will not be looking for /cc pattern in User-Agent header
+
* 950002 - "Internet Explorer" signature removed
+
* Double decoding bug used to cause FPs. Some of the parameters are already
+
  url-decoded by apache. This caused FPs when the rule performed another
+
  url-decoding transformation. The rules have been split so that parameters
+
  already decoded by apache will not be decoded by the rules anymore.
+
* 960911 - Expression is much more permissive now
+
* 950801 - Commented out entirely. NOTE: If your system uses UTF8 encoding,
+
          then you should uncomment this rule (in file 20)
+
 
+
 
+
version 1.4.3 - 2007/07/21
+
 
+
 
+
New Events:
+
* 950012 - HTTP Request Smuggling
+
  For more info on this attack:
+
  http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
+
* 960912 - Invalid request body
+
  Malformed content will not be parsed by modsecurity, but still there might
+
  be applications that will parse it, ignoring the errors.
+
* 960913 - Invalid Request
+
  Will trigger a security event when request was rejected by apache with
+
  code 400, without going through ModSecurity rules.
+
 
+
False Positives Fixes:
+
* 950107 - Will allow a % sign in the middle of a string as well
+
* 960911 - A more accurate expression based on the rfc:
+
            http://www.ietf.org/rfc/rfc2396.txt
+
* 950015 - Will not look for http/ pattern in the request headers
+
 
+
Additional rules logic:
+
* Since Apache applies scope directives only after ModSecurity phase 1
+
  this directives cannot be used to exclude phase 1 rules. Therefore
+
  we moved all inspection rules to phase 2.
+
 
+
 
+
 
+
version 1.4 build 2 - 2007/05/17
+
 
+
 
+
New Feature:
+
* Search for signatures in XML content
+
    XML Content will be parsed and ispected for signatures
+
 
+
New Events:
+
* 950116 - Unicode Full/Half Width Abuse Attack Attempt
+
    Full-width unicode can by used to bypass content inspection. Such encoding will be forbidden
+
    http://www.kb.cert.org/vuls/id/739224
+
* 960911 - Invalid HTTP request line
+
    Enforce request line to be valid, i.e.: <METHOD> <path> <HTTP version>
+
* 960904 - Request Missing Content-Type (when there is content)
+
    When a request contains content, the content-type must be specified. If not, the content will not be inspected
+
* 970018 - IIS installed in default location (any drive)
+
    Log once if IIS in installed in the /Inetpub directory (on any drive, not only C)
+
* 950019 - Email Injection
+
    Web forms used for sending mail (such as "tell a friend") are often manipulated by spammers for sending anonymous emails
+
 
+
Regular expressions fixes:
+
* Further optimization of some regular expressions (using the non-greediness operator)
+
    The non-greediness operator, <?>, prevents excessive backtracking
+
 
+
FP fixes:
+
* Rule 950107 - Will allow a parameter to end in a % sign from now on
+
 
+
 
+
version 1.4 - 2007/05/02
+
 
+
 
+
New Events:
+
* 970021 - WebLogic information disclosure
+
    Matching of "<title>JSP compile error</title>" in the response body, will trigger this rule, with severity 4 (Warning)
+
* 950015,950910,950911 - HTTP Response Splitting
+
    Looking for HTTP Response Splitting patterns as described in Amit Klein's excellent white paper:
+
    http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf
+
ModSecurity does not support compressed content at the moment. Thus, the following rules have been added:
+
* 960902 - Content-Encoding in request not supported
+
    Any incoming compressed request will be denied
+
* 960903 - Content-Encoding in response not suppoted
+
    An outgoing compressed response will be logged to alert, but ONLY ONCE.
+
 
+
False Positives Fixes:
+
* Removed <.exe>,<.shtml> from restricted extensions
+
* Will not be looking for SQL Injection signatures <root@>,<coalesce> in the Via request header
+
* Excluded Referer header from SQL injection, XSS and command injection rules
+
* Excluded X-OS-Prefs header from command injection rule
+
* Will be looking for command injection signatures in
+
  REQUEST_COOKIES|REQUEST_COOKIES_NAMES instead of REQUEST_HEADERS:Cookie.
+
* Allowing charset specification in the <application/x-www-form-urlencoded> Content-Type
+
 
+
Additional rules logic:
+
* Corrected match of OPTIONS method in event 960015
+
* Changed location for event 960014 (proxy access) to REQUEST_URI_RAW
+
* Moved all rules apart from method inspection from phase 1 to phase 2 -
+
    This will enable viewing content if such a rule triggers as well as setting
+
    exceptions using Apache scope tags.
+
* Added match for double quote in addition to single quote for <or x=x> signature (SQL Injection)
+
* Added 1=1 signature (SQL Injection)
+
 
+
 
+
version 1.3.2 build 4 2007/01/17
+
 
+
 
+
Fixed apache 2.4 dummy requests exclusion
+
Added persistent PDF UXSS detection rule
+
 
+
 
+
== Version 1.3.2 build 3 2007/01/10 ==
+
 
+
 
+
Fixed regular expression in rule 960010 (file #30) to allow multipart form data
+
content
+
 
+
 
+
== Version 1.3.2 - 2006/12/27 ==
+
 
+
 
+
New events:
+
* 960037  Directory is restricted by policy
+
* 960038  HTTP header is restricted by policy
+
 
+
Regular expressions fixes:
+
* Regular expressions with @ at end of beginning (for example "@import)
+
* Regular expressions with un-escaped "."
+
* Command Injections now always require certain characters both before and after the command. Important since many are common English words (finger, mail)
+
* The command injection wget is not searched in the UA header as it has different meaning there.
+
* LDAP Fixed to reduce FPs:
+
  + More accurate regular expressions
+
  + high bit characters not accpeted between signature tokens.
+
* Do not detect <?xml as a PHP tag in both PHP injection and PHP source leakage
+
* Removed Java from automation UA
+
* When validating encoding, added regexp based chained rule that accepts both %xx and %uxxxxx encoding bypassing a limitation of "@validateUrlEncoding"
+
 
+
Additional rules logic:
+
* Checks for empty headers in addition to missing ones  (Host, Accept and User-Agent)
+
* OPTIONS method does not require an accept header.
+
* Apache keep alive request exception.
+
* PROPFIND and OPTIONS can be used without content-encoding (like HEAD and GET)
+
* Validate byte range checks by default only that no NULL char exists.
+
* Added CSS to allowed extensions in strict rule sets.
+
* Changed default action in file #50 to pass instead of deny.
+
* Moved IP host header from protocol violations to protocol anomalies.
+
 
+
Modified descriptions:
+
* 950107: URL Encoding Abuse Attack Attempt
+
* 950801: UTF8 Encoding Abuse Attack Attempt
+
* Added matched pattern in many events using capture and %{TX.0}
+
* Added ctl:auditLogParts=+E for outbound events and attacks to collect response.
+
 
+
 
+
== Version 1.2 - 2006/11/19 ==
+
 
+
 
+
Changes:
+
+ Move all events to the range of events allocated to Thinking Stone, now Breach
+
by prefixing all event IDs with "9".
+
+ Reverse severities to follow the Syslog format used by ModSecurity, now 1 is
+
the highest and 5 the lowest.
+
 
+
Bug fixes:
+
+ Removed quotes from list of mime types inspected on exit (directive
+
SecResponseBodyMimeType)
+
+ Corrected "cd .." signature. Now the periods are escaped.
+
+ Too many FPs with events 950903 & 950905. Commented them out until fixed.
+
 
+
 
+
== Version 1.1 - 2006/10/18 ==
+
 
+
 
+
Initial version
+
 
+
= Roadmap =
+
  
=== Roadmap Items ===
+
= 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.
  
Line 1,371: Line 421:
 
### Tag client as "suspicious" in IP collection
 
### Tag client as "suspicious" in IP collection
  
<!-- ==== Project Details ====
+
Involvement in the development and promotion of OWASP ModSecurity CRS is actively encouraged!
{{:Key Project Information:OWASP ModSecurity Core Rule Set Project}}  -->
+
You do not have to be a security expert in order to contribute.
 
+
Some of the ways you can help:
<!-- ==== Project Details ====
+
* Contribute on the mail-list by answering questions from the community
{{:GPC Project Details/OWASP ModSecurity Core Rule Set Project | OWASP Project Identification Tab}}  -->
+
* Report issues to our GitHub Issue tracker
 
+
==== Project About ====
+
  
{{:Projects/OWASP_ModSecurity_Core_Rule_Set_Project | Project About}}
 
  
__NOTOC__ <headertabs /> <br>
 
  
''The CRS is an open source rule set licensed under ASLv2. ModSecurity Core Rule Set works with ModSecurity 2.5 and above.''
+
=Project About=
 +
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}} 
  
 +
__NOTOC__ <headertabs />
  
[[Category:OWASP Project|ModSecurity Core Rule Set Project]]
+
[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]]
[[Category:OWASP WAF|ModSecurity Core Rule Set Project]]
+
[[Category:OWASP Tool]]
+
[[Category:OWASP Release Quality Tool]]
+
[[Category:OWASP Download]]
+

Latest revision as of 19:43, 23 February 2015

Flagship banner.jpg

[edit]

OWASP ModSecurity Core Rule Set (CRS)

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.

Introduction

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform ModSecurity Web Application Firewall (WAF).

Description

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:

  • 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

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.

Open HUB

https://www.openhub.net/p/owasp-modsecurity-crs

What is OWASP ModSecurity CRS?

OWASP ModSecurity CRS provides:

  • Baseline protection for common web application attacks.

Presentation

Project Leader

Project Leader:

Contributors:

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

funds to OWASP earmarked for ModSecurity Core Rule Set Project.

Who Leads the ModSecurity Project?

ModSecurity is supported by Trustwave's SpiderLabs Team [1] and includes the following team members:

  • Ryan Barnett - ModSecurity Project Lead and OWASP ModSecurity Core Rule Set Project Lead
  • Felipe Zimmerle Costa - ModSecurity Lead Developer

Suggestions for enhancements of this document are always welcome. Please email them to the Mod-Security-Users mailing list [2].

Background and Support

What exactly is ModSecurity?

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

Commercial Help

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 [3] 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

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.

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?

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):

SecRule REMOTE_ADDR "@ipMatch 192.168.110" phase:1,nolog,allow,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

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?

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.

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

Ryan Barnett

Project Contributors

Josh Zlatin
Brian Rectanus
Roberto Salgado
Nick Galbreath

Project Users

WASC Distributed Web Honeypot Project uses the Core Rule Set - http://projects.webappsec.org/Distributed-Web-Honeypots

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


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.

  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

Detection Logic/Flow Concepts

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


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):
Project Contributor(s):
  • Breno Silva
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
}

Pages in category "OWASP ModSecurity Core Rule Set Project"

The following 4 pages are in this category, out of 4 total.