2 ==============================
3 ModSecurity Core Rule Set
4 ==============================
6 (c) 2006-2009 Breach Secuiry Inc.
8 The ModSecurity Core Rule Set is provided to you under the terms and
9 conditions of GPL version 2
11 This directory contains the files for Core ModSecurity Rule Set
12 The rules are compatible with ModSecurity 2.5 (as of version 1.4.3)
18 Using ModSecurity requires rules. In order to enable users to take full
19 advantage of ModSecurity immediately, Breach Security Inc. is providing a free
20 Core rule set. Unlike intrusion detection and prevention systems which
21 rely on signature specific to known vulnerabilities, the Core Rule Set
22 provides generic protection from unknown vulnerabilities often found in web
23 application that are in most cases custom coded.
25 Keep in mind that a predefined rule set is only part of the work required to
26 protect your web site. We strongly urge you to consult Ivan Ristic's book,
27 "Apache Security" in order to harden your Apache web server. You may also
28 consider writing custom rules for providing a positive security envelope to
29 your application or critical parts of it. Breach Security can provide you with
30 training and professional services to assist you in doing that. The Core
31 Rule Set is heavily commented to allow it to be used as a step-by-step
32 deployment guide for ModSecurity.
34 For more information refer to the Core Rule Set page at
35 http://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
37 Core Rules Mail-list -
38 Suscribe here: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
39 Archive: https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/
41 Core Rule Set Structure & Usage
42 ====================================
44 To activate the rules for your web server installation:
46 1) The modsecurity_crs_10_global_config.conf file includes directives that
47 can only be initiated once by Apache and thus this should be included
48 within the main httpd.conf file context.
50 The modsecurity_crs_10_config.conf, on the other hand, includes directives
51 that can be included within virtual host containers. Pay attention to
52 the SecRuleEngine setting (On by default) and that the SecDefaultAction
53 directive is set to "pass". All of the rules use the "block" action which
54 inherits this setting. The effectively means that you can toggle the
55 SecDefaultAction setting to decide if you would like to deny on a rule
56 match or if you want to run in anomaly scoring/correlation mode (which is
59 Should also update the appropriate anomaly scoring level in the
60 modsecurity_crs_49_enforcement.conf and modsecurity_crs_60_correlation.conf
61 files. This will determine when you log and block events.
63 Additionally you may want to edit modsecurity_crs_30_http_policy.conf
64 which enforces an application specific HTTP protocol usage.
66 2) Add the following line to your httpd.conf (assuming
67 you've placed the rule files into conf/modsecurity/):
69 Include conf/modsecurity/*.conf
70 Include conf/modsecurity/base_rules/*conf
72 3) Restart web server.
74 4) Make sure your web sites are still running fine.
76 5) Simulate an attack against the web server. Then check
77 the attack was correctly logged in the Apache error log,
78 ModSecurity debug log (if you enabled it) and ModSecurity
79 audit log (if you enabled it).
81 6) If you configured your audit log entries to be transported
82 to ModSecurity Console in real time, check the alert was
83 correctly recorded there too.
89 Apache requests rejection and phase 2 rules
90 -------------------------------------------
92 Since now all inspection rules are executed in phase 2, several protocol
93 validation is done by Apache prior to ModSecurity. This is by no means a
94 security issue as Apache would block the requests, but the alert would appear
95 in the ModSecurity audit log as a generic event "Invalid Request (960913)"
97 Here's a list of the events that modsecurity might not log due to this issue:
98 - Validate encoding - 950107
99 When invalid encoding is found in the URI
100 - Validate utf-8 encoding - 950801
101 When invalid encoding is found in the URI
102 - Method not allowed by policy - 960032
103 When the request uses a method that Apache doesn't know such as: CONNECT, SUBSCRIBE, etc.
109 For Google Analytics account activation, you will need to disable
110 the Core Rules temporarily, then enable them after your Google account is
111 activated. More info can be found in the mod-security-mailing-list:
112 http://sourceforge.net/mailarchive/message.php?msg_name=1179692394.26994.10.camel%40localhost
115 About Regular Expressions
116 ============================
118 One of the advantages of the Core Rule Set, being a set of text files is your
119 ability to modify it. However you will find that the regular expressions used
122 Since regular expressions are much more efficient if assembled into a single
123 expression and optimized, a generation script takes a list of patterns that
124 are required for a rule and optimize them into a most efficient regular
127 We plan to release the optimization script shortly to allow much easier editing
128 of regular expressions.
131 Core Rule Set Content
132 =========================
134 In order to provide generic web applications protection, the Core Rule Set
135 uses the following techniques:
137 1. HTTP protection - detecting violations of the HTTP protocol and a locally
138 defined usage policy.
140 2. Common Web Attacks Protection - detecting common web application security
143 3. Automation detection - Detecting bots, crawlers, scanners and other surface
146 4. Trojan Protection - Detecting access to Trojans horses.
148 5. Errors Hiding - Disguising error messages sent by the server
150 In addition the rule set also hints at the power of ModSecurity beyond
151 providing security by reporting access from the major search engines to your
155 HTTP Protection - This first line of protection ensures that all abnormal HTTP
156 requests are detected. This line of defense eliminates a large number of
157 automated and non targeted attacks as well as protects the web server itself.
158 Common Web Attacks Protection Rules on the second level address the common web
159 application security attack methods. These are the issues that can appear in
160 any web application. Some of the issues addressed are:
163 - Cross-Site Scripting (XSS)
164 - OS Command execution
165 - Remote code inclusion
172 Automation Detection - Automated clients are both a security risk and a
173 commercial risk. Automated crawlers collect information from your site, consume
174 bandwidth and might also search for vulnerabilities on the web site. Automation
175 detection is especially useful for generic detection of comments spam.
178 Trojan Protection - ModSecurity Core Rule Set detects access to back doors
179 installed on a web server. This feature is very important in a hosting
180 environment when some of this backdoors may be uploaded in a legitimate way and
181 used maliciously. In addition the Core Rule Set includes a hook for adding
182 an Anti-Virus program such as ClamAV for checking file uploads.
184 Errors Hiding - If all fails, the Core Rule Set will detect errors sent by
185 the web server. Detecting and blocking errors prevents attackers from
186 collecting reconnaissance information about the web application and also server
187 as a last line of defense in case an attack was not detected eariler.
193 As with every new technology, using the ModSecurity Core Rule Set requires some caution:
195 - Every Rule Set can have false positive in new environments and any new
196 installation should initially use the log only Rule Set version or if no such
197 version is available, set ModSecurity to Detection only using the SecRuleEngine
198 DetectionOnly command.
200 After running ModSecurity in a detection only mode for a while review the evens
201 generated and decide if any modification to the rule set should be made before
202 moving to protection mode.
204 - Freely available wide spread signatures have their down side as attackers may
205 examine them and find ways to bypass them. Especially note that the automation
206 detection signatures are relatively easy to evade and should not be viewed as a
207 security mechanism but only as a "nuisance reduction" mechanism.
213 This rule set is both young and old. Breach Security has a long experience with
214 rules and signatures for application security protection and the Core Rule
215 Set is based on this experience. On the other hand, this is a first cut of a
216 ModSecurity rule set so your feedback and remarks, either directly or through
217 the ModSecurity mailing list would be greatly appreciated.
219 Going forward we plan to:
221 - Utilize ModSecurity 2.0 support for events correlation to detect denial of
222 service attacks, brute force attacks and attack reconnaissance
224 - Add a framework for validating SOAP requests.
226 - Add signatures for key known vulnerabilities.
228 Anything else you would want?