Closed molu8bits closed 2 years ago
Looks like duplicate of #2000.
@molu8bits could you please try the PR from #2048?
I tried it already before raising the issue. PR #2048 adds a message when block action is given. But that doesn't solve the issue.
Please take a look at simplest case
Rule:
SecRule REQUEST_FILENAME "/phpmyadmin" "id:20000,phase:1,pass,log,t:lowercase,t:normalisePath,msg:'Blocking access to %{MATCHED_VAR}.',tag:'Blacklist Rules'"
The same url has been tested for Modsecurity2 and Modsecurity3:
curl -XGET http://localhost/phpmyadmin?ala
For this request compare section H for both version of Modsecurity:
modsec_audit.log from Modsecurity 2.9.2
--d9525e14-H-- Message: Access denied with code 403 (phase 1). Pattern match "/phpmyadmin" at REQUEST_FILENAME. [file "/etc/httpd/conf.d/mod_security.conf"] [line "94"] [id "10000"] [msg "Blocking access to /phpmyadmin."] [tag "Blacklist Rules"] Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 1). Pattern match "/phpmyadmin" at REQUEST_FILENAME. [file "/etc/httpd/conf.d/mod_security.conf"] [line "94"] [id "10000"] [msg "Blocking access to /phpmyadmin."] [tag "Blacklist Rules"] [hostname "localhost"] [uri "/phpmyadmin"] [unique_id "XJn28xwFH9hnuefyVqX3bAAAAAM"] Action: Intercepted (phase 1) Stopwatch: 1553594099438286 1792 (- - -) Stopwatch2: 1553594099438286 1792; combined=645, p1=381, p2=0, p3=0, p4=0, p5=264, sr=0, sw=0, l=0, gc=0 Response-Body-Transformed: Dechunked Producer: ModSecurity for Apache/2.9.2 (http://www.modsecurity.org/); OWASP_CRS/3.0.2. Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips mod_klwi/2.4 Engine-Mode: "ENABLED"
And compare with the line from Modsecurity 3:
--nGeBHQmm---H-- ModSecurity: Access denied with code 403 (phase 1). Matched "Operator Rx' with parameter /phpmyadmin' against variable REQUEST_FILENAME' (Value: /phpmyadmin' ) [file "/etc/nginx/modsec/main.conf"] [line "9"] [id "10000"] [rev ""] [msg "Blocking access to /phpmyadmin."] [data ""] [severity "0"] [ver ""] [maturity "0"] [accuracy "0"] [tag "Blacklist Rules"] [hostname "127.0.0.1"] [uri "/phpmyadmin"] [unique_id "155354533934.807582"] [ref "o0,11v4,11t:lowercase,t:normalisePath"]
For some cases when there is no rules with block/deny action defined e.g.
curl -XOPTIONS http://localhost/
Modsecurity3 produces a log entry but not inform why:
---0F9RDt9Y---A-- [26/Mar/2019:11:27:21 +0100] 155359604188.762315 127.0.0.1 49500 127.0.0.1 80 ---0F9RDt9Y---B-- OPTIONS / HTTP/1.1 User-Agent: curl/7.29.0 Host: localhost Accept: /
---0F9RDt9Y---D--
---0F9RDt9Y---F-- HTTP/1.1 405 Server: nginx/1.12.2 Date: Tue, 26 Mar 2019 10:27:21 GMT Content-Length: 173 Content-Type: text/html Connection: keep-alive
---0F9RDt9Y---H--
---0F9RDt9Y---I--
---0F9RDt9Y---J--
---0F9RDt9Y---K--
---0F9RDt9Y---Z--
btw. it can be connected with #2054
@molu8bits ,
Is this still a problem?
Regarding the example at the end of your last posting: note that empty 'part H' output is consistent with ModSecurity not having had any rules triggered at all. In this case perhaps output was written to the audit log because you were using 'SecAuditEngine RelevantOnly' with SecAuditLogRelevantStatus? I.e. in this case the web server itself generated the 405 response code, and ModSecurity merely logged it because you told it to?
I don't use modsecurity currently, Anyway some time ago I was using nginx-ingress with built in modsecurity and it worked fine. All log parts were in place. Probably problem was solved in the meantime by some other patch.
@molu8bits ,
Thanks for the update.
Describe the bug
SecAuditLogParts configuration works only for A,F and only partially for H. Partially - means that if hits the rule with drop/deny action that one line message is visible in section H. But even then it produces only one message without complete information which rules were hit.
Logs and dumps
Output of:
modsec_audit.log example entry for default config:
modsec_audit.log one entry for a rule with "deny" action:
Notice: Be carefully to not leak any confidential information.
To Reproduce Configuration was tested with following sets of software and always behaves the same way:
Testing rules for blocking action: SecRule REQUEST_FILENAME "/phpmyadmin" "id:10000,phase:1,drop,log,t:lowercase,t:normalisePath,msg:'Blocking access to %{MATCHED_VAR}.',tag:'Blacklist Rules'" SecRule REQUEST_FILENAME "/phpmyadmin" "id:10000,phase:1,deny,log,t:lowercase,t:normalisePath,msg:'Blocking access to %{MATCHED_VAR}.',tag:'Blacklist Rules'"
A curl command line that mimics the original request and reproduces the problem. Or a ModSecurity v3 test case:
curl -XGET http://localhost/phpmyadmin?ala
Expected behavior Expected behaviour is to get full modsec_audit.log entry for all cases - like for modsecurity2.x Example modsec_audit.log entry with multiple messages in Section H for case where the request wasn't blocked by modsecurity:
Server : Different configuration were tested:
Rule Set (please complete the following information): Tested with default modsecurity.conf only and some custom rules and with public CRS. No difference.
Additional context
JSON logging also is incomplete. Setting SecAuditLogType from Serial to Concurrent doesn't change anything. Single files in such case don't have all the log parts.