117 lines
4.4 KiB
Text
117 lines
4.4 KiB
Text
|
# {{ ansible_managed }}
|
||
|
|
|
||
|
|
# -- Rule engine initialization ----------------------------------------------
|
||
|
|
|
||
|
|
# Enable Coraza, attaching it to every transaction. Use detection
|
||
|
|
# only to start with, because that minimises the chances of post-installation
|
||
|
|
# disruption.
|
||
|
|
#
|
||
|
|
SecRuleEngine {{ coraza_sec_rule_engine | default("DetectionOnly") }}
|
||
|
|
|
||
|
|
|
||
|
|
# -- Request body handling ---------------------------------------------------
|
||
|
|
|
||
|
|
# Allow Coraza to access request bodies. If you don't, Coraza
|
||
|
|
# won't be able to see any POST parameters, which opens a large security
|
||
|
|
# hole for attackers to exploit.
|
||
|
|
#
|
||
|
|
SecRequestBodyAccess On
|
||
|
|
|
||
|
|
# Enable XML request body parser.
|
||
|
|
# Initiate XML Processor in case of xml content-type
|
||
|
|
#
|
||
|
|
SecRule REQUEST_HEADERS:Content-Type "^(?:application(?:/soap\+|/)|text/)xml" \
|
||
|
|
"id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
|
||
|
|
|
||
|
|
# Enable JSON request body parser.
|
||
|
|
# Initiate JSON Processor in case of JSON content-type; change accordingly
|
||
|
|
# if your application does not use 'application/json'
|
||
|
|
#
|
||
|
|
SecRule REQUEST_HEADERS:Content-Type "^application/json" \
|
||
|
|
"id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
|
||
|
|
|
||
|
|
# Enable JSON request body parser for more subtypes.
|
||
|
|
# Adapt this rule if you want to engage the JSON Processor for "+json" subtypes
|
||
|
|
#
|
||
|
|
SecRule REQUEST_HEADERS:Content-Type "^application/[a-z0-9.-]+[+]json" \
|
||
|
|
"id:'200006',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
|
||
|
|
|
||
|
|
# Maximum request body size we will accept for buffering. If you support
|
||
|
|
# file uploads, this value must has to be as large as the largest file
|
||
|
|
# you are willing to accept.
|
||
|
|
SecRequestBodyLimit 13107200
|
||
|
|
|
||
|
|
# Maximum request body size that Coraza will store in memory. If the body
|
||
|
|
# size exceeds this value, it will be saved to a temporary file on disk.
|
||
|
|
SecRequestBodyInMemoryLimit 131072
|
||
|
|
|
||
|
|
# Maximum request body size we will accept for buffering, with files excluded.
|
||
|
|
# You want to keep that value as low as practical.
|
||
|
|
# Note: SecRequestBodyNoFilesLimit is currently NOT supported by Coraza
|
||
|
|
# SecRequestBodyNoFilesLimit 131072
|
||
|
|
|
||
|
|
# What to do if the request body size is above our configured limit.
|
||
|
|
# Keep in mind that this setting will automatically be set to ProcessPartial
|
||
|
|
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
|
||
|
|
# disruptions when initially deploying Coraza.
|
||
|
|
# Warning: Setting this directive to ProcessPartial introduces a potential bypass
|
||
|
|
# risk, as attackers could prepend junk data equal to or greater than the inspected body size.
|
||
|
|
#
|
||
|
|
SecRequestBodyLimitAction Reject
|
||
|
|
|
||
|
|
# Verify that we've correctly processed the request body.
|
||
|
|
# As a rule of thumb, when failing to process a request body
|
||
|
|
# you should reject the request (when deployed in blocking mode)
|
||
|
|
# or log a high-severity alert (when deployed in detection-only mode).
|
||
|
|
#
|
||
|
|
SecRule REQBODY_ERROR "!@eq 0" \
|
||
|
|
"id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
|
||
|
|
|
||
|
|
# By default be strict with what we accept in the multipart/form-data
|
||
|
|
# request body. If the rule below proves to be too strict for your
|
||
|
|
# environment consider changing it to detection-only.
|
||
|
|
# Do NOT remove it, as it will catch many evasion attempts.
|
||
|
|
#
|
||
|
|
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
|
||
|
|
"id:'200003',phase:2,t:none,log,deny,status:400, \
|
||
|
|
msg:'Multipart request body failed strict validation."
|
||
|
|
|
||
|
|
|
||
|
|
# -- Debug log configuration -------------------------------------------------
|
||
|
|
|
||
|
|
# Default debug log path
|
||
|
|
# Debug levels:
|
||
|
|
# 0: No logging (least verbose)
|
||
|
|
# 1: Error
|
||
|
|
# 2: Warn
|
||
|
|
# 3: Info
|
||
|
|
# 4-8: Debug
|
||
|
|
# 9: Trace (most verbose)
|
||
|
|
#
|
||
|
|
SecDebugLog /var/log/coraza/debug.log
|
||
|
|
SecDebugLogLevel 3
|
||
|
|
|
||
|
|
|
||
|
|
# -- Audit log configuration -------------------------------------------------
|
||
|
|
|
||
|
|
# Log the transactions that are marked by a rule, as well as those that
|
||
|
|
# trigger a server error (determined by a 5xx or 4xx, excluding 404,
|
||
|
|
# level response status codes).
|
||
|
|
#
|
||
|
|
SecAuditEngine RelevantOnly
|
||
|
|
SecAuditLogRelevantStatus "^(?:(5|4)(0|1)[0-9])$"
|
||
|
|
|
||
|
|
# Define which parts of the transaction are going to be recorded in the audit log
|
||
|
|
SecAuditLogParts ABIJDEFHZ
|
||
|
|
|
||
|
|
# Use a single file for logging. This is much easier to look at, but
|
||
|
|
# assumes that you will use the audit log only occasionally.
|
||
|
|
#
|
||
|
|
SecAuditLogType Serial
|
||
|
|
SecAuditLogDir /var/log/coraza/audit
|
||
|
|
SecAuditLog /var/log/coraza/audit.log
|
||
|
|
|
||
|
|
# The format used to write the audit log.
|
||
|
|
# Can be one of JSON|JsonLegacy|Native|OCSF
|
||
|
|
SecAuditLogFormat JSON
|