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
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.