0

I'm looking for some help on a problem encountered with a modsecurity configuration. we recently discovered that our modsecurity configuration didn't behave as we thought, specifically the modsecurity audit logs are generated for all calls, while we have set the nolog parameters in the SecRule entries.

So giving an example:

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus ^5

SecDefaultAction log,auditlog,deny,status:403,phase:2,t:lowercase,t:replaceNulls,t:compressWhitespace

SecRule REQUEST_FILENAME "^/application(/.*)?$" phase:2,chain,t:none,allow,nolog
SecRule REQUEST_METHOD (?i)^(GET|POST|HEAD)$

SecAction block

Expectation with requests matching this entry would be that no log entries would be made to either error log or audit log. Actual result is that indeed error log remains empty, but the audit log gets filled up.

In the audit log, we can confirm that the request is (in B block):

GET /application/that/does/something?and=has&some=parameters

We can also confirm that the SecRule referenced is the one matching, as if we remove it, the request is considered forbidden.

What we'd like to achieve: no entries in audit log for the matching rule

Thanks in advance for any help one might provide

Olivier
  • 2,571
  • 1
  • 17
  • 25

1 Answers1

1

Note: edited from the original answer after discussion below.

I originally thought this was due to nolog only referring to the error log, but this is not the case and my own testing has proven this, and the documentation shows this too as you correctly point out in comments below (https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#nolog).

So what you are doing should work. I am unable to repeat this issue, when I test on ModSecurity 2.9 and it correctly does not log to either log.

Rule Ids became mandatory in ModSecurity 2.7 and the fact you are not using them suggests you are on an older version so I wonder if this was a bug that was fixed since then? The change log (https://github.com/SpiderLabs/ModSecurity/blob/master/CHANGES) has a couple of potential fixes which might be related to this:

Fix in 04 Feb 2010 - 2.5.12:

Fixed nolog,auditlog/noauditlog/nolog controls for disruptive actions.

Fixed in 15 Nov 2006 - 2.0.4

Made "nolog" do what it is supposed to do - cause a rule match to not be logged. Also "nolog" now implies "noauditlog" but it's possible to follow "nolog" with "auditlog" and have the match not logged to the error log but logged to the auditlog. (Not something that strikes me as useful but it's possible.)

So if you are running a version without this, this might be the cause of what you are seeing.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • HI BazzaDP, thanks for your reply. I had omitted the whole configuration, but indeed have the following entries present: `SecAuditEngine RelevantOnly` `SecAuditLogRelevantStatus ^5` but even with this, all entries seem to be logged. – Olivier Sep 04 '15 at 11:52
  • Also, following your comment about _nolog_, from the same source you provided: _nolog_ _Description: Prevents rule matches from appearing in both the error and audit logs._ – Olivier Sep 04 '15 at 12:08
  • Interesting but I still think your DefaultAction including auditlog will override those. There's no need for that to be in there. – Barry Pollard Sep 04 '15 at 12:46
  • Actually just tested this and I am not experiencing the same as you. When I add nolog, even with a SecDefaultAction containing audiotlog it's not logging. The SecDefaultAction is not used on allow. Hmmm... Can you add a ruleId to 100% confirm it's this rule? the fact you don't need a rule id suggests you are on an old version of ModSecurity anyway since this became mandatory in v2.7 so not sure if this is an old bug that's now fix? – Barry Pollard Sep 04 '15 at 13:00
  • Changes are here: https://github.com/SpiderLabs/ModSecurity/blob/master/CHANGES. Would be helpful to know what version you are running as looks like a few fixes in there which might explain your scenario. – Barry Pollard Sep 04 '15 at 18:30
  • Thanks @BazzaDP, will check the information provided, and see the details of the modsecurity version currently in place. I usually try to avoid assuming a bug in the tool till I have exhausted all other possibilities, which you have helped me do with your tests. – Olivier Sep 07 '15 at 10:46
  • No problems. Might not be that but at a lose to explain otherwise. I have updated my answer (since it was wrong!) in case anyone else stumbles on this in future. – Barry Pollard Sep 07 '15 at 16:51