3 Configuration

Now that you have ModSecurity installed and ready to run, we can proceed to the configuration. This section, with its many subsections, goes through every part of ModSecurity configuration, explicitly configuring every little detail:

In accordance with its philosophy, ModSecurity won’t do anything implicitly. It won’t even run unless you tell it to. There are three reasons for that:

The remainder of this section explains the proposed default configuration for ModSecurity. You can get a good overview of the default configuration simply by examining the configuration directives supported by ModSecurity, which are listed in Table 3.1 (with the exception of the logging directives, which are listed in several tables in Chapter 4, Logging).

Include /usr/local/modsecurity/etc/main.conf
Include /usr/local/modsecurity/etc/rules-first.conf
Include /usr/local/modsecurity/etc/rules.conf
Include /usr/local/modsecurity/etc/rules-last.conf

# Load Lua
LoadFile /usr/lib/x86_64-linux-gnu/liblua5.3.so
# Finally, load ModSecurity
LoadModule security2_module modules/mod_security2.so

<IfModule mod_security2.c>
    Include /usr/local/modsecurity/etc/modsecurity.conf
</IfModule>

# Enable ModSecurity, attaching it to every transaction.
SecRuleEngine DetectionOnly

# Allow ModSecurity to access request bodies. If you don't,
# ModSecurity won't be able to see any POST parameters,
# and that's generally not what you want.
SecRequestBodyAccess On

# Maximum request body size we will accept for buffering.
# If you support file uploads, then the value given on the
# first line has to be as large as the largest file you
# want to accept. The second value refers to the size of
# data, with files excluded. You want to keep that value
# as low as practical.
SecRequestBodyLimit 1310720
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When
# the multipart parser reaches this limit, it will start
# using your hard disk for storage. That is generally slow,
# but unavoidable.
SecRequestBodyInMemoryLimit 131072

# Allow ModSecurity to access response bodies. We leave
# this disabled because most deployments want to focus on
# the incoming threats, and leaving this off reduces
# memory consumption.
SecResponseBodyAccess Off

# Which response MIME types do you want to look at? You
# should adjust this configuration to catch documents
# but avoid static files (e.g., images and archives).
SecResponseBodyMimeType text/plain text/html

# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288

# What happens when we encounter a response body larger
# than the configured limit? By default, we process what
# we have and let the rest through.
SecResponseBodyLimitAction ProcessPartial

# The location where ModSecurity will store temporary files
# (e.g., when it needs to handle a multipart request
# body that's larger than the configured limit). If you don't
# specify a location here, your system's default will be used.
# It's recommended that you specify a location that's private.
SecTmpDir /usr/local/modsecurity/var/tmp/

# The location where ModSecurity will keep its data. This,
# too, needs to be a path that other users can't access.
# IMPORTANT: The path defined by SecDataDir must reside on
# on the same partition as the path defined by SecTmpDir.
SecDataDir /usr/local/modsecurity/var/data/

# The location where ModSecurity will store intercepted
# uploaded files. This location must be private to ModSecurity.
SecUploadDir /usr/local/modsecurity/var/upload/

# By default, do not intercept (nor store) uploaded files.
SecUploadKeepFiles Off

# Uploaded files are by default created with permissions that
# don't allow any other user to access them. You may need to
# relax that if you want to interface ModSecurity with an
# external program (e.g., an anti-virus program).
SecUploadFileMode 0600

# Limit the number of files we are willing
# to handle in any one request.
SecUploadFileLimit 32

# Debug log
SecDebugLog /usr/local/modsecurity/var/log/debug.log
SecDebugLogLevel 3

# Log only what's really necessary.
SecAuditEngine RelevantOnly

# Also log requests that cause a server error.
SecAuditLogRelevantStatus ^5

# Also log requests that cause an error.
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJKZ

# Use a single file for logging.
SecAuditLogType Serial
SecAuditLog /usr/local/modsecurity/var/log/audit.log

# Specify the path for concurrent audit logging.
SecAuditLogStorageDir /usr/local/modsecurity/var/audit/

SecDefaultAction "phase:1,log,auditlog,pass"

# 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_PROCESSOR_ERROR "!@eq 0" \
    "id:2000,phase:2,block,t:none,log,msg:'Failed to parse request body: ↩
%{REQBODY_PROCESSOR_ERROR_MSG}'"

# By default, be strict with what you 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. You are encouraged
# *not* to remove it altogether.
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:2001,phase:2,block,t:none,log,msg:'Multipart request body \
failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IF %{MULTIPART_INVALID_HEADER_FOLDING}, \
FE %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

[3] Rule 292d670 [id "941140"][file "/usr/local/modsecurity/etc/core-rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"][line "514"] - Execution error - PCRE limits exceeded (-8): (null).

SecRule TX:MSC_PCRE_LIMITS_EXCEEDED "@eq 1" \
    "id:9000,phase:5,pass,t:none,log,msg:'PCRE limits exceeded'"