Cannot suppress logging to Apache error log

[azurit]

Describe the bug

mod_security is logging messages with level 'error' into apache error log even with this setting:
LogLevel warn security2:crit

The problem is, probably, because mod_security is marking messages as if they come from Apache itself. See the log line below, there should be [security2:error] instead of [:error].

We need to suppress these messages because they are confusing to our users.

Logs and dumps

[Thu Apr 30 08:27:15.510284 2020] [:error] [pid 25449] [client 1.1.1.1:55988] [client 1.1.1.1] ModSecurity: Warning. Pattern match ...

Server (please complete the following information):

• ModSecurity version (and connector): mod_security 2.9.3
• WebServer: Apache 2.4
• OS (and distro): Debian linux, 64bit

[martinhsv]

Hi @azurit ,

Have you considered using 'nolog'? You can continue logging to audit log but suppress logging to Apache's error.log if the rule's actions include:

nolog,auditlog

[azurit]

@martinhsv, I already solved it like you suggested but that doesn't solve problem i described. To fully suppress logging i had to modify rules in CRS ruleset and now i had to manage all these changes with every update of CRS.

[martinhsv]

Hi @azurit ,

You shouldn't have to modify every CRS rule. As shipped, 942100 (for example) does not specify 'log' as one of its actions. Instead, it inherits certain actions from SecDefaultAction in crs-setup.conf.

If you change the 'log,auditlog' portion of SecDefaultAction to instead have 'nolog,auditlog', then 942100 (and other similarly-structured rules) will no longer log to Apache's error.log.

[azurit]

@martinhsv I had to modify rules 949110 and 980130, setting SecDefaultAction has no effect on them.

[martinhsv]

@azurit ,

Sure. Unlike most CRS rules, those two do indeed specifically have 'log' as part of their actions -- i.e the individual rules explicitly override the setting in SecDefaultAction. Setting up those two rules that way will have been a decision by the CRS rule maintainers.

I'd summarize by suggesting that, as the ModSecurity engine stands, using 'nolog' (in whatever combination of SecDefaultAction and individual rules is effective for you) is the recommended way to suppress the ModSecurity engine's logging to Apaches's error.log

As to the other potential method that you mentioned at the outset that you expected would work (using security2:crit in LogLevel): you are likely correct that it doesn't work because the log lines aren't being written with the module name before the ':error'. That aspect would be a duplicate of the open ticket #1135

I'll go ahead and close this one on that basis.