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:
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) 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™ 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.
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
- 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
}
- 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
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).
No comments:
Post a Comment