-[{"comment":"module loaded","match_log":{"error":[{"__regex__":1,"flags":"","pattern":"ModSecurity for Apache.* configured\\."},10]},"type":"config"},{"comment":"minimal config","conf":"# -- Rule engine initialization ----------------------------------------------\n\n# Enable ModSecurity, attaching it to every transaction. Use detection\n# only to start with, because that minimises the chances of post-installation\n# disruption.\n#\nSecRuleEngine DetectionOnly\n\n\n# -- Request body handling ---------------------------------------------------\n\n# Allow ModSecurity to access request bodies. If you don't, ModSecurity\n# won't be able to see any POST parameters, which opens a large security\n# hole for attackers to exploit.\n#\nSecRequestBodyAccess On\n\n\n# Enable XML request body parser.\n# Initiate XML Processor in case of xml content-type\n#\nSecRule REQUEST_HEADERS:Content-Type \"^(?:application(?:/soap\\+|/)|text/)xml\" \\\n \"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML\"\n\n# Enable JSON request body parser.\n# Initiate JSON Processor in case of JSON content-type; change accordingly\n# if your application does not use 'application/json'\n#\nSecRule REQUEST_HEADERS:Content-Type \"^application/json\" \\\n \"id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON\"\n\n# Sample rule to enable JSON request body parser for more subtypes.\n# Uncomment or adapt this rule if you want to engage the JSON\n# Processor for \"+json\" subtypes\n#\n#SecRule REQUEST_HEADERS:Content-Type \"^application/[a-z0-9.-]+[+]json\" \\\n# \"id:'200006',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON\"\n\n# Maximum request body size we will accept for buffering. If you support\n# file uploads then the value given on the first line has to be as large\n# as the largest file you are willing to accept. The second value refers\n# to the size of data, with files excluded. You want to keep that value as\n# low as practical.\n#\nSecRequestBodyLimit 13107200\nSecRequestBodyNoFilesLimit 131072\n\n# Store up to 128 KB of request body data in memory. When the multipart\n# parser reaches this limit, it will start using your hard disk for\n# storage. That is slow, but unavoidable.\n#\nSecRequestBodyInMemoryLimit 131072\n\n# What do do if the request body size is above our configured limit.\n# Keep in mind that this setting will automatically be set to ProcessPartial\n# when SecRuleEngine is set to DetectionOnly mode in order to minimize\n# disruptions when initially deploying ModSecurity.\n#\nSecRequestBodyLimitAction Reject\n\n# Maximum parsing depth allowed for JSON objects. You want to keep this\n# value as low as practical.\n#\nSecRequestBodyJsonDepthLimit 512\n\n# Verify that we've correctly processed the request body.\n# As a rule of thumb, when failing to process a request body\n# you should reject the request (when deployed in blocking mode)\n# or log a high-severity alert (when deployed in detection-only mode).\n#\nSecRule REQBODY_ERROR \"!@eq 0\" \\\n\"id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2\"\n\n# By default be strict with what we accept in the multipart/form-data\n# request body. If the rule below proves to be too strict for your\n# environment consider changing it to detection-only. You are encouraged\n# _not_ to remove it altogether.\n#\nSecRule MULTIPART_STRICT_ERROR \"!@eq 0\" \\\n\"id:'200003',phase:2,t:none,log,deny,status:400, \\\nmsg:'Multipart request body failed strict validation: \\\nPE %{REQBODY_PROCESSOR_ERROR}, \\\nBQ %{MULTIPART_BOUNDARY_QUOTED}, \\\nBW %{MULTIPART_BOUNDARY_WHITESPACE}, \\\nDB %{MULTIPART_DATA_BEFORE}, \\\nDA %{MULTIPART_DATA_AFTER}, \\\nHF %{MULTIPART_HEADER_FOLDING}, \\\nLF %{MULTIPART_LF_LINE}, \\\nSM %{MULTIPART_MISSING_SEMICOLON}, \\\nIQ %{MULTIPART_INVALID_QUOTING}, \\\nIP %{MULTIPART_INVALID_PART}, \\\nIH %{MULTIPART_INVALID_HEADER_FOLDING}, \\\nFL %{MULTIPART_FILE_LIMIT_EXCEEDED}'\"\n\n# Did we see anything that might be a boundary?\n#\nSecRule MULTIPART_UNMATCHED_BOUNDARY \"!@eq 0\" \\\n\"id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'\"\n\n# PCRE Tuning\n# We want to avoid a potential RegEx DoS condition\n#\nSecPcreMatchLimit 1000\nSecPcreMatchLimitRecursion 1000\n\n# Some internal errors will set flags in TX and we will need to look for these.\n# All of these are prefixed with \"MSC_\". The following flags currently exist:\n#\n# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.\n#\nSecRule TX:/^MSC_/ \"!@streq 0\" \\\n \"id:'200005',phase:2,t:none,log,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'\"\n\n\n# -- Response body handling --------------------------------------------------\n\n# Allow ModSecurity to access response bodies. \n# You should have this directive enabled in order to identify errors\n# and data leakage issues.\n# \n# Do keep in mind that enabling this directive does increases both\n# memory consumption and response latency.\n#\nSecResponseBodyAccess On\n\n# Which response MIME types do you want to inspect? You should adjust the\n# configuration below to catch documents but avoid static files\n# (e.g., images and archives).\n#\nSecResponseBodyMimeType text/plain text/html text/xml\n\n# Buffer response bodies of up to 512 KB in length.\nSecResponseBodyLimit 524288\n\n# What happens when we encounter a response body larger than the configured\n# limit? By default, we process what we have and let the rest through.\n# That's somewhat less secure, but does not break any legitimate pages.\n#\nSecResponseBodyLimitAction ProcessPartial\n\n\n# -- Filesystem configuration ------------------------------------------------\n\n# The location where ModSecurity stores temporary files (for example, when\n# it needs to handle a file upload that is larger than the configured limit).\n# \n# This default setting is chosen due to all systems have /tmp available however, \n# this is less than ideal. It is recommended that you specify a location that's private.\n#\nSecTmpDir /tmp/\n\n# The location where ModSecurity will keep its persistent data. This default setting \n# is chosen due to all systems have /tmp available however, it\n# too should be updated to a place that other users can't access.\n#\nSecDataDir /tmp/\n\n\n# -- File uploads handling configuration -------------------------------------\n\n# The location where ModSecurity stores intercepted uploaded files. This\n# location must be private to ModSecurity. You don't want other users on\n# the server to access the files, do you?\n#\n#SecUploadDir /opt/modsecurity/var/upload/\n\n# By default, only keep the files that were determined to be unusual\n# in some way (by an external inspection script). For this to work you\n# will also need at least one file inspection rule.\n#\n#SecUploadKeepFiles RelevantOnly\n\n# Uploaded files are by default created with permissions that do not allow\n# any other user to access them. You may need to relax that if you want to\n# interface ModSecurity to an external program (e.g., an anti-virus).\n#\n#SecUploadFileMode 0600\n\n\n# -- Debug log configuration -------------------------------------------------\n\n# The default debug log configuration is to duplicate the error, warning\n# and notice messages from the error log.\n#\n#SecDebugLog /opt/modsecurity/var/log/debug.log\n#SecDebugLogLevel 3\n\n\n# -- Audit log configuration -------------------------------------------------\n\n# Log the transactions that are marked by a rule, as well as those that\n# trigger a server error (determined by a 5xx or 4xx, excluding 404, \n# level response status codes).\n#\nSecAuditEngine RelevantOnly\nSecAuditLogRelevantStatus \"^(?:5|4(?!04))\"\n\n# Log everything we know about a transaction.\nSecAuditLogParts ABIJDEFHZ\n\n# Use a single file for logging. This is much easier to look at, but\n# assumes that you will use the audit log only ocassionally.\n#\n#SecAuditLogType Serial\n#SecAuditLog /var/log/modsec_audit.log\n\n# Specify the path for concurrent audit logging.\n#SecAuditLogStorageDir /opt/modsecurity/var/audit/\n\n\n# -- Miscellaneous -----------------------------------------------------------\n\n# Use the most commonly used application/x-www-form-urlencoded parameter\n# separator. There's probably only one application somewhere that uses\n# something else so don't expect to change this value.\n#\nSecArgumentSeparator &\n\n# Settle on version 0 (zero) cookies, as that is what most applications\n# use. Using an incorrect cookie version may open your installation to\n# evasion attacks (against the rules that examine named cookies).\n#\nSecCookieFormat 0\n\n# Specify your Unicode Code Point.\n# This mapping is used by the t:urlDecodeUni transformation function\n# to properly map encoded data to your language. Properly setting\n# these directives helps to reduce false positives and negatives.\n#\nSecUnicodeMapFile unicode.mapping 20127\n\n# Improve the quality of ModSecurity by sharing information about your\n# current ModSecurity version and dependencies versions.\n# The following information will be shared: ModSecurity version,\n# Web Server version, APR version, PCRE version, Lua version, Libxml2\n# version, Anonymous unique id for host.\n# NB: As of April 2022, there is no longer any advantage to turning this\n# setting On, as there is no active receiver for the information.\nSecStatusEngine Off\n\n","match_log":{"error":[{"__regex__":1,"flags":"","pattern":"ModSecurity for Apache.* configured\\."},10]},"type":"config"}]
0 commit comments