Owasp-modsecurity-crs: Nginx + modsecurity - Only Warnings in log file

[vikas027]

Hey, I am noob in configuring ModSecurity. Following this tutorial, I have configured nginx v1.13.0 with ModSecuriy v2.9.1 and OWASP v3.0.2.

It seems to be configured well as I can see warnings for issues in ModSecurity Audit file, but I am not sure how to block threats. I have tried placing below line in /etc/nginx/modsec/modsecurity.conf and /etc/nginx/modsec/main.conf in vain.

SecDefaultAction "phase:2,log,auditlog,deny,status:403,tag:'SLA 24/7'"

Also, I do have SecRuleEngine On in my modsecurity.conf

Not sure, what I am missing. :(

[dune73]

Hi @vikas027, can you check the anomaly thresholds in the crs-setup.conf file? But your additional config line should block immediately, actually. It does sound as if your sourcing of files might be broken somehow. As if only certain files were sourced. Or sourced in the wrong order (?).

[vikas027]

Thanks @dune73 for the quick reply. Here are my files. Can you pls have a look and point out what I missing out.

[root@804c1576494d ~]# cat /etc/nginx/modsec/main.conf
# Include the recommended configuration
Include /etc/nginx/modsec/modsecurity.conf

# OWASP CRS v3 rules
Include /usr/local/owasp-modsecurity-crs/crs-setup.conf
Include /usr/local/owasp-modsecurity-crs/rules/*.conf
[root@804c1576494d ~]#

[root@804c1576494d ~]# cat /etc/nginx/conf.d/default.conf
server {
    listen       80 default_server;
    server_name  localhost;

    ModSecurityEnabled On;
    ModSecurityConfig /etc/nginx/modsec/main.conf;

    location / {
        root   /etc/nginx/html;
        index  index.html index.htm;
    }
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /etc/nginx/html;
    }
}
[root@804c1576494d ~]#

[root@804c1576494d ~]# ls /usr/local/owasp-modsecurity-crs/rules/*.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf      /usr/local/owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf                  /usr/local/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf     /usr/local/owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf  /usr/local/owasp-modsecurity-crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf               /usr/local/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf                   /usr/local/owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf              /usr/local/owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf                  /usr/local/owasp-modsecurity-crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf               /usr/local/owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf            /usr/local/owasp-modsecurity-crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf                 /usr/local/owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf          /usr/local/owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf          /usr/local/owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
/usr/local/owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
[root@804c1576494d ~]#

[dune73]

Does not look too bad. How about the thresholds in crs-setup.conf and what do you have in modsecurity.conf?

[vikas027]

I have all defaults here. Thanks in advance

[root@804c1576494d ~]# cat /usr/local/owasp-modsecurity-crs/crs-setup.conf | grep -v ^# | sed '/^$/d'
SecDefaultAction "phase:1,log,auditlog,pass"
SecDefaultAction "phase:2,log,auditlog,pass"
SecCollectionTimeout 600
SecAction \
 "id:900990,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_setup_version=302"
[root@804c1576494d ~]#

[root@804c1576494d ~]# cat /etc/nginx/modsec/modsecurity.conf | grep -v ^# | sed '/^$/d'
SecRuleEngine On
SecRequestBodyAccess On
SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
SecRule REQUEST_HEADERS:Content-Type "application/json" \
     "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyInMemoryLimit 131072
SecRequestBodyLimitAction Reject
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"
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}'"
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000
SecRule TX:/^MSC_/ "!@streq 0" \
        "id:'200005',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial
SecTmpDir /tmp/
SecDataDir /tmp/
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIJDEFHZ
SecAuditLogType Serial
SecAuditLog /var/log/nginx/modsec_audit.log
SecArgumentSeparator &
SecCookieFormat 0
SecUnicodeMapFile unicode.mapping 20127
SecStatusEngine On
[root@804c1576494d ~]#

[dune73]

Very odd. I do not see the bug. (But a few other issues: Better raise the PCRE limits to 100000 or so. The audot log parts should be ordered by alphabeth - a rarely known issue).

Next debugging step: Raise the debug level to 9, issue a request that should be blocked, then submit the complete error log of the request and the debug log passage that belongs to rule if 949110.

Sorry, this is such a hassle, but this must be a very interesting configuration bug.

[vikas027]

No, not a hassle at all. PFB log files.
modsec_audit.log.txt
modsec_debug.log.txt

Updated modsecurity.conf
modsecurity.conf.txt

[dune73]

OK. It looks like a bug. Thank you for your cooperation (and reporting this in the first place). Will be back.

[vikas027]

Thank you @dune73 . Feel free to update this thread should you need any further info/logs from me.

Cheers.

[dune73]

OK. Got it. Not a bug. But something I overlooked when I first browsed your config.

The INSTALL file says you need to load the rule files explicitly for Nginx because Nginx does not use alphabetical load order by itself. You used the Apache Include form *.conf which resulted in Nginx evaluating the Anomaly Score _before_ your rule triggered. (-> 949 file was loaded before the 942 file).

Load them as follows and you should be OK:

include owasp-modsecurity-crs/crs-setup.conf
include owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
include owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
include owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf
include owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
include owasp-modsecurity-crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
include owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
include owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
include owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
include owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
include owasp-modsecurity-crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
include owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
include owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
include owasp-modsecurity-crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
include owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
include owasp-modsecurity-crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
include owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

[vikas027]

Cool. Thanks, will try this tomorrow morning.

[vikas027]

Thanks @dune73, it worked like a charm. This was tricky as nginx official tutorial says to use wildcard (*), may be _nginx-plus_ loads rules in alphabetical order.

[dune73]

Great to hear it worked for you. Good luck with CRS!