3rdparty/modules/apache/templates/mod/security_crs.conf.erb

   1 # ---------------------------------------------------------------
   2 # Core ModSecurity Rule Set ver.2.2.6
   3 # Copyright (C) 2006-2012 Trustwave All rights reserved.
   4 #
   5 # The OWASP ModSecurity Core Rule Set is distributed under
   6 # Apache Software License (ASL) version 2
   7 # Please see the enclosed LICENCE file for full details.
   8 # ---------------------------------------------------------------
   9
  10
  11 #
  12 # -- [[ Recommended Base Configuration ]] -------------------------------------------------
  13 #
  14 # The configuration directives/settings in this file are used to control
  15 # the OWASP ModSecurity CRS. These settings do **NOT** configure the main
  16 # ModSecurity settings such as:
  17 #
  18 # - SecRuleEngine
  19 # - SecRequestBodyAccess
  20 # - SecAuditEngine
  21 # - SecDebugLog
  22 #
  23 # You should use the modsecurity.conf-recommended file that comes with the
  24 # ModSecurity source code archive.
  25 #
  26 # Ref: http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/trunk/modsecurity.conf-recommended
  27 #
  28
  29
  30 #
  31 # -- [[ Rule Version ]] -------------------------------------------------------------------
  32 #
  33 # Rule version data is added to the "Producer" line of Section H of the Audit log:
  34 #
  35 # - Producer: ModSecurity for Apache/2.7.0-rc1 (http://www.modsecurity.org/); OWASP_CRS/2.2.4.
  36 #
  37 # Ref: https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecComponentSignature
  38 #
  39 SecComponentSignature "OWASP_CRS/2.2.6"
  40
  41
  42 #
  43 # -- [[ Modes of Operation: Self-Contained vs. Collaborative Detection ]] -----------------
  44 #
  45 # Each detection rule uses the "block" action which will inherit the SecDefaultAction
  46 # specified below.  Your settings here will determine which mode of operation you use.
  47 #
  48 # -- [[ Self-Contained Mode ]] --
  49 # Rules inherit the "deny" disruptive action.  The first rule that matches will block.
  50 #
  51 # -- [[ Collaborative Detection Mode ]] --
  52 # This is a "delayed blocking" mode of operation where each matching rule will inherit
  53 # the "pass" action and will only contribute to anomaly scores.  Transactional blocking
  54 # can be applied
  55 #
  56 # -- [[ Alert Logging Control ]] --
  57 # You have three options -
  58 #
  59 # - To log to both the Apache error_log and ModSecurity audit_log file use: "log"
  60 # - To log *only* to the ModSecurity audit_log file use: "nolog,auditlog"
  61 # - To log *only* to the Apache error_log file use: "log,noauditlog"
  62 #
  63 # Ref: http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html
  64 # Ref: https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecDefaultAction
  65 #
  66 SecDefaultAction "phase:1,deny,log"
  67
  68
  69 #
  70 # -- [[ Collaborative Detection Severity Levels ]] ----------------------------------------
  71 #
  72 # These are the default scoring points for each severity level.  You may
  73 # adjust these to you liking.  These settings will be used in macro expansion
  74 # in the rules to increment the anomaly scores when rules match.
  75 #
  76 # These are the default Severity ratings (with anomaly scores) of the individual rules -
  77 #
  78 #    - 2: Critical - Anomaly Score of 5.
  79 #         Is the highest severity level possible without correlation.  It is
  80 #         normally generated by the web attack rules (40 level files).
  81 #    - 3: Error - Anomaly Score of 4.
  82 #         Is generated mostly from outbound leakage rules (50 level files).
  83 #    - 4: Warning - Anomaly Score of 3.
  84 #         Is generated by malicious client rules (35 level files).
  85 #    - 5: Notice - Anomaly Score of 2.
  86 #         Is generated by the Protocol policy and anomaly files.
  87 #
  88 SecAction \
  89   "id:'900001', \
  90   phase:1, \
  91   t:none, \
  92   setvar:tx.critical_anomaly_score=5, \
  93   setvar:tx.error_anomaly_score=4, \
  94   setvar:tx.warning_anomaly_score=3, \
  95   setvar:tx.notice_anomaly_score=2, \
  96   nolog, \
  97   pass"
  98
  99
 100 #
 101 # -- [[ Collaborative Detection Scoring Threshold Levels ]] ------------------------------
 102 #
 103 # These variables are used in macro expansion in the 49 inbound blocking and 59
 104 # outbound blocking files.
 105 #
 106 # **MUST HAVE** ModSecurity v2.5.12 or higher to use macro expansion in numeric
 107 # operators.  If you have an earlier version, edit the 49/59 files directly to
 108 # set the appropriate anomaly score levels.
 109 #
 110 # You should set the score to the proper threshold you would prefer. If set to "5"
 111 # it will work similarly to previous Mod CRS rules and will create an event in the error_log
 112 # file if there are any rules that match.  If you would like to lessen the number of events
 113 # generated in the error_log file, you should increase the anomaly score threshold to
 114 # something like "20".  This would only generate an event in the error_log file if
 115 # there are multiple lower severity rule matches or if any 1 higher severity item matches.
 116 #
 117 SecAction \
 118   "id:'900002', \
 119   phase:1, \
 120   t:none, \
 121   setvar:tx.inbound_anomaly_score_level=5, \
 122   nolog, \
 123   pass"
 124
 125
 126 SecAction \
 127   "id:'900003', \
 128   phase:1, \
 129   t:none, \
 130   setvar:tx.outbound_anomaly_score_level=4, \
 131   nolog, \
 132   pass"
 133
 134
 135 #
 136 # -- [[ Collaborative Detection Blocking ]] -----------------------------------------------
 137 #
 138 # This is a collaborative detection mode where each rule will increment an overall
 139 # anomaly score for the transaction. The scores are then evaluated in the following files:
 140 #
 141 # Inbound anomaly score - checked in the modsecurity_crs_49_inbound_blocking.conf file
 142 # Outbound anomaly score - checked in the modsecurity_crs_59_outbound_blocking.conf file
 143 #
 144 # If you want to use anomaly scoring mode, then uncomment this line.
 145 #
 146 #SecAction \
 147   "id:'900004', \
 148   phase:1, \
 149   t:none, \
 150   setvar:tx.anomaly_score_blocking=on, \
 151   nolog, \
 152   pass"
 153
 154
 155 #
 156 # -- [[ GeoIP Database ]] -----------------------------------------------------------------
 157 #
 158 # There are some rulesets that need to inspect the GEO data of the REMOTE_ADDR data.
 159 #
 160 # You must first download the MaxMind GeoIP Lite City DB -
 161 #
 162 #       http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
 163 #
 164 # You then need to define the proper path for the SecGeoLookupDb directive
 165 #
 166 # Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html
 167 # Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
 168 #
 169 #SecGeoLookupDb /opt/modsecurity/lib/GeoLiteCity.dat
 170
 171 #
 172 # -- [[ Regression Testing Mode ]] --------------------------------------------------------
 173 #
 174 # If you are going to run the regression testing mode, you should uncomment the
 175 # following rule. It will enable DetectionOnly mode for the SecRuleEngine and
 176 # will enable Response Header tagging so that the client testing script can see
 177 # which rule IDs have matched.
 178 #
 179 # You must specify the your source IP address where you will be running the tests
 180 # from.
 181 #
 182 #SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
 183   "id:'900005', \
 184   phase:1, \
 185   t:none, \
 186   ctl:ruleEngine=DetectionOnly, \
 187   setvar:tx.regression_testing=1, \
 188   nolog, \
 189   pass"
 190
 191
 192 #
 193 # -- [[ HTTP Policy Settings ]] ----------------------------------------------------------
 194 #
 195 # Set the following policy settings here and they will be propagated to the 23 rules
 196 # file (modsecurity_common_23_request_limits.conf) by using macro expansion.
 197 # If you run into false positives, you can adjust the settings here.
 198 #
 199 # Only the max number of args is uncommented by default as there are a high rate
 200 # of false positives.  Uncomment the items you wish to set.
 201 #
 202 #
 203 # -- Maximum number of arguments in request limited
 204 SecAction \
 205   "id:'900006', \
 206   phase:1, \
 207   t:none, \
 208   setvar:tx.max_num_args=255, \
 209   nolog, \
 210   pass"
 211
 212 #
 213 # -- Limit argument name length
 214 #SecAction \
 215   "id:'900007', \
 216   phase:1, \
 217   t:none, \
 218   setvar:tx.arg_name_length=100, \
 219   nolog, \
 220   pass"
 221
 222 #
 223 # -- Limit value name length
 224 #SecAction \
 225   "id:'900008', \
 226   phase:1, \
 227   t:none, \
 228   setvar:tx.arg_length=400, \
 229   nolog, \
 230   pass"
 231
 232 #
 233 # -- Limit arguments total length
 234 #SecAction \
 235   "id:'900009', \
 236   phase:1, \
 237   t:none, \
 238   setvar:tx.total_arg_length=64000, \
 239   nolog, \
 240   pass"
 241
 242 #
 243 # -- Individual file size is limited
 244 #SecAction \
 245   "id:'900010', \
 246   phase:1, \
 247   t:none, \
 248   setvar:tx.max_file_size=1048576, \
 249   nolog, \
 250   pass"
 251
 252 #
 253 # -- Combined file size is limited
 254 #SecAction \
 255   "id:'900011', \
 256   phase:1, \
 257   t:none, \
 258   setvar:tx.combined_file_sizes=1048576, \
 259   nolog, \
 260   pass"
 261
 262
 263 #
 264 # Set the following policy settings here and they will be propagated to the 30 rules
 265 # file (modsecurity_crs_30_http_policy.conf) by using macro expansion.
 266 # If you run into false positves, you can adjust the settings here.
 267 #
 268 SecAction \
 269   "id:'900012', \
 270   phase:1, \
 271   t:none, \
 272   setvar:'tx.allowed_methods=<%= @allowed_methods -%>', \
 273   setvar:'tx.allowed_request_content_type=<%= @content_types -%>', \
 274   setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
 275   setvar:'tx.restricted_extensions=<%= @restricted_extensions -%>', \
 276   setvar:'tx.restricted_headers=<%= @restricted_headers -%>', \
 277   nolog, \
 278   pass"
 279
 280
 281 #
 282 # -- [[ Content Security Policy (CSP) Settings ]] -----------------------------------------
 283 #
 284 # The purpose of these settings is to send CSP response headers to
 285 # Mozilla FireFox users so that you can enforce how dynamic content
 286 # is used. CSP usage helps to prevent XSS attacks against your users.
 287 #
 288 # Reference Link:
 289 #
 290 #       https://developer.mozilla.org/en/Security/CSP
 291 #
 292 # Uncomment this SecAction line if you want use CSP enforcement.
 293 # You need to set the appropriate directives and settings for your site/domain and
 294 # and activate the CSP file in the experimental_rules directory.
 295 #
 296 # Ref: http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html
 297 #
 298 #SecAction \
 299   "id:'900013', \
 300   phase:1, \
 301   t:none, \
 302   setvar:tx.csp_report_only=1, \
 303   setvar:tx.csp_report_uri=/csp_violation_report, \
 304   setenv:'csp_policy=allow \'self\'; img-src *.yoursite.com; media-src *.yoursite.com; style-src *.yoursite.com; frame-ancestors *.yoursite.com; script-src *.yoursite.com; report-uri %{tx.csp_report_uri}', \
 305   nolog, \
 306   pass"
 307
 308
 309 #
 310 # -- [[ Brute Force Protection ]] ---------------------------------------------------------
 311 #
 312 # If you are using the Brute Force Protection rule set, then uncomment the following
 313 # lines and set the following variables:
 314 # - Protected URLs: resources to protect (e.g. login pages) - set to your login page
 315 # - Burst Time Slice Interval: time interval window to monitor for bursts
 316 # - Request Threshold: request # threshold to trigger a burst
 317 # - Block Period: temporary block timeout
 318 #
 319 #SecAction \
 320   "id:'900014', \
 321   phase:1, \
 322   t:none, \
 323   setvar:'tx.brute_force_protected_urls=/login.jsp /partner_login.php', \
 324   setvar:'tx.brute_force_burst_time_slice=60', \
 325   setvar:'tx.brute_force_counter_threshold=10', \
 326   setvar:'tx.brute_force_block_timeout=300', \
 327   nolog, \
 328   pass"
 329
 330
 331 #
 332 # -- [[ DoS Protection ]] ----------------------------------------------------------------
 333 #
 334 # If you are using the DoS Protection rule set, then uncomment the following
 335 # lines and set the following variables:
 336 # - Burst Time Slice Interval: time interval window to monitor for bursts
 337 # - Request Threshold: request # threshold to trigger a burst
 338 # - Block Period: temporary block timeout
 339 #
 340 #SecAction \
 341   "id:'900015', \
 342   phase:1, \
 343   t:none, \
 344   setvar:'tx.dos_burst_time_slice=60', \
 345   setvar:'tx.dos_counter_threshold=100', \
 346   setvar:'tx.dos_block_timeout=600', \
 347   nolog, \
 348   pass"
 349
 350
 351 #
 352 # -- [[ Check UTF enconding ]] -----------------------------------------------------------
 353 #
 354 # We only want to apply this check if UTF-8 encoding is actually used by the site, otherwise
 355 # it will result in false positives.
 356 #
 357 # Uncomment this line if your site uses UTF8 encoding
 358 #SecAction \
 359   "id:'900016', \
 360   phase:1, \
 361   t:none, \
 362   setvar:tx.crs_validate_utf8_encoding=1, \
 363   nolog, \
 364   pass"
 365
 366
 367 #
 368 # -- [[ Enable XML Body Parsing ]] -------------------------------------------------------
 369 #
 370 # The rules in this file will trigger the XML parser upon an XML request
 371 #
 372 # Initiate XML Processor in case of xml content-type
 373 #
 374 SecRule REQUEST_HEADERS:Content-Type "text/xml" \
 375   "id:'900017', \
 376   phase:1, \
 377   t:none,t:lowercase, \
 378   nolog, \
 379   pass, \
 380   chain"
 381         SecRule REQBODY_PROCESSOR "!@streq XML" \
 382           "ctl:requestBodyProcessor=XML"
 383
 384
 385 #
 386 # -- [[ Global and IP Collections ]] -----------------------------------------------------
 387 #
 388 # Create both Global and IP collections for rules to use
 389 # There are some CRS rules that assume that these two collections
 390 # have already been initiated.
 391 #
 392 SecRule REQUEST_HEADERS:User-Agent "^(.*)$" \
 393   "id:'900018', \
 394   phase:1, \
 395   t:none,t:sha1,t:hexEncode, \
 396   setvar:tx.ua_hash=%{matched_var}, \
 397   nolog, \
 398   pass"
 399
 400
 401 SecRule REQUEST_HEADERS:x-forwarded-for "^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b" \
 402   "id:'900019', \
 403   phase:1, \
 404   t:none, \
 405   capture, \
 406   setvar:tx.real_ip=%{tx.1}, \
 407   nolog, \
 408   pass"
 409
 410
 411 SecRule &TX:REAL_IP "!@eq 0" \
 412   "id:'900020', \
 413   phase:1, \
 414   t:none, \
 415   initcol:global=global, \
 416   initcol:ip=%{tx.real_ip}_%{tx.ua_hash}, \
 417   nolog, \
 418   pass"
 419
 420
 421 SecRule &TX:REAL_IP "@eq 0" \
 422   "id:'900021', \
 423   phase:1, \
 424   t:none, \
 425   initcol:global=global, \
 426   initcol:ip=%{remote_addr}_%{tx.ua_hash}, \
 427   nolog, \
 428   pass"