|  | 
|  | 1 | +# -- Rule engine initialization ---------------------------------------------- | 
|  | 2 | + | 
|  | 3 | +# Enable ModSecurity, attaching it to every transaction. Use detection | 
|  | 4 | +# only to start with, because that minimises the chances of post-installation | 
|  | 5 | +# disruption. | 
|  | 6 | +# | 
|  | 7 | +SecRuleEngine On | 
|  | 8 | + | 
|  | 9 | + | 
|  | 10 | +# -- Request body handling --------------------------------------------------- | 
|  | 11 | + | 
|  | 12 | +# Allow ModSecurity to access request bodies. If you don't, ModSecurity | 
|  | 13 | +# won't be able to see any POST parameters, which opens a large security | 
|  | 14 | +# hole for attackers to exploit. | 
|  | 15 | +# | 
|  | 16 | +SecRequestBodyAccess On | 
|  | 17 | + | 
|  | 18 | + | 
|  | 19 | +# Enable XML request body parser. | 
|  | 20 | +# Initiate XML Processor in case of xml content-type | 
|  | 21 | +# | 
|  | 22 | +SecRule REQUEST_HEADERS:Content-Type "^(?:application(?:/soap\+|/)|text/)xml" \ | 
|  | 23 | + "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" | 
|  | 24 | + | 
|  | 25 | +# Enable JSON request body parser. | 
|  | 26 | +# Initiate JSON Processor in case of JSON content-type; change accordingly | 
|  | 27 | +# if your application does not use 'application/json' | 
|  | 28 | +# | 
|  | 29 | +SecRule REQUEST_HEADERS:Content-Type "^application/json" \ | 
|  | 30 | + "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" | 
|  | 31 | + | 
|  | 32 | +# Sample rule to enable JSON request body parser for more subtypes. | 
|  | 33 | +# Uncomment or adapt this rule if you want to engage the JSON | 
|  | 34 | +# Processor for "+json" subtypes | 
|  | 35 | +# | 
|  | 36 | +#SecRule REQUEST_HEADERS:Content-Type "^application/[a-z0-9.-]+[+]json" \ | 
|  | 37 | +# "id:'200006',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON" | 
|  | 38 | + | 
|  | 39 | +# Maximum request body size we will accept for buffering. If you support | 
|  | 40 | +# file uploads then the value given on the first line has to be as large | 
|  | 41 | +# as the largest file you are willing to accept. The second value refers | 
|  | 42 | +# to the size of data, with files excluded. You want to keep that value as | 
|  | 43 | +# low as practical. | 
|  | 44 | +# | 
|  | 45 | +SecRequestBodyLimit 13107200 | 
|  | 46 | +SecRequestBodyNoFilesLimit 131072 | 
|  | 47 | + | 
|  | 48 | +# What to do if the request body size is above our configured limit. | 
|  | 49 | +# Keep in mind that this setting will automatically be set to ProcessPartial | 
|  | 50 | +# when SecRuleEngine is set to DetectionOnly mode in order to minimize | 
|  | 51 | +# disruptions when initially deploying ModSecurity. | 
|  | 52 | +# | 
|  | 53 | +SecRequestBodyLimitAction Reject | 
|  | 54 | + | 
|  | 55 | +# Maximum parsing depth allowed for JSON objects. You want to keep this | 
|  | 56 | +# value as low as practical. | 
|  | 57 | +# | 
|  | 58 | +SecRequestBodyJsonDepthLimit 512 | 
|  | 59 | + | 
|  | 60 | +# Maximum number of args allowed per request. You want to keep this | 
|  | 61 | +# value as low as practical. The value should match that in rule 200007. | 
|  | 62 | +SecArgumentsLimit 1000 | 
|  | 63 | + | 
|  | 64 | +# If SecArgumentsLimit has been set, you probably want to reject any | 
|  | 65 | +# request body that has only been partly parsed. The value used in this | 
|  | 66 | +# rule should match what was used with SecArgumentsLimit | 
|  | 67 | +SecRule &ARGS "@ge 1000" \ | 
|  | 68 | +"id:'200007', phase:2,t:none,log,deny,status:400,msg:'Failed to fully parse request body due to large argument count',severity:2" | 
|  | 69 | + | 
|  | 70 | +# Verify that we've correctly processed the request body. | 
|  | 71 | +# As a rule of thumb, when failing to process a request body | 
|  | 72 | +# you should reject the request (when deployed in blocking mode) | 
|  | 73 | +# or log a high-severity alert (when deployed in detection-only mode). | 
|  | 74 | +# | 
|  | 75 | +SecRule REQBODY_ERROR "!@eq 0" \ | 
|  | 76 | +"id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2" | 
|  | 77 | + | 
|  | 78 | +# By default be strict with what we accept in the multipart/form-data | 
|  | 79 | +# request body. If the rule below proves to be too strict for your | 
|  | 80 | +# environment consider changing it to detection-only. You are encouraged | 
|  | 81 | +# _not_ to remove it altogether. | 
|  | 82 | +# | 
|  | 83 | +SecRule MULTIPART_STRICT_ERROR "!@eq 0" \ | 
|  | 84 | +"id:'200003',phase:2,t:none,log,deny,status:400, \ | 
|  | 85 | +msg:'Multipart request body failed strict validation: \ | 
|  | 86 | +PE %{REQBODY_PROCESSOR_ERROR}, \ | 
|  | 87 | +BQ %{MULTIPART_BOUNDARY_QUOTED}, \ | 
|  | 88 | +BW %{MULTIPART_BOUNDARY_WHITESPACE}, \ | 
|  | 89 | +DB %{MULTIPART_DATA_BEFORE}, \ | 
|  | 90 | +DA %{MULTIPART_DATA_AFTER}, \ | 
|  | 91 | +HF %{MULTIPART_HEADER_FOLDING}, \ | 
|  | 92 | +LF %{MULTIPART_LF_LINE}, \ | 
|  | 93 | +SM %{MULTIPART_MISSING_SEMICOLON}, \ | 
|  | 94 | +IQ %{MULTIPART_INVALID_QUOTING}, \ | 
|  | 95 | +IP %{MULTIPART_INVALID_PART}, \ | 
|  | 96 | +IH %{MULTIPART_INVALID_HEADER_FOLDING}, \ | 
|  | 97 | +FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'" | 
|  | 98 | + | 
|  | 99 | +# Did we see anything that might be a boundary? | 
|  | 100 | +# | 
|  | 101 | +# Here is a short description about the ModSecurity Multipart parser: the | 
|  | 102 | +# parser returns with value 0, if all "boundary-like" line matches with | 
|  | 103 | +# the boundary string which given in MIME header. In any other cases it returns | 
|  | 104 | +# with different value, eg. 1 or 2. | 
|  | 105 | +# | 
|  | 106 | +# The RFC 1341 descript the multipart content-type and its syntax must contains | 
|  | 107 | +# only three mandatory lines (above the content): | 
|  | 108 | +# * Content-Type: multipart/mixed; boundary=BOUNDARY_STRING | 
|  | 109 | +# * --BOUNDARY_STRING | 
|  | 110 | +# * --BOUNDARY_STRING-- | 
|  | 111 | +# | 
|  | 112 | +# First line indicates, that this is a multipart content, second shows that | 
|  | 113 | +# here starts a part of the multipart content, third shows the end of content. | 
|  | 114 | +# | 
|  | 115 | +# If there are any other lines, which starts with "--", then it should be | 
|  | 116 | +# another boundary id - or not. | 
|  | 117 | +# | 
|  | 118 | +# After 3.0.3, there are two kinds of types of boundary errors: strict and permissive. | 
|  | 119 | +# | 
|  | 120 | +# If multipart content contains the three necessary lines with correct order, but | 
|  | 121 | +# there are one or more lines with "--", then parser returns with value 2 (non-zero). | 
|  | 122 | +# | 
|  | 123 | +# If some of the necessary lines (usually the start or end) misses, or the order | 
|  | 124 | +# is wrong, then parser returns with value 1 (also a non-zero). | 
|  | 125 | +# | 
|  | 126 | +# You can choose, which one is what you need. The example below contains the | 
|  | 127 | +# 'strict' mode, which means if there are any lines with start of "--", then | 
|  | 128 | +# ModSecurity blocked the content. But the next, commented example contains | 
|  | 129 | +# the 'permissive' mode, then you check only if the necessary lines exists in | 
|  | 130 | +# correct order. Whit this, you can enable to upload PEM files (eg "----BEGIN.."), | 
|  | 131 | +# or other text files, which contains eg. HTTP headers. | 
|  | 132 | +# | 
|  | 133 | +# The difference is only the operator - in strict mode (first) the content blocked | 
|  | 134 | +# in case of any non-zero value. In permissive mode (second, commented) the | 
|  | 135 | +# content blocked only if the value is explicit 1. If it 0 or 2, the content will | 
|  | 136 | +# allowed. | 
|  | 137 | +# | 
|  | 138 | + | 
|  | 139 | +# | 
|  | 140 | +# See #1747 and #1924 for further information on the possible values for | 
|  | 141 | +# MULTIPART_UNMATCHED_BOUNDARY. | 
|  | 142 | +# | 
|  | 143 | +SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \ | 
|  | 144 | + "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'" | 
|  | 145 | + | 
|  | 146 | + | 
|  | 147 | +# PCRE Tuning | 
|  | 148 | +# We want to avoid a potential RegEx DoS condition | 
|  | 149 | +# | 
|  | 150 | +SecPcreMatchLimit 1000 | 
|  | 151 | +SecPcreMatchLimitRecursion 1000 | 
|  | 152 | + | 
|  | 153 | +# Some internal errors will set flags in TX and we will need to look for these. | 
|  | 154 | +# All of these are prefixed with "MSC_". The following flags currently exist: | 
|  | 155 | +# | 
|  | 156 | +# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded. | 
|  | 157 | +# | 
|  | 158 | +SecRule TX:/^MSC_/ "!@streq 0" \ | 
|  | 159 | + "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'" | 
|  | 160 | + | 
|  | 161 | + | 
|  | 162 | +# -- Response body handling -------------------------------------------------- | 
|  | 163 | + | 
|  | 164 | +# Allow ModSecurity to access response bodies.  | 
|  | 165 | +# You should have this directive enabled in order to identify errors | 
|  | 166 | +# and data leakage issues. | 
|  | 167 | +#  | 
|  | 168 | +# Do keep in mind that enabling this directive does increases both | 
|  | 169 | +# memory consumption and response latency. | 
|  | 170 | +# | 
|  | 171 | +SecResponseBodyAccess On | 
|  | 172 | + | 
|  | 173 | +# Which response MIME types do you want to inspect? You should adjust the | 
|  | 174 | +# configuration below to catch documents but avoid static files | 
|  | 175 | +# (e.g., images and archives). | 
|  | 176 | +# | 
|  | 177 | +SecResponseBodyMimeType text/plain text/html text/xml | 
|  | 178 | + | 
|  | 179 | +# Buffer response bodies of up to 512 KB in length. | 
|  | 180 | +SecResponseBodyLimit 524288 | 
|  | 181 | + | 
|  | 182 | +# What happens when we encounter a response body larger than the configured | 
|  | 183 | +# limit? By default, we process what we have and let the rest through. | 
|  | 184 | +# That's somewhat less secure, but does not break any legitimate pages. | 
|  | 185 | +# | 
|  | 186 | +SecResponseBodyLimitAction ProcessPartial | 
|  | 187 | + | 
|  | 188 | + | 
|  | 189 | +# -- Filesystem configuration ------------------------------------------------ | 
|  | 190 | + | 
|  | 191 | +# The location where ModSecurity stores temporary files (for example, when | 
|  | 192 | +# it needs to handle a file upload that is larger than the configured limit). | 
|  | 193 | +#  | 
|  | 194 | +# This default setting is chosen due to all systems have /tmp available however,  | 
|  | 195 | +# this is less than ideal. It is recommended that you specify a location that's private. | 
|  | 196 | +# | 
|  | 197 | +SecTmpDir /tmp/ | 
|  | 198 | + | 
|  | 199 | +# The location where ModSecurity will keep its persistent data. This default setting  | 
|  | 200 | +# is chosen due to all systems have /tmp available however, it | 
|  | 201 | +# too should be updated to a place that other users can't access. | 
|  | 202 | +# | 
|  | 203 | +SecDataDir /tmp/ | 
|  | 204 | + | 
|  | 205 | + | 
|  | 206 | +# -- File uploads handling configuration ------------------------------------- | 
|  | 207 | + | 
|  | 208 | +# The location where ModSecurity stores intercepted uploaded files. This | 
|  | 209 | +# location must be private to ModSecurity. You don't want other users on | 
|  | 210 | +# the server to access the files, do you? | 
|  | 211 | +# | 
|  | 212 | +#SecUploadDir /opt/modsecurity/var/upload/ | 
|  | 213 | + | 
|  | 214 | +# By default, only keep the files that were determined to be unusual | 
|  | 215 | +# in some way (by an external inspection script). For this to work you | 
|  | 216 | +# will also need at least one file inspection rule. | 
|  | 217 | +# | 
|  | 218 | +#SecUploadKeepFiles RelevantOnly | 
|  | 219 | + | 
|  | 220 | +# Uploaded files are by default created with permissions that do not allow | 
|  | 221 | +# any other user to access them. You may need to relax that if you want to | 
|  | 222 | +# interface ModSecurity to an external program (e.g., an anti-virus). | 
|  | 223 | +# | 
|  | 224 | +#SecUploadFileMode 0600 | 
|  | 225 | + | 
|  | 226 | + | 
|  | 227 | +# -- Debug log configuration ------------------------------------------------- | 
|  | 228 | + | 
|  | 229 | +# The default debug log configuration is to duplicate the error, warning | 
|  | 230 | +# and notice messages from the error log. | 
|  | 231 | +# | 
|  | 232 | +#SecDebugLog /opt/modsecurity/var/log/debug.log | 
|  | 233 | +#SecDebugLogLevel 3 | 
|  | 234 | + | 
|  | 235 | + | 
|  | 236 | +# -- Audit log configuration ------------------------------------------------- | 
|  | 237 | + | 
|  | 238 | +# Log the transactions that are marked by a rule, as well as those that | 
|  | 239 | +# trigger a server error (determined by a 5xx or 4xx, excluding 404,  | 
|  | 240 | +# level response status codes). | 
|  | 241 | +# | 
|  | 242 | +SecAuditEngine RelevantOnly | 
|  | 243 | +SecAuditLogRelevantStatus "^(?:5|4(?!04))" | 
|  | 244 | + | 
|  | 245 | +# Log everything we know about a transaction. | 
|  | 246 | +SecAuditLogParts ABIJDEFHZ | 
|  | 247 | + | 
|  | 248 | +# Use a single file for logging. This is much easier to look at, but | 
|  | 249 | +# assumes that you will use the audit log only ocassionally. | 
|  | 250 | +# | 
|  | 251 | +SecAuditLogType Serial | 
|  | 252 | +SecAuditLog /var/log/modsec_audit.log | 
|  | 253 | + | 
|  | 254 | +# Specify the path for concurrent audit logging. | 
|  | 255 | +#SecAuditLogStorageDir /opt/modsecurity/var/audit/ | 
|  | 256 | + | 
|  | 257 | + | 
|  | 258 | +# -- Miscellaneous ----------------------------------------------------------- | 
|  | 259 | + | 
|  | 260 | +# Use the most commonly used application/x-www-form-urlencoded parameter | 
|  | 261 | +# separator. There's probably only one application somewhere that uses | 
|  | 262 | +# something else so don't expect to change this value. | 
|  | 263 | +# | 
|  | 264 | +SecArgumentSeparator & | 
|  | 265 | + | 
|  | 266 | +# Settle on version 0 (zero) cookies, as that is what most applications | 
|  | 267 | +# use. Using an incorrect cookie version may open your installation to | 
|  | 268 | +# evasion attacks (against the rules that examine named cookies). | 
|  | 269 | +# | 
|  | 270 | +SecCookieFormat 0 | 
|  | 271 | + | 
|  | 272 | +# Specify your Unicode Code Point. | 
|  | 273 | +# This mapping is used by the t:urlDecodeUni transformation function | 
|  | 274 | +# to properly map encoded data to your language. Properly setting | 
|  | 275 | +# these directives helps to reduce false positives and negatives. | 
|  | 276 | +# | 
|  | 277 | +SecUnicodeMapFile unicode.mapping 20127 | 
|  | 278 | + | 
|  | 279 | +# Improve the quality of ModSecurity by sharing information about your | 
|  | 280 | +# current ModSecurity version and dependencies versions. | 
|  | 281 | +# The following information will be shared: ModSecurity version, | 
|  | 282 | +# Web Server version, APR version, PCRE version, Lua version, Libxml2 | 
|  | 283 | +# version, Anonymous unique id for host. | 
|  | 284 | +SecStatusEngine Off | 
|  | 285 | + | 
|  | 286 | +SecRule ARGS "@rx attack" \ | 
|  | 287 | + "id:10001,\ | 
|  | 288 | + phase:1,\ | 
|  | 289 | + t:none,\ | 
|  | 290 | + log,\ | 
|  | 291 | + deny" | 
0 commit comments