rules/README

   1
   2 ==============================
   3 ModSecurity Core Rule Set
   4 ==============================
   5
   6 (c) 2006-2009 Breach Secuiry Inc.
   7
   8 The ModSecurity Core Rule Set is provided to you under the terms and
   9 conditions of GPL version 2
  10
  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)
  13
  14
  15 Overview
  16 ========
  17
  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.
  24
  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.
  33
  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
  36
  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/
  40
  41 Core Rule Set Structure & Usage
  42 ====================================
  43
  44 To activate the rules for your web server installation:
  45
  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.
  49
  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
  57      the new default).
  58
  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.
  62
  63      Additionally you may want to edit modsecurity_crs_30_http_policy.conf
  64      which enforces an application specific HTTP protocol usage.
  65
  66   2) Add the following line to your httpd.conf (assuming
  67      you've placed the rule files into conf/modsecurity/):
  68
  69      Include conf/modsecurity/*.conf
  70      Include conf/modsecurity/base_rules/*conf
  71
  72   3) Restart web server.
  73
  74   4) Make sure your web sites are still running fine.
  75
  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).
  80
  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.
  84
  85
  86 Known Issues
  87 ===============
  88
  89 Apache requests rejection and phase 2 rules
  90 -------------------------------------------
  91
  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)"
  96
  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.
 104
 105
 106 Google Analytics
 107 ----------------
 108
 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
 113
 114
 115 About Regular Expressions
 116 ============================
 117
 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
 120 are very complex.
 121
 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
 125 expression.
 126
 127 We plan to release the optimization script shortly to allow much easier editing
 128 of regular expressions.
 129
 130
 131 Core Rule Set Content
 132 =========================
 133
 134 In order to provide generic web applications protection, the Core Rule Set
 135 uses the following techniques:
 136
 137 1. HTTP protection - detecting violations of the HTTP protocol and a locally
 138 defined usage policy.
 139
 140 2. Common Web Attacks Protection - detecting common web application security
 141 attack.
 142
 143 3. Automation detection - Detecting bots, crawlers, scanners and other surface
 144 malicious activity.
 145
 146 4. Trojan Protection - Detecting access to Trojans horses.
 147
 148 5. Errors Hiding - Disguising error messages sent by the server
 149
 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
 152 site.
 153
 154
 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:
 161
 162 - SQL Injection
 163 - Cross-Site Scripting (XSS)
 164 - OS Command execution
 165 - Remote code inclusion
 166 - LDAP Injection
 167 - SSI Injection
 168 - Information leak
 169 - Buffer overflows
 170 - File disclosure
 171
 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.
 176
 177
 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.
 183
 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.
 188
 189
 190 Few Word of Caution
 191 -------------------
 192
 193 As with every new technology, using the ModSecurity Core Rule Set requires some caution:
 194
 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.
 199
 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.
 203
 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.
 208
 209
 210 Road Map
 211 --------
 212
 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.
 218
 219 Going forward we plan to:
 220
 221 - Utilize ModSecurity 2.0 support for events correlation to detect denial of
 222 service attacks, brute force attacks and attack reconnaissance
 223
 224 - Add a framework for validating SOAP requests.
 225
 226 - Add signatures for key known vulnerabilities.
 227
 228 Anything else you would want?
 229