ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
`
But as you see in the logs, the arguments do not get sanitized. If I move them into a query param, everything works as expected, but that's not the use case I need this rule for.
Use the most commonly used application/x-www-form-urlencoded parameter
separator. There's probably only one application somewhere that uses
something else so don't expect to change this value.
#
SecArgumentSeparator &
Settle on version 0 (zero) cookies, as that is what most applications
use. Using an incorrect cookie version may open your installation to
evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0
Specify your Unicode Code Point.
This mapping is used by the t:urlDecodeUni transformation function
to properly map encoded data to your language. Properly setting
these directives helps to reduce false positives and negatives.
#
SecUnicodeMapFile unicode.mapping 20127
Improve the quality of ModSecurity by sharing information about your
current ModSecurity version and dependencies versions.
The following information will be shared: ModSecurity version,
Web Server version, APR version, PCRE version, Lua version, Libxml2
version, Anonymous unique id for host.
SecStatusEngine On
`
/etc/apache2/mods-enabled/security2.conf
`
# Default Debian dir for modsecurity's persistent data
SecDataDir /var/cache/modsecurity
# Include all the *.conf files in /etc/modsecurity.
# Keeping your local configuration in that directory
# will allow for an easy upgrade of THIS file and
# make your life easier
IncludeOptional /etc/modsecurity/*.conf
# Include OWASP ModSecurity CRS rules if installed
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/*.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/crs-setup.conf
IncludeOptional /etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/*.conf
SanitiseArg does not work in RequestBody
Taken right from the docs: https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#user-content-sanitiseArg
I want to sanitiese two password fields in a POST body, but the Rule is not working. I am on Ubuntu 22.04.03 LTS for testing and Apache 2.4.52
I have defined five rules (for each phase for testing, although only phase 2 should be relevant) in my custom rules:
/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf
`
SecAction "auditlog,phase:1,id:131,sanitiseArg:password1,sanitiseArg:password2
SecAction "auditlog,phase:2,id:132,sanitiseArg:password1,sanitiseArg:password2
SecAction "auditlog,phase:3,id:133,sanitiseArg:password1,sanitiseArg:password2
SecAction "auditlog,phase:4,id:134,sanitiseArg:password1,sanitiseArg:password2
SecAction "auditlog,phase:5,id:135,sanitiseArg:password1,sanitiseArg:password2
` But as you see in the logs, the arguments do not get sanitized. If I move them into a query param, everything works as expected, but that's not the use case I need this rule for.
modsec_debug.log
Logs and dumps
Output of debug log:
see attached file :)
Audit log `--bdaba279-A--
[21/Feb/2024:11:11:31.019241 +0100] ZdXMUqJvB0RHGjLsW7sioAAAAEE 127.0.0.1 60516 127.0.0.1 80
--bdaba279-B--
POST /test HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Content-Length: 46
Origin: http://localhost
Pragma: no-cache
Cache-Control: no-cache
--bdaba279-C--
password1=xyz&password2=test&inj=1' or 1=1;--
--bdaba279-F--
HTTP/1.1 404 Not Found
Content-Length: 271
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
--bdaba279-E--
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
Not Found
The requested URL was not found on this server.
Apache/2.4.52 (Ubuntu) Server at localhost Port 80
--bdaba279-H--
Message: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "1"] [id "131"]
Message: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "2"] [id "132"]
Message: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "702"] [id "920340"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"]
Message: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "3"] [id "133"]
Message: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "4"] [id "134"]
Message: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "5"] [id "135"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "1"] [id "131"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "2"] [id "132"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "702"] [id "920340"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "3"] [id "133"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "4"] [id "134"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "5"] [id "135"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
Stopwatch: 1708510290984493 34783 (- - -)
Stopwatch2: 1708510290984493 34783; combined=24384, p1=5247, p2=17230, p3=306, p4=1153, p5=447, sr=77, sw=1, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.5 (http://www.modsecurity.org/); OWASP_CRS/3.3.0.
Server: Apache/2.4.52 (Ubuntu)
Engine-Mode: "DETECTION_ONLY"
--bdaba279-Z--
`
[Wed Feb 21 11:11:18.358276 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: APR compiled version="1.7.0"; loaded version="1.7.0"
[Wed Feb 21 11:11:18.358280 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: PCRE compiled version="8.39 "; loaded version="8.39 2016-06-14"
[Wed Feb 21 11:11:18.358282 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: LUA compiled version="Lua 5.1"
[Wed Feb 21 11:11:18.358283 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: YAJL compiled version="2.1.0"
[Wed Feb 21 11:11:18.358285 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: LIBXML compiled version="2.9.12"
[Wed Feb 21 11:11:18.358327 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: StatusEngine call: "2.9.5,Apache/2.4.52 (Ubuntu),1.7.0/1.7.0,8.39/8.39 2016-06-14,Lua 5.1,2.9.12,b53b7f0c516afb11983b2f31ed836b58d9aa16c9"
[Wed Feb 21 11:11:18.418102 2024] [:notice] [pid 278101:tid 140491626837888] ModSecurity: StatusEngine call failed. Query: GIXDSLRVFRAXAYLDNBSS6MROGQXDKMRA.FBKWE5LOOR2SSLBRFY3S4MBPGEXDOLRQ.FQ4C4MZZF44C4MZZEAZDAMJWFUYDMLJR.GQWEY5LBEA2S4MJMGIXDSLRRGIWGENJT.MI3WMMDDGUYTMYLGMIYTCOJYGNRDEZRT.GFSWIOBTGZRDKODEHFQWCMJWMM4Q.1708510278.status.modsecurity.org
[Wed Feb 21 11:11:18.483609 2024] [mpm_event:notice] [pid 278102:tid 140491626837888] AH00489: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Feb 21 11:11:18.483645 2024] [core:notice] [pid 278102:tid 140491626837888] AH00094: Command line: '/usr/sbin/apache2'
[Wed Feb 21 11:11:26.266928 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "1"] [id "131"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:26.272942 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "2"] [id "132"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:26.275733 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "702"] [id "920340"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:26.281850 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "3"] [id "133"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:26.282177 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "4"] [id "134"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:26.283330 2024] [:error] [pid 278104:tid 140491588085312] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "5"] [id "135"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMTqJvB0RHGjLsW7sinwAAAEA"]
[Wed Feb 21 11:11:30.987024 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "1"] [id "131"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
[Wed Feb 21 11:11:30.992166 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "2"] [id "132"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
[Wed Feb 21 11:11:30.994795 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Operator EQ matched 0 at REQUEST_HEADERS. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "702"] [id "920340"] [msg "Request Containing Content, but Missing Content-Type header"] [severity "NOTICE"] [ver "OWASP_CRS/3.3.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/210/272"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
[Wed Feb 21 11:11:31.009324 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "3"] [id "133"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
[Wed Feb 21 11:11:31.009643 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "4"] [id "134"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
[Wed Feb 21 11:11:31.018830 2024] [:error] [pid 278104:tid 140491579692608] [client 127.0.0.1:60516] [client 127.0.0.1] ModSecurity: Warning. Unconditional match in SecAction. [file "/etc/apache2/modsecurity-crs/coreruleset-3.3.0/rules/custom/waf_adaption.conf"] [line "5"] [id "135"] [hostname "localhost"] [uri "/test"] [unique_id "ZdXMUqJvB0RHGjLsW7sioAAAAEE"]
`
Notice: Be carefully to not leak any confidential information.
To Reproduce
Steps to reproduce the behavior:
A curl command line that mimics the original request and reproduces the problem. Or a ModSecurity v3 test case.
[e.g: curl "modsec-full/ca/..\..\..\..\..\..\/\etc/\passwd" or issue-394.json]
Expected behavior
A clear and concise description of what you expected to happen.
Server (please complete the following information):
Rule Set (please complete the following information):
Additional context
/etc/modsecurity/modsecurity.conf
`# -- Rule engine initialization ----------------------------------------------
Enable ModSecurity, attaching it to every transaction. Use detection
only to start with, because that minimises the chances of post-installation
disruption.
#
SecRuleEngine DetectionOnly
-- Request body handling ---------------------------------------------------
Allow ModSecurity to access request bodies. If you don't, ModSecurity
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" \
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" \
Sample rule to enable JSON request body parser for more subtypes.
Uncomment or adapt this rule if you want to engage the JSON
Processor for "+json" subtypes
#
SecRule REQUEST_HEADERS:Content-Type "^application/.+[+]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 then the value given on the first line has to be as large
as the largest file you are willing 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 13107200
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 slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072
What do 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 ModSecurity.
#
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. You are encouraged
not to remove it altogether.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:400, \
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}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
Did we see anything that might be a boundary?
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
PCRE Tuning
We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 100000
SecPcreMatchLimitRecursion 100000
Some internal errors will set flags in TX and we will need to look for these.
All of these are prefixed with "MSC_". The following flags currently exist:
#
MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
SecRule TX:/^MSC_/ "!@streq 0" \
-- Response body handling --------------------------------------------------
Allow ModSecurity to access response bodies.
You should have this directive enabled in order to identify errors
and data leakage issues.
Do keep in mind that enabling this directive does increases both
memory consumption and response latency.
#
SecResponseBodyAccess On
Which response MIME types do you want to inspect? You should adjust the
configuration below to catch documents but avoid static files
(e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml
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.
That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial
-- Filesystem configuration ------------------------------------------------
The location where ModSecurity stores temporary files (for example, when
it needs to handle a file upload that is larger than the configured limit).
This default setting is chosen due to all systems have /tmp available however,
this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir /tmp/
The location where ModSecurity will keep its persistent data. This default setting
is chosen due to all systems have /tmp available however, it
too should be updated to a place that other users can't access.
#
SecDataDir /tmp/
-- File uploads handling configuration -------------------------------------
The location where ModSecurity stores intercepted uploaded files. This
location must be private to ModSecurity. You don't want other users on
the server to access the files, do you?
#
SecUploadDir /opt/modsecurity/var/upload/
By default, only keep the files that were determined to be unusual
in some way (by an external inspection script). For this to work you
will also need at least one file inspection rule.
#
SecUploadKeepFiles RelevantOnly
Uploaded files are by default created with permissions that do not allow
any other user to access them. You may need to relax that if you want to
interface ModSecurity to an external program (e.g., an anti-virus).
#
SecUploadFileMode 0600
-- Debug log configuration -------------------------------------------------
The default debug log configuration is to duplicate the error, warning
and notice messages from the error log.
#
SecDebugLog /var/log/apache2/modsec_debug.log
SecDebugLogLevel 9
- 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(?!04))"
Log everything we know about a transaction.
SecAuditLogParts ABDEFHIJZ
Use a single file for logging. This is much easier to look at, but
assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog /var/log/apache2/modsec_audit.log
Specify the path for concurrent audit logging.
SecAuditLogStorageDir /opt/modsecurity/var/audit/
-- Miscellaneous -----------------------------------------------------------
Use the most commonly used application/x-www-form-urlencoded parameter
separator. There's probably only one application somewhere that uses
something else so don't expect to change this value.
#
SecArgumentSeparator &
Settle on version 0 (zero) cookies, as that is what most applications
use. Using an incorrect cookie version may open your installation to
evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0
Specify your Unicode Code Point.
This mapping is used by the t:urlDecodeUni transformation function
to properly map encoded data to your language. Properly setting
these directives helps to reduce false positives and negatives.
#
SecUnicodeMapFile unicode.mapping 20127
Improve the quality of ModSecurity by sharing information about your
current ModSecurity version and dependencies versions.
The following information will be shared: ModSecurity version,
Web Server version, APR version, PCRE version, Lua version, Libxml2
version, Anonymous unique id for host.
SecStatusEngine On
`
/etc/apache2/mods-enabled/security2.conf
`
`