============================== ModSecurity Core Rule Set ============================== (c) 2006-2009 Breach Secuiry Inc. 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, Breach Security Inc. 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. 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, "Apache Security" in order to harden your Apache web server. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. Breach Security can provide you with training and professional services to assist you in doing that. The Core Rule Set is heavily commented to allow it to be used as a step-by-step deployment guide for ModSecurity. For more information refer to the Core Rule Set 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/ Core Rule Set Structure & Usage ==================================== To activate the rules for your web server installation: 1) The modsecurity_crs_10_global_config.conf file includes directives that can only be initiated once by Apache and thus this should be included within the main httpd.conf file context. The modsecurity_crs_10_config.conf, on the other hand, includes directives that can be included within virtual host containers. Pay attention to the SecRuleEngine setting (On by default) and that the SecDefaultAction directive is set to "pass". All of the rules 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 a rule match or if you want to run in anomaly scoring/correlation mode (which is the new default). Should also update the appropriate anomaly scoring level in the modsecurity_crs_49_enforcement.conf and modsecurity_crs_60_correlation.conf files. This will determine when you log and block events. Additionally you may want to edit modsecurity_crs_30_http_policy.conf which enforces an application specific HTTP protocol usage. 2) Add the following line to your httpd.conf (assuming you've placed the rule files into conf/modsecurity/): Include conf/modsecurity/*.conf Include conf/modsecurity/base_rules/*conf 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). 6) If you configured your audit log entries to be transported to ModSecurity Console in real time, check the alert was correctly recorded there too. Known Issues =============== Apache requests rejection and phase 2 rules ------------------------------------------- Since now all inspection rules are executed in phase 2, several protocol validation is done by Apache prior to ModSecurity. This is by no means a security issue as Apache would block the requests, but the alert would appear in the ModSecurity audit log as a generic event "Invalid Request (960913)" Here's a list of the events that modsecurity might not log due to this issue: - Validate encoding - 950107 When invalid encoding is found in the URI - Validate utf-8 encoding - 950801 When invalid encoding is found in the URI - Method not allowed by policy - 960032 When the request uses a method that Apache doesn't know such as: CONNECT, SUBSCRIBE, etc. Google Analytics ---------------- For Google Analytics account activation, you will need to disable the Core Rules temporarily, then enable them after your Google account is activated. More info can be found in the mod-security-mailing-list: http://sourceforge.net/mailarchive/message.php?msg_name=1179692394.26994.10.camel%40localhost About Regular Expressions ============================ One of the advantages of the Core Rule Set, being a set of text files is your ability to modify it. However you will find that the regular expressions used are very complex. Since regular expressions are much more efficient if assembled into a single expression and optimized, a generation script takes a list of patterns that are required for a rule and optimize them into a most efficient regular expression. We plan to release the optimization script shortly to allow much easier editing of regular expressions. Core Rule Set Content ========================= In order to provide generic web applications protection, the Core Rule Set uses the following techniques: 1. HTTP protection - detecting violations of the HTTP protocol and a locally defined usage policy. 2. Common Web Attacks Protection - detecting common web application security attack. 3. Automation detection - Detecting bots, crawlers, scanners and other surface malicious activity. 4. Trojan Protection - Detecting access to Trojans horses. 5. Errors Hiding - Disguising error messages sent by the server In addition the rule set also hints at the power of ModSecurity beyond providing security by reporting access from the major search engines to your site. HTTP Protection - 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. 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 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. 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. Errors Hiding - 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. Few Word of Caution ------------------- As with every new technology, using the ModSecurity Core Rule Set requires some caution: - Every Rule Set can have false positive in new environments and any new installation should initially use the log only Rule Set version or if no such version is available, set ModSecurity to Detection only using the SecRuleEngine DetectionOnly command. After running ModSecurity in a detection only mode for a while review the evens generated and decide if any modification to the rule set should be made before moving to protection mode. - Freely available wide spread signatures have their down side as attackers may examine them and find ways to bypass them. Especially note that the automation detection signatures are relatively easy to evade and should not be viewed as a security mechanism but only as a "nuisance reduction" mechanism. Road Map -------- This rule set is both young and old. Breach Security has a long experience with rules and signatures for application security protection and the Core Rule Set is based on this experience. On the other hand, this is a first cut of a ModSecurity rule set so your feedback and remarks, either directly or through the ModSecurity mailing list would be greatly appreciated. Going forward we plan to: - Utilize ModSecurity 2.0 support for events correlation to detect denial of service attacks, brute force attacks and attack reconnaissance - Add a framework for validating SOAP requests. - Add signatures for key known vulnerabilities. Anything else you would want?