You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ModSecurity sometimes doesn't fully log all of the rule IDs triggered within a request, this is annoying with false positives as you'll have to go through multiple tuning iterations just to resolve one false positive. This happens on both detection only mode and blocking mode. I haven't been able to find a reason behind what's causing this, but I do know how to trigger the issue.
But if you pay attention to the anomaly score, you'll see that there's a score of 28 but only 2 rules have been logged (both adding up to 8 points). I'll have to do a few more iterations before this false positive can be fully resolved.
Expected behavior
I should be able to see all of the rule IDs triggered the first time so I can fully resolve the false positive the first time. Something like this:
First of all, let me ask you: lines in H section under expected behavior part have different unique_id. There are 3 or 4 different id, but - as I know - in a transaction the unique id's must be the same.
Is this just a typo?
Btw there is known bug in libmodsecurity3: if a rule matches with multiple targets, then only one target will be logged. But the TX anomaly score is incremented "normally". May be you ran into this problem?
First of all, let me ask you: lines in H section under expected behavior part have different unique_id. There are 3 or 4 different id, but - as I know - in a transaction the unique id's must be the same.
Is this just a typo?
Yes, I was just showing how I approximately wanted the log output to look like.
Btw there is known bug in libmodsecurity3: if a rule matches with multiple targets, then only one target will be logged. But the TX anomaly score is incremented "normally". May be you ran into this problem?
Yeah I think that's the issue I'm encountering. Only 3 rules are being triggered in the example payload I used, 942432, 931130, and 920273 (I didn't notice this before). By the way, I couldn't find an open issue related to this in this repo or the nginx one.
Describe the bug
ModSecurity sometimes doesn't fully log all of the rule IDs triggered within a request, this is annoying with false positives as you'll have to go through multiple tuning iterations just to resolve one false positive. This happens on both detection only mode and blocking mode. I haven't been able to find a reason behind what's causing this, but I do know how to trigger the issue.
Logs and dumps
N/A See below
To Reproduce
I have some test payloads in my SOGo plugin that have this issue, run them against CRS using go-ftw 0.6.4
https://coreruleset.org/docs/development/testing/
I'll be using this test as an example: https://github.com/EsadCetiner/sogo-rule-exclusions-plugin/blob/b224054707ca0d0e7b73c9af4b1ae265970baf98/tests/regression/sogo-rule-exclusions-plugin/9520130.yaml#L8
As an end user, I get a false positive like this:
So then I create a rule exclusion thinking it'll fix the issue
Then later on I encounter the exact same false positive with the exact same payload:
Now I have to modify my previous rule exclusion to exclude the new rule IDs showing up
But if you pay attention to the anomaly score, you'll see that there's a score of 28 but only 2 rules have been logged (both adding up to 8 points). I'll have to do a few more iterations before this false positive can be fully resolved.
Expected behavior
I should be able to see all of the rule IDs triggered the first time so I can fully resolve the false positive the first time. Something like this:
Server:
Rule Set: CRSv4.5.0
Additional context
N/A
The text was updated successfully, but these errors were encountered: