Category:OWASP ModSecurity Core Rule Set Project

From OWASP
Revision as of 13:40, 7 June 2012 by Rcbarnett (Talk | contribs)

Jump to: navigation, search
OWASP Defenders logo.png This project is part of the OWASP Defenders community.
Feel free to browse other projects within the Defenders, Builders, and Breakers communities.


funds to OWASP earmarked for ModSecurity Core Rule Set Project.

[edit]

Overview

ModSecurity™ is a web application firewall engine that provides very little protection on its own. In order to become useful, ModSecurity™ must be configured with rules. In order to enable users to take full advantage of ModSecurity™ out of the box, Trustwave's SpiderLabs is providing a free certified rule set for ModSecurity™ 2.x. Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the Core Rules provide generic protection from unknown vulnerabilities often found in web applications, which are in most cases custom coded. The Core Rules are heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity™.

Core Rules Content

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.
  • Real-time Blacklist Lookups - utilizes 3rd Party IP Reputation
  • Web-based Malware Detection - identifies malicious web content by check against the Google Safe Browsing API.
  • HTTP Denial of Service Protections - defense against HTTP Flooding and Slow HTTP DoS Attacks.
  • Common Web Attacks Protection - detecting common web application security attack.
  • Automation Detection - Detecting bots, crawlers, scanners and other surface malicious activity.
  • Integration with AV Scanning for File Uploads - detects malicious files uploaded through the web application.
  • Tracking Sensitive Data - Tracks Credit Card usage and blocks leakages.
  • Trojan Protection - Detecting access to Trojans horses.
  • Identification of Application Defects - alerts on application misconfigurations.
  • Error Detection and Hiding - Disguising error messages sent by the server.
ModSecurity Logo 2011.JPG
SpiderLabs Logo 2011.JPG

Let's talk here

Asvs-bulb.jpgModSecurity Communities

Further development of ModSecurity and the Core Rule Set occurs through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. For more information, please contact us.

Want to help?

Asvs-waiting.JPGCRS Development

The CRS project is always on the lookout for volunteers who are interested in contributing. We need help in the following areas:

  • Documentation of the CRS
  • New Detection Methods
  • Updates to existing rules

Related resources

Asvs-satellite.jpgOWASP Resources


SVN Repository is here:

http://mod-security.svn.sourceforge.net/viewvc/mod-security/crs/

Sync with SVN:

svn co https://mod-security.svn.sourceforge.net/svnroot/mod-security/crs/trunk crs

CRS Releases are signed by Ryan Barnett. These public keys are available via most PGP key server mirrors.

http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xC976607D9624FCD2

Manual Downloading: You can always download the latest CRS version here - https://sourceforge.net/projects/mod-security/files/modsecurity-crs/0-CURRENT/

Automated Downloading: Use the rules-updater.pl script in the CRS /util directory

  1. Get a list of what the repository contains:
$ ./rules-updater.pl -rhttp://www.modsecurity.org/autoupdate/repository/ -l
Repository: http://www.modsecurity.org/autoupdate/repository
modsecurity-crs {
         2.0.0: modsecurity-crs_2.0.0.zip
         2.0.1: modsecurity-crs_2.0.1.zip
         2.0.2: modsecurity-crs_2.0.2.zip
         2.0.3: modsecurity-crs_2.0.3.zip
         2.0.4: modsecurity-crs_2.0.4.zip
         2.0.5: modsecurity-crs_2.0.5.zip
         2.0.6: modsecurity-crs_2.0.6.zip
         2.0.7: modsecurity-crs_2.0.7.zip
         2.0.8: modsecurity-crs_2.0.8.zip
         2.0.9: modsecurity-crs_2.0.9.zip
         2.1.0: modsecurity-crs_2.1.0.zip
}
  1. Get the latest stable version of "modsecurity-crs":
$ ./rules-updater.pl -rhttp://www.modsecurity.org/autoupdate/repository/ -prules -Smodsecurity-crs
Fetching: modsecurity-crs/modsecurity-crs_2.1.0.zip ...
$ ls -R rules
modsecurity-crs

rules/modsecurity-crs:
modsecurity-crs_2.1.0.zip    modsecurity-crs_2.1.0.zip.sig

ModSecurity CRS Demonstration/Smoketest page:

http://www.modsecurity.org/demo/

Project Leader

Ryan Barnett

Project Contributors

Josh Zlatin
Brian Rectanus
Roberto Salgado

Project Users

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

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

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


Quick Start

Core Rule Set Quick Setup

To activate the rules for your web server installation:

 1) The modsecurity_crs_10_config.conf includes management rules and directives
    that can control important CRS functions. Pay attention to
    the SecRuleEngine setting (On by default) and that the SecDefaultAction
    directive is set to "pass".  The 49 inbound blocking and 59 outbound blocking
    rules files use the "block" action which
    inherits this setting.  The effectively means that you can toggle the
    SecDefaultAction setting to decide if you would like to deny on an
    anomaly scoring/correlation match.
    Update the PARANOID_MODE variable setting if you want to become more 
    aggressive in your detection.  Caution - this will cause more false positives.
    Should also update the appropriate anomaly scoring levels that will be propagated
    to the inbound/outbound blocking files.
    Update the TX policy settings for allowed Request Methods, File Extensions, etc...
 2) Add the following line to your httpd.conf (assuming
    you've placed the rule files into conf/modsecurity_crs/):
       <IfModule security2_module>
               Include conf/modsecurity_crs/*.conf
               Include conf/modsecurity_crs/base_rules/*.conf
       </IfModule>
 3) Restart web server.
 4) Make sure your web sites are still running fine.
 5) Simulate an attack against the web server. Then check
    the attack was correctly logged in the Apache error log,
    ModSecurity debug log (if you enabled it) and ModSecurity
    audit log (if you enabled it).


ModSecurity Blog Posts

http://blog.spiderlabs.com/modsecurity/

  • ModSecurity Advanced Topic of the Week: Traditional vs. Anomaly Scoring Detection Modes

http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html

  • ModSecurity Advanced Topic of the Week: Exception Handling

http://blog.spiderlabs.com/2011/08/modsecurity-advanced-topic-of-the-week-exception-handling.html

Rule Documentation Template

Each ModSecurity Rule in the CRS has an individual rule description page based on the following template file:

http://www.owasp.org/index.php/ModSecurity_CRS_Rule_Description_Template

Example:

http://www.owasp.org/index.php/ModSecurity_CRS_RuleID-960911

ModSecurity Core Rule Set (CRS)

The ModSecurity Core Rule Set is provided to you under the terms and conditions of GPL version 2

This directory contains the files for Core ModSecurity Rule Set The rules are compatible with ModSecurity 2.5 (as of version 1.4.3)

Overview

Using ModSecurity requires rules. In order to enable users to take full advantage of ModSecurity immediately, Trustwave is providing a free Core rule set. Unlike intrusion detection and prevention systems which rely on signature specific to known vulnerabilities, the Core Rule Set provides generic protection from unknown vulnerabilities often found in web application that are in most cases custom coded. This is what we call "Attack Payload Detection."

Keep in mind that a predefined rule set is only part of the work required to protect your web site. We strongly urge you to consult Ivan Ristic's book, "ModSecurity Handbook" http://store.feistyduck.com/products/modsecurity-handbook and the ModSecurity Reference Manual - http://www.modsecurity.org/documentation/. The CRS is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity.

For more information refer to the OWASP Core Rule Set Project page at http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Core Rules Mail-list - Suscribe here: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set Archive: https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/

CRS 2.0 Design Concepts

CRS < 2.0 - Self-Contained Rules

Older (<2.0) CRS used individual, “self-contained” actions in rules

- If a rule triggered, it would either deny or pass and log
- No intelligence was shared between rules

Not optimal from a rules management perspective (handling false positives/exceptions)

- Editing the regex could blow it up
- Typical method was to copy/paste rules into custom rules files and then edit rule logic
  and disable core rule ID.
- Heavily customized rules were less likely to be updated by the user

Not optimal from a security perspective

- Not every site had the same risk tolerance
- Lower severity alerts were largely ignored
- Individual low severity alerts are not important but several low severity events
  in the same transaction are.

CRS 2.0 - Collaborative Detection

Rules - Detection and Management

Rules logic has changed by decoupling the inspection/detection from the blocking functionality

- Rules log.pass and set transactional variables (tx) to track anomaly scores and to 
  store meta-data about the rule match
- This TX rule match data can be used by other 3rd party rules (converter Emerging Threats
  Snort web attack rules) to more accurately correlate identified attacks with their
  attack vector locations.
- TX data of previous strong rule matches can also be used to conditionally apply weaker signatures
  that normally would have a high fasle positive rate.
- Rules also increase anomaly scores for both the attack category and global score which allows
  users to set a threshold that is appropriate for them.
- This also allows several low severity events to trigger alerts while individual ones are suppressed.
- Exceptions may be handled by either increasing the overall anomaly score threshold, or
  by adding rules to a local custom exceptions file where TX data of previous rule matches
  may be inspected and anomaly scores re-adjusted based on the false positive criteria.

User can now globally update which variables to inspect and the anomaly score settings in the modsecurity_crs_10_config.conf file.

- PARANOID_MODE setting which will apply rules to locations that have a higher false positive rate
- INBOUND_ANOMALY_SCORE setting will be populated in the inbound blocking file and if a transaction
  score at the end of phase:2 is equal to or greater than this number, it will be denied.
- OUTBOUND_ANOMALY_SCORE setting will be populated in the outbound blocking file and it a transaction
  score at the end of phase:4 is equal to or greater than this number, it will be denied.

Inbound/Outbound Blocking

The CRS rules themselves are configured with the pass action, which allows all the rules to be processed and for the proposed anomaly scoring/collaborative detection concept to work. The inbound/outbound anomaly score levels may be set in the modsecurity_crs_10_config.conf file. These scores will be evaluated in the modsecurity_crs_49_inbound_blocking.conf and modsecurity_crs_59_outbound_blocking.conf files.

Alert Management - Correlated Event Creation

One of the top feedback items we have heard is that the CRS events in the Apache error_log file were very chatty. This was due to each rule triggering its own error_log entry. What most people wanted was for 1 correlated event to be generated that would give the user a higher level determination as to what the event category was.

To that end- each CRS rule will generate an audit log event Message entry but they will not log to the error_log on their own. These rules are now considered basic or reference events and may be reviewed in the audit log if the user wants to see what individual events contributed to the overall anomaly score and event designation.

Inbound/Outbound Correlation

After the transaction has completed (in the logging phase), the rules in the base_rules/modsecurity_crs_60_correlation.conf file will conduct further post-processing by analyzing any inbound events with any outbound events in order to provide a more intelligent/priority correlated event.

- Was there an inbound attack?
- Was there an HTTP Status Code Error (4xx/5xx level)?
- Was there an application information leak?

If an inbound attack was detected and either an outbound application status code error or infolead was detected, then the overall event severity is raised -

- 0: Emergency - is generated from correlation where there is an inbound attack and
  an outbound leakage.
- 1: Alert - is generated from correlation where there is an inbound attack and an
  outbound application level error.

Core Rule Set Content

In order to provide generic web applications protection, the Core Rule Set uses the following techniques:

HTTP Protocol Validation and Protection

Detecting violations of the HTTP protocol and a locally defined usage policy. This first line of protection ensures that all abnormal HTTP requests are detected. This line of defense eliminates a large number of automated and non targeted attacks as well as protects the web server itself.

base_rules/modsecurity_crs_20_protocol_violations.conf

Protocol vulnerabilities such as Response Splitting, Request Smuggling, Premature URL ending

- Content length only for non GET/HEAD methods 
- Non ASCII characters or encoding in headers
- Valid use of headers (for example, content length is numerical)
- Proxy Access

base_rules/modsecurity_crs_21_protocol_anomalies.conf

Attack requests are different due to automation

- Missing headers such as Host, Accept, User-Agent
- Host is an IP address (common worm propagation method)

base_rules/modsecurity_crs_23_request_limits.conf

Policy is usually application specific

- Some restrictions can usually be applied generically
- White lists can be build for specific environments
  Limitations on Sizes
- Request size, Upload size
- # of parameters, length of parameter

base_rules/modsecurity_crs_30_http_policy.conf

Items that can be allowed or restricted

- Methods - Allow or restrict WebDAV, block abused methods such as CONNECT, TRACE or DEBUG 
- File extensions – backup files, database files, ini files
- Content-Types (and to some extent other headers)

Automation Detection

Automated clients are both a security risk and a commercial risk. Automated crawlers collect information from your site, consume bandwidth and might also search for vulnerabilities on the web site. Automation detection is especially useful for generic detection of comments spam.

Detecting bots, crawlers, scanners and other surface malicious activity. Not aimed against targeted attacks, but against general malicious internet activity

- Offloads a lot of cyberspace junk & noise
- Effective against comment spam
- Reduce event count

base_rules/modsecurity_crs_35_bad_robots.conf

Detection of Malicious Robots

- Unique request attributes: User-Agent header, URL, Headers
- RBL Check of IP addresses
- Detection of security scanners
- Blocking can confuse security testing software (WAFW00f)

optional_rules/modsecurity_crs_42_comment_spam.conf

This rules file is only relevant if you are concerned about comment SPAM attacks. The rules file will run an RBL check against the source IP address at SPAMHAUS and will cache the response for 1 day. If the client sends subsequent requests, it will be denied without having to re-run an RBL check.

This file will also look for comment SPAM posting attacks which submit URL links.

Common Web Attacks Protection

Common Web Attacks Protection Rules on the second level address the common web application security attack methods. These are the issues that can appear in any web application. Some of the issues addressed are:

- SQL Injection
- Cross-Site Scripting (XSS)
- OS Command execution
- Remote code inclusion
- LDAP Injection
- SSI Injection
- Information leak
- Buffer overflows
- File disclosure

base_rules/modsecurity_crs_40_generic_attacks.conf

- OS command injection and remote command access
- Remote file inclusion
- Session Fixation

optional_rules/modsecurity_crs_40_experimental.conf

The rules in this file are considered BETA quality as they have not been rigorously tested. They attempt to address advanced attacks such as HTTP Parameter Pollution or use new rule features or techniques.

base_rules/modsecurity_crs_42_tight_security.conf

This rules file attempts to identify all directory traversal variations. It is prone to a high level of false positives so set PARANOID_MODE if you want to run these rules.

base_rules/modsecurity_crs_41_sql_injection.conf

- SQL injection and blind SQL injection

base_rules/modsecurity_crs_41_xss.conf

- Cross site scripting (XSS)

Trojan Protection

ModSecurity Core Rule Set detects access to back doors installed on a web server. This feature is very important in a hosting environment when some of this backdoors may be uploaded in a legitimate way and used maliciously. In addition the Core Rule Set includes a hook for adding an Anti-Virus program such as ClamAV for checking file uploads.

base_rules/modsecurity_crs_45_trojans.conf

- Check uploading of http backdoor page
- Access detection
- Known signatures (x_key header)
- Generic file management output (gid, uid, drwx, c:\)

InfoLeakages

If all fails, the Core Rule Set will detect errors sent by the web server. Detecting and blocking errors prevents attackers from collecting reconnaissance information about the web application and also server as a last line of defense in case an attack was not detected eariler.

base_rules/modsecurity_crs_50_outbound.conf

- HTTP Error Response Status Codes
- SQL Information Leakage
- Stack Dumps
- Source Code Leakage

Request Header Tagging

This concept is similar to anti-SPAM SMTP apps that will add additional mime headers to emails providing the SPAM detection analysis information. The CRS is attempting to mimic this concept at the HTTP layer by adding additional request headers that provide insight into any ModSecurity events that may have triggered during processing. The advantage of this approach is that it allows a WAF to be in a detection-only mode while still providing attack data to the destination application server. The recieving app server may then inspect the WAF request headers and make a determination whether or not to process the transaction. This concept is valuable in distributed web environments and hosting architectures where a determination to block may only be appropriate at the destination app server.

optional_rules/modsecurity_crs_49_header_tagging.conf

This rules file will take all of the TX attack variable data and populate Apache ENV variables that Apache can then use to add X-WAF-Event request header data to the request.

Example showing the consolidated X-WAF-Events and X-WAF-Score data -

GET /path/to/foo.php?test=1%27%20or%20%272%27=%272%27;-- HTTP/1.1
Host: www.example.com 
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091109 Ubuntu/9.10 (karmic) Firefox/3.5.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
X-WAF-Events: TX: / 999935-Detects common comment types-WEB_ATTACK/INJECTION-ARGS:test, TX:999923-Detects JavaScript location/document property access and window access obfuscation-WEB_ATTACK/INJECTION-REQUEST_URI_RAW, TX:950001- WEB_ATTACK/SQL_INJECTION-ARGS:test
X-WAF-Score: Total=48; sqli=2; xss=
Connection: Keep-Alive

Current CRS v2 File:OWASP ModSecurity Core Rule Set.ppt presented at AppSec DC 2009.

Ofer Shezaf's presentation and whitepaper on the Core Rule Set v1 presented at 6th OWASP AppSec conference in Milan, Italy, in May 2007

Current Stable Version CRS 2.1.2


Version 2.1.2 - 02/17/2011


Improvements:
- Added experimental real-time application profiling ruleset.
- Added experimental Lua script for profiling the # of page scripts, iframes, etc..
  which will help to identify successful XSS attacks and planting of malware links.
- Added new CSRF detection rule which will trigger if a subsequent request comes too
  quickly (need to use the Ignore Static Content rules).
Bug Fixes:
- Added missing " in the skipAfter SecAction in the CC Detection rule set

Version 2.1.0 - 12/29/2010


Improvements:

- Added Experimental Lua Converter script to normalize payloads. Based on
  PHPIDS Converter code and it used with the advanced filters conf file. 
- Changed the name of PHPIDS converted rules to Advanced Filters
- Added Ignore Static Content (Performance enhancement) rule set
- Added XML Enabler (Web Services) rule set which will parse XML data
- Added Authorized Vulnerability Scanning (AVS) Whitelist rule set 
- Added Denial of Service (DoS) Protection rule set
- Added Slow HTTP DoS (Connection Consumption) Protection rule set
- Added Brute Force Attack Protection rule set
- Added Session Hijacking Detection rule set
- Added Username Tracking rule set
- Added Authentication Tracking rule set
- Added Anti-Virus Scanning of File Attachments rule set
- Added AV Scanning program to /util directory
- Added Credit Card Usage Tracking/Leakage Prevention rule set
- Added experimental CC Track/PAN Leakage Prevention rule set
- Added an experimental_rules directory to hold new BETA rules
- Moved the local exceptions conf file back into base_rules dirctory however
  it has a ".example" extension to prevent overwriting customized versions
  when upgrading
- Separated out HTTP Parameter Pollution and Restricted Character Anomaly Detection rules to
  the experimental_rules directory
- Adding the REQUEST_HEADERS:User-Agent macro data to the initcol in 10 config file, which will
  help to make collections a bit more unique

Version 2.0.8 - 08/27/2010


Improvements:

- Updated the PHPIDS filters
- Updated the SQL Injection filters to detect boolean attacks (1<2, foo == bar, etc..)
- Updated the SQL Injection filters to account for different quotes
- Added UTF-8 encoding validation support to the modsecurity_crs_10_config.conf file
- Added Rule ID 950109 to detect multiple URL encodings
- Added two experimental rules to detect anomalous use of special characters

Bug Fixes:

- Fixed Encoding Detection RegEx (950107 and 950108)
- Fixed rules-updater.pl script to better handle whitespace
  https://www.modsecurity.org/tracker/browse/MODSEC-167
- Fixed missing pass action bug in modsecurity_crs_21_protocol_anomalies.conf
  https://www.modsecurity.org/tracker/browse/CORERULES-55
- Fixed the anomaly scoring in the modsecurity_crs_41_phpids_filters.conf file
  https://www.modsecurity.org/tracker/browse/CORERULES-54
- Updated XSS rule id 958001 to improve the .cookie regex to reduce false postives
  https://www.modsecurity.org/tracker/browse/CORERULES-29  

Version 2.0.7 - 06/4/2010


Improvements:

- Added CSRF Protection Ruleset which will use Content Injection to add javascript to
  specific outbound data and then validate the csrf token on subsequent requests.
- Added new Application Defect Ruleset which will identify/fix missing HTTPOnly cookie
  flags
- Added Experimental XSS/Missing Output Escaping Ruleset which looks for user supplied
  data being echoed back to user unchanged.
- Added rules-updater.pl script and configuration file to allow users to automatically
  download CRS rules from the CRS rules repository. 
- Added new SQLi keyword for ciel() and reverse() functions.
- Updated the PHPIDS filters

Bug Fixes:

- Fixed false positives for Request Header Name matching in the 30 file by 
  adding boundary characters.  
- Added missing pass actions to @pmFromFile prequalifier rules
- Added backslash to SQLi regex
  https://www.modsecurity.org/tracker/browse/CORERULES-41
- Fixed hard coded anomaly score in PHPIDS filter file
  https://www.modsecurity.org/tracker/browse/CORERULES-45 
- Fixed restricted_extension false positive by adding boundary characters 

Version 2.0.6 - 02/26/2010


Bug Fixes:

- Added missing transformation functions to SQLi rules.
  https://www.modsecurity.org/tracker/browse/CORERULES-32
- Fixed duplicate rule IDs.
  https://www.modsecurity.org/tracker/browse/CORERULES-33
- Fixed typo in @pmFromFile in the Comment SPAM rules
  https://www.modsecurity.org/tracker/browse/CORERULES-34
- Added macro expansion to Restricted Headers rule
  https://www.modsecurity.org/tracker/browse/CORERULES-35
- Fixed misspelled SecMarker
  https://www.modsecurity.org/tracker/browse/CORERULES-36
- Fixed missing chain action in Content-Type header check
  https://www.modsecurity.org/tracker/browse/CORERULES-37
- Update phpids filters to use pass action instead of block



Version 2.0.5 - 02/01/2010


Improvements:

- Removed previous 10 config files as they may conflict with local customized Mod configs.
- Added a new 10 config file that allows the user to globally set TX variables to turn on/off
  PARANOID_MODE inspection, set anomaly score levels and http policies.
  Must have ModSecurity 2.5.12 to use the macro expansion in numeric operators.
- Added Rule Logic and Reference links to rules descriptions.
- Added Rule IDs to all rules.
- Added tag data mapping to new OWASP Top 10 and AppSensor Projects, WASC Threat Classification
- Removed Apache limit directives from the 23 file
- Added macro expansion to 23 file checks.
- Added @pmFromFile check to 35 bad robots file
- Added malicious UA strings to 35 bad robots check
- Created an experimental rules file
- Updated HTTP Parameter Pollution (HPP) rule logic to concat data into a TX variable for inspection
- Removed TX inspections for generic attacks and reverted to standard ARGS inspection
  https://www.modsecurity.org/tracker/browse/MODSEC-120
- Updated the variable list for standard inspections (ARGS|ARGS_NAMES|XML:/*) and moved the other
  variables to the PARANOID list (REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS|TX:HPP_DATA)
- Moved converted ET Snort rules to the /optional_rules directory
- Created a new Header Tagging ruleset (optional_rules) that will add matched rule data to the
  request headers.
- Updated Inbound blocking conf file to use macro expansion from the 10 config file settings
- Added separate anomaly scores for inbound, outbound and total to be evaluated for blocking.
- Updated the regex logic in the (1=1) rule to factor in quotes and other logical operators.
- Updated the SPAMMER RBL check rules logic to only check once per IP/Day.
- Added new outbound malware link detection rules.

Bug Fixes:

- Removed Non-numeric Rule IDs
  https://www.modsecurity.org/tracker/browse/CORERULES-28
- Updated the variable list on SQLi rules.
- Fixed outbound @pmFromFile action from allow to skipAfter to allow for outbound anomaly scoring
  and blocking

Version 2.0.4 - 11/30/2009


Improvements:

- Updated converted PHPIDS signatures (https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xml)
- Updated PHPIDS rules logic to first search for payloads in ARGS and then if there is no match found
  then search more generically in request_body|request_uri_raw
- Updated PHPIDS rules logic to only set TX variables and to not log.  This allows for more clean
  exceptions in the 48 file which can then expire/delete false positive TX matches and adjust the
  anomaly scores.  These rules will then inspect for any TX variables in phase:5 and create appropriate
  alerts for any variable matches that exist.

Bug Fixes:

- Added Anomaly Score check to the 60 correlation file to recheck the anomaly score at the end of
  phase:4 which would allow for blocking based on information leakage issues.

v3.0

This page documents the goals/ideas for the next major version of the CRS.

Goals

These are not listed in any particular order.

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

Detection Logic/Flow Concepts

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

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


Project About

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP ModSecurity Core Rule Set Project (home page)
Purpose: ModSecurity is an Apache web server module that provides a web application firewall engine. The ModSecurity Rules Language engine is extrememly flexible and robust and has been referred to as the "Swiss Army Knife of web application firewalls." While this is certainly true, it doesn't do much implicitly on its own and requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, we have developed the Core Rule Set (CRS) which provides critical protections against attacks across most every web architecture.

Unlike intrusion detection and prevention systems, which rely on signatures specific to known vulnerabilities, the CRS is based on generic rules which focus on attack payload identification in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded.

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

- Changed Licensing from GPLv2 to Apache Software License v2 (ASLv2) http://www.apache.org/licenses/LICENSE-2.0.txt - Created new INSTALL file outlining quick config setup - Added a new rule regression testing framework to the /util directory - Added new activated_rules directory which will allow users to place symlinks pointing to files they want to run. This allows for easier Apache Include wild-carding - Adding in new RULE_MATURITY and RULE_ACCURACY tags - Adding in a check for X-Forwarded-For source IP when creating IP collection - Added new Application Defect checks (55 app defect file) from Watcher tool (Check Charset) http://websecuritytool.codeplex.com/wikipage?title=Checks#charset - Added new AppSensor rules to experimental_dir https://www.owasp.org/index.php/AppSensor_DetectionPoints - Added new Generic Malicious JS checks in outbound content - Added experimental IP Forensic rules to gather Client hostname/whois info http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html - Added support for Mozilla's Content Security Policy (CSP) to the experimental_rules http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html - Global collection in the 10 file now uses the Host Request Header as the collection key. This allows for per-site global collections. - Added new SpiderLabs Research (SLR) rules directory (slr_rules) for known vulnerabilties. This includes both converted web rules from Emerging Threats (ET) and from SLR Team. - Added new SLR rule packs for known application vulns for WordPress, Joomla and phpBB - Added experimental rules for detecting Open Proxy Abuse http://blog.spiderlabs.com/2011/03/detecting-malice-with-modsecurity-open-proxy-abuse.html - Added experimental Passive Vulnerability Scanning ruleset using OSVDB and Lua API http://blog.spiderlabs.com/2011/02/modsecurity-advanced-topic-of-the-week-passive-vulnerability-scanning-part-1-osvdb-checks.html - Added additional URI Request Validation rule to the 20 protocol violations file (Rule ID - 981227) - Added new SQLi detection rules (959070, 959071 and 959072) - Added "Toata dragostea mea pentru diavola" to the malicious User-Agent data https://www.modsecurity.org/tracker/browse/CORERULES-64

  • Bug Fixes:

- Assigned IDs to all active SecRules/SecActions - Removed rule inversion (!) from rule ID 960902 - Fixed false negative issue in Response Splitting Rule - Fixed false negative issue with @validateByteRange check - Updated the TARGETS lising for rule ID 950908 - Updated TX data for REQBODY processing - Changed the pass action to block in the RFI rules in the 40 generic file - Updated RFI regex to catch IP address usage in hostname https://www.modsecurity.org/tracker/browse/CORERULES-68 - Changed REQUEST_URI_RAW variable to REQUEST_LINE in SLR rules to allow matches on request methods. - Updated the RFI rules in the 40 generic attacks conf file to remove explicit logging actions. They will now inherit the settings from the SecDefaultAction

Rating: Yellow button.JPG Not Reviewed - Assessment Details
last reviewed release
ModSecurity 2.0.6 - 2010-02-26 - (download)
Release description: ModSecurity is a web application firewall that can work either embedded or as a reverse proxy. It provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
Rating: Greenlight.pngGreenlight.pngGreenlight.png Stable Release - Assessment Details


other releases


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

Pages in category "OWASP ModSecurity Core Rule Set Project"

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