Skip to content

Cannot suppress logging to Apache error log #2302

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
azurit opened this issue Apr 30, 2020 · 5 comments
Closed

Cannot suppress logging to Apache error log #2302

azurit opened this issue Apr 30, 2020 · 5 comments
Assignees
Labels
2.x Related to ModSecurity version 2.x

Comments

@azurit
Copy link

azurit commented Apr 30, 2020

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
@zimmerle zimmerle added the 2.x Related to ModSecurity version 2.x label Apr 30, 2020
@martinhsv
Copy link
Contributor

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
Copy link
Author

azurit commented Apr 30, 2020

@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
Copy link
Contributor

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
Copy link
Author

azurit commented Apr 30, 2020

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

@martinhsv
Copy link
Contributor

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

@martinhsv martinhsv self-assigned this Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2.x Related to ModSecurity version 2.x
Projects
None yet
Development

No branches or pull requests

3 participants