ModSecurity not putting some transactions to audit log

[PeterP55P]

Describe the bug

We are facing a problem when in certain cases ModSecurity is not tracking the blocking in the audit log despite we have set it as a default action and the rule is not having any logging property set. In the error log, we can see only the rule which was triggered due to the anomaly score has been reached but nothing about the rules which actually counted the score. In some other cases, this information is visible.

In modsecurity.conf we have logging of rules enabled

SecAuditLogParts ABCIJDFHKZ

In crs-setup.conf we have default logging set to capture everything in both error and audit log.

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

We have also tried other combinations like using this setup

SecDefaultAction "phase:2,pass, nolog,auditlog"

But nothing helped.

Logs and dumps

The only thing we can see in the log is this part from the error log and when we need more details we need to enable debug and redo the action. In the example below I have changed the IP addresses for security reasons.

2022/03/09 08:32:25 [error] 1149#1149: *13832 [client 1.1.1.1] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator Ge' with parameter 5' against variable TX:ANOMALY_SCORE' (Value: 15' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "139"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 15)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.4.0-dev"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "10.1.0.1"] [uri "/favicon.ico"] [unique_id "1646811145"] [ref ""], client: 1.1.1.1, server: example.com, request: "GET /favicon.ico HTTP/1.1", host: "example.com", referrer: "http://example.com/?q=%22%3E%3Cscript%3Ealert(1)%3C/script%3E%27"

We need to find a way how to make sure every attempt will be logged into the audit log.

Thanks in advance for any help.

Peter

To Reproduce

Steps to reproduce the behavior:

We just ran the URL below to trigger some WAF rules.

http://example.com/?q=%22%3E%3Cscript%3Ealert(1)%3C/script%3E%27

Expected behavior

We expect that every threat will be captured in audit log which is not happening at this time. Only some are captured while many are not. We can see only rule 949110 in the log which is the very last one and missing those others which counted the anomaly score.

Server (please complete the following information):

• ModSecurity version (and connector): [ModSecurity v3.0.6 ]
• WebServer: [nginx-1.20.2]
• OS (and distro): [Oracle Linux 7.9]

Rule Set (please complete the following information):

• Running any public or commercial rule set? [e.g. SpiderLabs public rules]
• What is the version number? [CRS v3.4.0dev]

[willyamcts]

@PeterP55P check directive "SecAuditLog" in your modsecurity.conf, in file this directive must to have all content from match rules.

In logger error normally show only wich generate action the lock.

[PeterP55P]

@PeterP55P check directive "SecAuditLog" in your modsecurity.conf, in file this directive must to have all content from match rules.

In logger error normally show only wich generate action the lock.

I'm not really sure what do you mean. The directive "SecAuditLog" points to the path of the audit log file which is set and some transactions are being captured there. The problem is that many others are not captured in this file.

[martinhsv]

Hello @PeterP55P,

To summarize your issue:

• you get entries in the audit log file for some transactions
• for some other transactions, you get nothing in the audit log file, but you still get an entry in nginx's error.log file (including even the triggering rule number)

One way that could happen is if you have set SecAuditEngine Off for some transactions but not for others. This could happen if you are using different ModSecurity configuration directives for different nginx blocks (e.g. different location blocks).

A related way to see this effect is you are using the ctl:auditEngine action (it is not available in the tagged version of v3.0.6, but it is in v3/master.

Beyond that, I would suggest seeing what is happening by checking ModSecurity's DebugLog (level 9).

[liudongmiao]

@PeterP55P do you use ModSecurity-nginx with error_page?
If so, please check owasp-modsecurity/ModSecurity-nginx#273.

[PeterP55P]

@liudongmiao very good point. thanks for this finding. this is exactly our problem. after commenting out the error_page directive the issue is gone.

[byrneo]

Hi - i have this exact problem also. In my case, I'm using "OWASP_CRS/3.3.2" with NGINX Ingress controller Release: v1.2.0 nginx version: nginx/1.19.10 on EKS.

My config is otherwise the same as @PeterP55P except i have not configured any error_page. Everything else is default except for what I set on my ingress:

nginx.ingress.kubernetes.io/modsecurity-snippet: |
      SecRuleEngine On
      SecDebugLog /var/log/nginx/error.log
      SecAuditLogType Serial
      SecAuditLog /var/log/nginx/error.log

When I trigger a rule, I can indeed see a log indicating the error but showing only rule [id "949110"] with no audit details:

2022/05/31 16:14:10 [error] 2188#2188: *189096 [client _REDACTED__] ModSecurity: Access denied with code 403 (phase 2). Matched "Operator Ge' with parameter 5' against variable TX:ANOMALY_SCORE' (Value: 10' ) [file "/etc/nginx/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "80"] [id "949110"] [rev ""] [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"] [data ""] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-generic"] [hostname "__REDACTED__"] [uri "/"] [unique_id "1654013650"] [ref ""], client: __REDACTED__ server: echo-server2.dev.__REDACTED__.com, request: "GET /?q=\'1%20OR%201=1 HTTP/2.0", host: "echo-server2.dev.__REDACTED__.com

Any help greatly appreciated!

[martinhsv]

Hello @byrneo ,

I believe what you are describing is quite different from what is otherwise discussed here.

There are three different log files relevant to ModSecurity: (1) the web server's own 'error.log' file, (2) ModSecurity's own audit log file and (3) ModSecurity's debug log.

It's not usual (and probably not advisable) to combine these in a single physical file, as your configuration snippet suggests you have done.

If only nginx's own web server logging goes to /var/log/nginx/error.log, and you are using CRS's anomaly scoring mode, then, yes under certain configurations, you might only see the rule that actually resulted in the 'deny' action (949110 in your case). However, you should able to get additional rule information to show up there by adjusting the setting for 'error_log' (this may be in your nginx.conf file) to be 'info'.

[byrneo]

Thanks for the feedback @martinhsv ! Reason for the aggregated logs is because I have log monitoring already in place on the cluster and all logs that are sent to stdout or stderr will be collected .

So, within the ingress-nginx pods, there are already default symlinks such as:

lrwxrwxrwx    1 www-data www-data        11 Apr 20 18:41 access.log -> /dev/stdout
lrwxrwxrwx    1 www-data www-data        11 Apr 20 18:41 error.log -> /dev/stderr

and i've also tried setting SecAuditLog /dev/stdout to no avail.

That said, I think you are right: my issue is likely different as i have just noticed that many log files do indeed always appear in /var/log/audit/ - so i guess i just need to find a way to collect them and print to stdout/stderr via a sidecar perhaps.

Thanks for the pointers