OWASP - User contributions [en]

Category:OWASP ModSecurity Core Rule Set Project

2017-11-19T16:31:26Z

Dune73:

File:CRS-logo-full size-512x257.png

2017-11-19T16:29:34Z

Dune73:

Category:OWASP ModSecurity Core Rule Set Project

2017-11-19T16:25:56Z

Dune73:

2017-08-15T09:56:51Z

2017-01-09T21:40:03Z

Dune73: /* Conference Papers / Presentation */

This is a work in progress page about our plans for the CRS at AppSecEU 2017.

* Conference website: https://2017.appsec.eu/
* Training dates: 8th, 9th & 10th of May 2017
* Conference dates: 11th & 12th of May 2017

=== Training ===

We offer a free Apache / ModSecurity / CRS training course based on Christian's course material at https://netnea.com/cms/apache-tutorials

* CFT Application: Christian
* Teacher: Christian
* Support: Chaim - Always willing to help :)
* Call for Trainings: https://2017.appsec.eu/program/call-for-trainings
* Status: Has been submitted on January 2: https://easychair.org/conferences/submission.cgi?a=13528833;submission=3078201

=== Conference Papers / Presentation ===

* Call for Papers: https://2017.appsec.eu/program/call-for-papers
* Deadline: '''January 9, 2017'''

* Paper #1: CRS3: Introduction to CRS3 and the new Features
** Presenter: Christian (Chaim can help if needed)
** Status: Submitted January 8th
* Paper #2: Testing FTW! A Modern, Open Source Approach to testing WAFs
** Presenter: Chaim Sanders, Zach Allen and Christian Peron
** Status: Submitted January 8th
* Paper #3: On the use of client side WAFs - it’s no WAFing matter
** Presenter: Chaim Sanders
** Status: Submitted January 8th
* Paper #4: A Core Rule Set War Report
** Presenter: Christian Folini
** Status: Submitted January 8th

=== Conference Activities ===

* Call for Activities: https://2017.appsec.eu/program/call-for-activities
* Deadline: none

==== CRS Summit ====

Inviting the Community and all Commercial Suppliers using / interested in CRS rules, maybe evening of May 10

* Head of CRS Summit: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Hackathon ====

Hacking away together for a day. Maybe May 10

* Head of CRS Hackathon: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Installation Party ====

Helping people get started with the CRS, probably 1/2 day during the conference

* Head of Installation Party
* Status: FIXME
* Date / Time / Location: FIXME

==== Hack CRS ====

Offer a prize to break execute an attack against a website protected with CRS throughout the conference

* Head of Development: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

CRSAppSecEU2017

2017-01-02T16:56:45Z

Dune73:

CRSAppSecEU2017

2017-01-02T16:48:18Z

Dune73:

Category:OWASP ModSecurity Core Rule Set Project

2016-12-20T19:25:03Z

Dune73: /* Getting Started / Tutorials */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

'''The 1st Line of Defense Against Web Application Attacks'''

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

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

==Description==

{| style="width: 100%;"
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
* SQL Injection (SQLi)
* Cross Site Scripting (XSS)
* Local File Inclusion (LFI)
* Remote File Inclusion (RFI)
* Remote Code Execution (RCE)
* PHP Code Injection
* HTTP Protocol Violations
* Shellshock
* Session Fixation
* Scanner Detection
* Metadata/Error Leakages
* Project Honey Pot Blacklist
* GeoIP Country Blocking

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

| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
|}

==Getting Started / Tutorials==

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;" |

== Project Members ==

Project Leader:
* [[:User:Chaim_sanders|Chaim Sanders]]

Contributors:
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Related Projects ==

*[[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_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]

| valign="top" style="padding-left:25px;width:200px;" |

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| 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=]]
|}

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

|}

=Getting Started=

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

=FAQs=

== ModSecurity Rules Language ==

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

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

=== What attacks do the Core Rules protect against? ===

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

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

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

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

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

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

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

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

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

=== How do I handle False Positives and creating Custom Rules? ===

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

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

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

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

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

== Managing Alerts ==

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

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

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

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

=== Can I send ModSecurity alert log data through Syslog? ===

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

= Acknowledgements =

== Project Leader ==

[[:User:Chaim_sanders|Chaim Sanders]]

== Project Contributors ==

*[[:User:Chaim_sanders|Chaim Sanders]]
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
*[[:User:Brian_Rectanus|Brian Rectanus]]
*[[:user:Roberto_Salgado|Roberto Salgado]]
*Nick Galbreath (libinjection)

See changelog for more contributors.

== Project Users ==

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

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

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

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

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

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

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]

= Getting Involved =

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

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

FIXME

== Plans for AppSecEU 2017 ==

See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]

== Archive: v3.0 Detection Concepts / Goals ==

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

These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## 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)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### 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

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

=CRS3 Poster=

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

The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).

[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Category:OWASP ModSecurity Core Rule Set Project

2016-12-20T19:24:42Z

Dune73: /* Getting Started / Tutorials */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

'''The 1st Line of Defense Against Web Application Attacks'''

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

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

==Description==

{| style="width: 100%;"
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
* SQL Injection (SQLi)
* Cross Site Scripting (XSS)
* Local File Inclusion (LFI)
* Remote File Inclusion (RFI)
* Remote Code Execution (RCE)
* PHP Code Injection
* HTTP Protocol Violations
* Shellshock
* Session Fixation
* Scanner Detection
* Metadata/Error Leakages
* Project Honey Pot Blacklist
* GeoIP Country Blocking

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

| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
|}

==Getting Started / Tutorials==

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;" |

== Project Members ==

Project Leader:
* [[:User:Chaim_sanders|Chaim Sanders]]

Contributors:
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Related Projects ==

*[[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_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]

| valign="top" style="padding-left:25px;width:200px;" |

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| 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=]]
|}

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

|}

=Getting Started=

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

=FAQs=

== ModSecurity Rules Language ==

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

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

=== What attacks do the Core Rules protect against? ===

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

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

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

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

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

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

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

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

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

=== How do I handle False Positives and creating Custom Rules? ===

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

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

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

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

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

== Managing Alerts ==

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

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

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

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

=== Can I send ModSecurity alert log data through Syslog? ===

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

= Acknowledgements =

== Project Leader ==

[[:User:Chaim_sanders|Chaim Sanders]]

== Project Contributors ==

*[[:User:Chaim_sanders|Chaim Sanders]]
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
*[[:User:Brian_Rectanus|Brian Rectanus]]
*[[:user:Roberto_Salgado|Roberto Salgado]]
*Nick Galbreath (libinjection)

See changelog for more contributors.

== Project Users ==

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

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

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

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

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

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

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]

= Getting Involved =

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

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

FIXME

== Plans for AppSecEU 2017 ==

See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]

== Archive: v3.0 Detection Concepts / Goals ==

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

These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## 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)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### 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

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

=CRS3 Poster=

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

The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).

[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Category:OWASP ModSecurity Core Rule Set Project

2016-12-20T19:24:02Z

Dune73: /* Getting Started / Tutorials */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

'''The 1st Line of Defense Against Web Application Attacks'''

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

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

==Description==

{| style="width: 100%;"
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
* SQL Injection (SQLi)
* Cross Site Scripting (XSS)
* Local File Inclusion (LFI)
* Remote File Inclusion (RFI)
* Remote Code Execution (RCE)
* PHP Code Injection
* HTTP Protocol Violations
* Shellshock
* Session Fixation
* Scanner Detection
* Metadata/Error Leakages
* Project Honey Pot Blacklist
* GeoIP Country Blocking

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

| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
|}

==Getting Started / Tutorials==

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

More Information at [https://modsecurity.org/crs https://modsecurity.org/crs].<br/>
You can find a full list of all the rules in the Core Rule Set at [https://netnea.com/crs https://netnea.com/crs]

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;" |

== Project Members ==

Project Leader:
* [[:User:Chaim_sanders|Chaim Sanders]]

Contributors:
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Related Projects ==

*[[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_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]

| valign="top" style="padding-left:25px;width:200px;" |

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| 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=]]
|}

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

|}

=Getting Started=

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

=FAQs=

== ModSecurity Rules Language ==

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

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

=== What attacks do the Core Rules protect against? ===

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

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

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

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

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

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

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

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

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

=== How do I handle False Positives and creating Custom Rules? ===

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

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

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

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

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

== Managing Alerts ==

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

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

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

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

=== Can I send ModSecurity alert log data through Syslog? ===

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

= Acknowledgements =

== Project Leader ==

[[:User:Chaim_sanders|Chaim Sanders]]

== Project Contributors ==

*[[:User:Chaim_sanders|Chaim Sanders]]
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
*[[:User:Brian_Rectanus|Brian Rectanus]]
*[[:user:Roberto_Salgado|Roberto Salgado]]
*Nick Galbreath (libinjection)

See changelog for more contributors.

== Project Users ==

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

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

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

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

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

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

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]

= Getting Involved =

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

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

FIXME

== Plans for AppSecEU 2017 ==

See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]

== Archive: v3.0 Detection Concepts / Goals ==

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

These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## 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)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### 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

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

=CRS3 Poster=

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

The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).

[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

Category:OWASP ModSecurity Core Rule Set Project

2016-12-20T19:23:40Z

Dune73: /* Getting Started / Tutorials */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

'''The 1st Line of Defense Against Web Application Attacks'''

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

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

==Description==

{| style="width: 100%;"
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
* SQL Injection (SQLi)
* Cross Site Scripting (XSS)
* Local File Inclusion (LFI)
* Remote File Inclusion (RFI)
* Remote Code Execution (RCE)
* PHP Code Injection
* HTTP Protocol Violations
* Shellshock
* Session Fixation
* Scanner Detection
* Metadata/Error Leakages
* Project Honey Pot Blacklist
* GeoIP Country Blocking

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

| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
|}

==Getting Started / Tutorials==

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

More Information at [https://modsecurity.org/crs https://modsecurity.org/crs].<br/>
You can find a full list of all the rules in the Core Rule Set at [https://netnea.com/crs]

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

| valign="top" style="padding-left:25px;width:200px;" |

== Project Members ==

Project Leader:
* [[:User:Chaim_sanders|Chaim Sanders]]

Contributors:
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Related Projects ==

*[[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_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]

| valign="top" style="padding-left:25px;width:200px;" |

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| 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=]]
|}

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

|}

=Getting Started=

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

=FAQs=

== ModSecurity Rules Language ==

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

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

=== What attacks do the Core Rules protect against? ===

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

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

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

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

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

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

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

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

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

=== How do I handle False Positives and creating Custom Rules? ===

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

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

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

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

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

== Managing Alerts ==

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

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

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

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

=== Can I send ModSecurity alert log data through Syslog? ===

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

= Acknowledgements =

== Project Leader ==

[[:User:Chaim_sanders|Chaim Sanders]]

== Project Contributors ==

*[[:User:Chaim_sanders|Chaim Sanders]]
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
*[[:User:Brian_Rectanus|Brian Rectanus]]
*[[:user:Roberto_Salgado|Roberto Salgado]]
*Nick Galbreath (libinjection)

See changelog for more contributors.

== Project Users ==

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

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

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

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

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

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

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]

= Getting Involved =

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

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

FIXME

== Plans for AppSecEU 2017 ==

See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]

== Archive: v3.0 Detection Concepts / Goals ==

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

These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## 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)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### 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

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

=CRS3 Poster=

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

The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).

[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]

CRSAppSecEU2017

2016-12-15T10:04:04Z

Dune73:

CRSAppSecEU2017

2016-12-15T09:59:57Z

Dune73:

This is a work in progress page about our plans for the CRS at AppSecEU 2017.

https://2017.appsec.eu/
* Training 8th, 9th & 10th of May 2017
* Conference 11th & 12th of May 2017

=== Training ===

We offer a free Apache / ModSecurity / CRS training course based on Christian's course material at https://netnea.com/cms/apache-tutorials

* CFT Application: Christian
* Teacher: Christian
* Support: FIXME (above 8 students, I need a sidekick)
* Call for Trainings: https://2017.appsec.eu/program/call-for-trainings
* Deadline: '''January 2, 2017'''

=== Conference Papers / Presentation ===

* Call for Papers: https://2017.appsec.eu/program/call-for-papers
* Deadline: '''January 9, 2017'''

* Paper #1: CRS3: Introduction to CRS3 and the new Features,
** Presenter: FIXME
* Paper #2: FIXME
** Presenter: FIXME
* Paper #3: FIXME
** Presenter: FIXME
* Paper #4: FIXME
** Presenter: FIXME

=== Conference Activities ===

* Call for Activities: https://2017.appsec.eu/program/call-for-activities
* Deadline: none

==== CRS Summit ====

Inviting the Community and all Commercial Suppliers using / interested in CRS rules, maybe evening of May 10

* Head of CRS Summit: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Hackathon ====

Hacking away together for a day. Maybe May 10

* Head of CRS Hackathon: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Installation Party ====

Helping people get started with the CRS, probably 1/2 day during the conference

* Head of Installation Party
* Status: FIXME
* Date / Time / Location: FIXME

CRSAppSecEU2017

2016-12-15T09:57:57Z

Dune73: Created page with "= Plans for AppsSecEU 2017 in Belfast = https://2017.appsec.eu/ * Training 8th, 9th & 10th of May 2017 * Conference 11th & 12th of May 2017 === Training === We offer a free..."

= Plans for AppsSecEU 2017 in Belfast =

https://2017.appsec.eu/
* Training 8th, 9th & 10th of May 2017
* Conference 11th & 12th of May 2017

=== Training ===

We offer a free Apache / ModSecurity / CRS training course based on Christian's course material at https://netnea.com/cms/apache-tutorials

* CFT Application: Christian
* Teacher: Christian
* Support: FIXME (above 8 students, I need a sidekick)
* Call for Trainings: https://2017.appsec.eu/program/call-for-trainings
* Deadline: '''January 2, 2017'''

=== Conference Papers / Presentation ===

* Call for Papers: https://2017.appsec.eu/program/call-for-papers
* Deadline: '''January 9, 2017'''

* Paper #1: CRS3: Introduction to CRS3 and the new Features,
** Presenter: FIXME
* Paper #2: FIXME
** Presenter: FIXME
* Paper #3: FIXME
** Presenter: FIXME
* Paper #4: FIXME
** Presenter: FIXME

=== Conference Activities ===

* Call for Activities: https://2017.appsec.eu/program/call-for-activities
* Deadline: none

==== CRS Summit ====

Inviting the Community and all Commercial Suppliers using / interested in CRS rules, maybe evening of May 10

* Head of CRS Summit: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Hackathon ====

Hacking away together for a day. Maybe May 10

* Head of CRS Hackathon: FIXME
* Status: FIXME
* Date / Time / Location: FIXME

==== CRS Installation Party ====

Helping people get started with the CRS, probably 1/2 day during the conference

* Head of Installation Party
* Status: FIXME
* Date / Time / Location: FIXME

Category:OWASP ModSecurity Core Rule Set Project

2016-12-15T09:57:32Z

Dune73: /* Plans for AppSecEU 2017 */

=Main=
<div style="width:100%;height:90px;border:0,margin:0;overflow: hidden;">[[File: flagship_big.jpg|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Flagship_Projects]]</div>
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |

==OWASP ModSecurity Core Rule Set (CRS)==

'''The 1st Line of Defense Against Web Application Attacks'''

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

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

==Description==

{| style="width: 100%;"
| style="vertical-align:top;" | The OWASP ModSecurity CRS provides protections in the following attack/threat categories:
* SQL Injection (SQLi)
* Cross Site Scripting (XSS)
* Local File Inclusion (LFI)
* Remote File Inclusion (RFI)
* Remote Code Execution (RCE)
* PHP Code Injection
* HTTP Protocol Violations
* Shellshock
* Session Fixation
* Scanner Detection
* Metadata/Error Leakages
* Project Honey Pot Blacklist
* GeoIP Country Blocking

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

| style="text-align:right;" | [[File:CRS3-movie-poster-thumb.jpeg|300px|link=https://coreruleset.org/poster]]
|}

==Getting Started / Tutorials==

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

==Licensing==
OWASP ModSecurity CRS is free to use. It is licensed under the [http://www.apache.org/licenses/LICENSE-2.0.txt Apache Software License version 2 (ASLv2)], so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

| valign="top" style="padding-left:25px;width:200px;" |

== Project Members ==

Project Leader:
* [[:User:Chaim_sanders|Chaim Sanders]]

Contributors:
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]

== Presentation ==

*[https://www.owasp.org/images/a/a9/AppSecDC_2010-ModSecurityCRS_Ryan_Barnett.ppt OWASP ModSecurity CRS Preso - PPT]
*[http://vimeo.com/20166971 OWASP ModSecurity CRS Preso - Video]

== Related Projects ==

*[[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_AppSensor_Project OWASP AppSensor Project]]
*[[https://www.owasp.org/index.php/Category:OWASP_Blacklist_Regex_Repository OWASP Blacklist Regex Repository]]

== Quick Download ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.tar.gz Latest CRS (TAR/GZ)]
* [https://github.com/SpiderLabs/owasp-modsecurity-crs/archive/v3.0.0.zip Latest CRS (ZIP)]

| valign="top" style="padding-left:25px;width:200px;" |

== Source Code Repo ==

* [https://github.com/SpiderLabs/owasp-modsecurity-crs OWASP ModSecurity CRS on GitHub]

== News and Events ==
* [10 Nov 2016] - [https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2016-November/002265.html CRS3 Released]

== Mailing List ==

*[https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set OWASP CRS Mail-list]

==Classifications==

{| 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=]]
|}

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

|}

=Getting Started=

The following tutorials will get you started with ModSecurity and the CRS v3.
* [https://www.netnea.com/cms/apache-tutorial-6_embedding-modsecurity/ Installing ModSecurity]
* [https://www.netnea.com/cms/apache-tutorial-7_including-modsecurity-core-rules/ Including the OWASP ModSecurity Core Rule Set]
* [https://www.netnea.com/cms/apache-tutorial-8_handling-false-positives-modsecurity-core-rule-set/ Handling False Positives with the OWASP ModSecurity Core Rule Set]

These tutorials are part of a big series of Apache / ModSecurity guides published by [https://www.netnea.com/cms/apache-tutorials netnea]. They are written by [[:user:Dune73|Christian Folini]].

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

=FAQs=

== ModSecurity Rules Language ==

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

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

=== What attacks do the Core Rules protect against? ===

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

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

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

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

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

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

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

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

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

=== How do I handle False Positives and creating Custom Rules? ===

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

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

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

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

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

== Managing Alerts ==

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

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

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

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

=== Can I send ModSecurity alert log data through Syslog? ===

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

= Acknowledgements =

== Project Leader ==

[[:User:Chaim_sanders|Chaim Sanders]]

== Project Contributors ==

*[[:User:Chaim_sanders|Chaim Sanders]]
*[[:user:Dune73|Christian Folini]]
*[[:User:lifeforms|Walter Hop]]
*[[:User:Rcbarnett|Ryan Barnett]]
*[[:User:Josh Amishav-Zlatin|Josh Zlatin]]
*[[:User:Brian_Rectanus|Brian Rectanus]]
*[[:user:Roberto_Salgado|Roberto Salgado]]
*Nick Galbreath (libinjection)

See changelog for more contributors.

== Project Users ==

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

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

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

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

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

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

== Project Sponsors ==

[[Image:SpiderLabs Logo 2011.JPG|200px|link=https://www.trustwave.com/spiderLabs.php]]

= Getting Involved =

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

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

FIXME

== Plans for AppSecEU 2017 ==

See separate page: [[CRSAppSecEU2017|Plans for AppSecEU 2017]]

== Archive: v3.0 Detection Concepts / Goals ==

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

These are not listed in any particular order.
# '''Add New Detection Logic'''
## Fraud Detection (Session Hijacking/CSRF/Banking Trojans)
## User Profiling (GeoIP/Browser Fingerprinting)
## HoneyTraps
# '''Increase Rule Accuracy'''
## Reduce False Positives - many users complain about the number of false positives and the negative impacts (breaking functionality) when in blocking mode
## 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)
# '''Increase Performance/Reduce Latency'''
## Utilize set-based pattern matching (@pm/@pmf) for pre-qualification of regular expression checks
## Optimize individual @rx SecRules into less optimized versions
## Review all regular expression rules for performance (non-capturing/greediness).
# '''Improve Rule Management'''
## Make it easier for user to enable/disable the desired rules for their platform
## Update rule formatting for easier readability
## Reorder/Regroup rule into new file names

== Archive: Detection Logic/Flow Concepts in the Request Header Phase ==
This section outlines the processing flow and associated points of detection and actions taken.
# '''IP Reputation'''
## Data inspected: REMOTE_ADDR
## Use @rbl to check against remote RBLs
## Use @pmf to check a local file if bad IPs
## Use GeoIP Data to assign fraud scores
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Method Analysis'''
## Data inspected: REQUEST_METHOD
## Compare the REQUEST_METHOD specified against:
### Allowed global methods set by the admin in the modsecurity_crs_10_setup.conf file
### Request methods allowed per-resource (GET vs. POST)
## '''Actions'''
### Deny
### Increase TX anomaly score
### Tag client as "suspicious" in IP collection
# '''Request Header Analysis'''
## Data inspected: REQUESTE_HEADERS
## Check for existence of malicious headers (User-Agent of scanners, etc..)
## Check for the absence of required headers (Host, User-Agent, Accept)
## Request Header Ordering Anomalies detects non-browsers/bots
## '''Actions'''
### Deny
### Increase TX anomaly score
### 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

=Upcoming Major Release 3.0.0=

The upcoming major Core Rules (CRS) release 3.0.0 is currently being developed in a separate branch on [https://github.com/SpiderLabs/owasp-modsecurity-crs/tree/v3.0.0-rc1 github]. The release is planned for the first quarter 2016. It brings incorporation of the <tt>@detectsqli</tt> and <tt>@detectxss</tt> operators and a general reduction of false positives for default setups.

==Infos about 3.0.0==
* [https://www.netnea.com/cms/2015/12/20/modsec-crs-2-2-x-vs-3-0-0-dev/ Blogpost comparing CRS 2.2.x with 3.0.0-dev]

===Development===

* [[OWASP_ModSec_CRS_Paranoia_Mode | Paranoia Mode / Bringing back the rules that used to yield a high number of false positives]]

=Project About=
{{:Projects/OWASP ModSecurity Core Rule Set Project | Project About}}}

=CRS3 Poster=

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

The [https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg large version] has a 300 dpi resolution, big enough to be printed in A2, A1, or even A0 format. The format is the standard poster size format 500mm x 700mm (19.68in x 27.56in).

[[File:CRS3-movie-poster-small.jpg|1280px|link=https://www.owasp.org/images/e/eb/CRS3-movie-poster-nourl-5906x8268.jpeg]]

__NOTOC__ <headertabs />

[[Category:OWASP Project]] [[Category:OWASP_Defenders]] [[Category:OWASP_Document]] [[Category:SAMM-EH-3]]