/etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf is in modsecurity-crs 3.0.0-3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 | # ------------------------------------------------------------------------
# OWASP ModSecurity Core Rule Set ver.3.0.0
# Copyright (c) 2006-2016 Trustwave and contributors. All rights reserved.
#
# The OWASP ModSecurity Core Rule Set is distributed under
# Apache Software License (ASL) version 2
# Please see the enclosed LICENSE file for full details.
# ------------------------------------------------------------------------
#
# The purpose of this file is to hold LOCAL exceptions for your site. The
# types of rules that would go into this file are one where you want to
# short-circuit inspection and allow certain transactions to pass through
# inspection or if you want to alter rules that are applied.
#
# This file is named REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example for a
# very specific reason. Files affixed with the .example extension are designed
# to contain user created/modified data. The '.example'. extension should be
# renamed to end in .conf. The advantage of this is that when OWASP CRS is
# updated, the updates will not overwrite a user generated configuration file.
#
# As a result of this design paradigm users are encouraged NOT to directly
# modify rules. Instead they should use this
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS and the
# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS file to modify OWASP rules using
# methods similar to the examples specified below.
#
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS and
# RESPONSE-999-EXCLUSION-RULES-AFTER-CRS serve different purposes. ModSecurity
# effectively maintains two different context: startup, and per transaction.
# As a rule, directives are processed within the startup context. While they
# can affect the per transaction context they generally remain fixed during the
# execution of ModSecurity.
#
# As a result if one wanted to disable a rule at bootup the SecRuleRemoveById
# directive or one of its siblings would have to be placed AFTER the rule is
# listed, otherwise it will not have knowledge of the rules existence (since
# these rules are read in at the same time). This means that when using
# directives that effect SecRules, these exceptions should be placed AFTER all
# the existing rules. This is why RESPONSE-999-EXCLUSION-RULES-AFTER-CRS is
# designed such that it loads LAST.
#
# Conversely, ModSecurity supports several actions that can change the state of
# the underlying configuration during the per transaction context, this is when
# rules are being processed. Generally, these are accomplished by using the
# 'ctl' action. As these are part of a rule, they will be evaluated in the
# order rules are applied (by physical location, considering phases). As a
# result of this ordering a 'ctl' action should be placed with consideration to
# when it will be executed. This is particularly relevant for the 'ctl' options
# that involve modifying ID's (such as ruleRemoveById). In these cases it is
# important that such rules are placed BEFORE the rule ID they will affect.
# Unlike the setup context, by the time we process rules in the per-transaction
# context, we are already aware of all the rule ID's. It is by this logic that
# we include rules such as this BEFORE all the remaining rules. As a result
# REQUEST-900-EXCLUSION-RULES-BEFORE-CRS is designed to load FIRST.
#
# As a general rule:
# ctl:ruleEngine -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveById -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveByMsg -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveByTag -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetById -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetByMsg -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
# ctl:ruleRemoveTargetByTag -> place in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS
#
# SecRuleRemoveById -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleRemoveByMsg -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleRemoveByTag -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateActionById -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetById -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetByMsg -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
# SecRuleUpdateTargetByTag -> place in RESPONSE-999-EXCLUSION-RULES-AFTER-CRS
#
#
# What follows are a group of examples that show you how to perform rule
# exclusions.
#
#
# Example Exclusion Rule: Disable inspection for an authorized client
#
# This ruleset allows you to control how ModSecurity will handle traffic
# originating from Authorized Vulnerability Scanning (AVS) sources. See
# related blog post -
# http://blog.spiderlabs.com/2010/12/advanced-topic-of-the-week-handling-authorized-scanning-traffic.html
#
# White-list ASV network block (no blocking or logging of AVS traffic) Update
# IP network block as appropriate for your AVS traffic
#
# ModSec Rule Exclusion: Disable Rule Engine for known ASV IP
# SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
# "phase:1,id:1000,pass,nolog,ctl:ruleEngine=Off"
#
#
# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
# for an individual rule
#
# This rule shows how to conditionally exclude the "password"
# parameter for rule 942100 when the REQUEST_URI is /index.php
# ModSecurity Rule Exclusion: 942100 SQL Injection Detected via libinjection
#
# SecRule REQUEST_URI "@beginsWith /index.php" \
# "id:1001,phase:1,pass,nolog, \
# ctl:ruleRemoveTargetById=942100;ARGS:password"
#
#
# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
# for only certain attacks
#
# Attack rules within the CRS are tagged, with tags such as 'attack-lfi',
# 'attack-sqli', 'attack-xss', 'attack-injection-php', et cetera.
#
# ModSecurity Rule Exclusion: Disable inspection of ARGS:pwd
# for all rules tagged attack-sqli
# SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \
# "id:1002,phase:request,pass,nolog,\
# ctl:ruleRemoveTargetByTag=attack-sqli;ARGS:pwd"
#
# Example Exclusion Rule: Removing a specific ARGS parameter from inspection
# for all CRS rules
#
# This rule illustrates that we can use tagging very effectively to whitelist a
# common false positive across an entire ModSecurity instance. This can be done
# because every rule in OWASP_CRS is tagged with OWASP_CRS. This will NOT
# affect custom rules.
#
# ModSecurity Rule Exclusion: Disable inspection of ARGS:pwd
# for all CRS rules
# SecRule REQUEST_FILENAME "@endsWith /wp-login.php" \
# "id:1003,phase:request,pass,nolog,\
# ctl:ruleRemoveTargetByTag=CRS;ARGS:pwd"
#
# Example Exclusion Rule: Removing a range of rules
#
# This rule illustrates that we can remove a rule range via a ctl action.
# This uses the fact, that rules are grouped by topic in rule files covering
# a certain id range.
#
# ModSecurity Rule Exclusion: Disable all SQLi and XSS rules
# SecRule REQUEST_FILENAME "@beginsWith /admin" \
# "id:1004,phase:request,pass,nolog,\
# ctl:ruleRemoveById=941000-942999"
#
#
# The application specific rule exclusion files
# REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
# REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
# bring additional examples which can be useful then tuning a service.
|