Home / server / Questions / 632162
Accepted
user2845840
Asked: 2014-09-30 09:33:10 +0800 CST

Fine-grained control over mod_security logging

  • 772

I installed mod_security2 on several dozen servers (each with several dozen VHosts) and don't have the time to configure it for every VHost. In the default configuration, it produces copious amounts of false positives in log files, so I chose to let it run in DetectionOnly-mode (it doesn't block anything, but I still get detailed logs for most hacking attempts) for all but a select few VHosts.

I was happy with this setup until I discovered that log files on some servers grew to several Gigabytes in less than 3 weeks. I decided to switch off logging for the handful of VHosts that produced the lion's share of those log entries. There are several different ways to do this, I eventually settled on making new rules with very specific triggers that all have "nolog,phase:1,t:none,ctl:secAuditEngine=Off" as action. This succeeds insofar as the amount of entries in the audit log is reduced to manageable levels.

But I still get Gigabytes of logs because I can't seem to prevent mod_security2 from writing to the error log. I tried SecDebugLogLevel 0 since it's the only configuration directive concerned with error logging (that I was able to find, anyway), but to no avail. The only thing that seems to help is SecRuleEngine Off, which defeats the purpose of installing mod_security2 in the first place.

Am I missing something? No matter what I try, it appears as if I can only control the amount of logging to the audit log, while having no control over the amount of logging to the error log.

logging

1 Answers

  1. Best Answer

    After extensive trial & error I still don't have a perfectly satisfying solution, but at least a workaround. Adding SecRemoveRuleById inside <Directory>-Blocks prevents entries in the error log - but it does not seem to work for all rules, only for some of them (for example, deactivating rule id 960010 works, but 960243 & 960257 do not). This will of course only work if Apache was able to determine the directory path - for many malformed request and requests missing crucial information, Apache does not know the path.

    Deactivating rules by defining new rules of the form SecRule SERVER_NAME "^domain.tld$" "nolog,phase:1,t:none,id:100,ctl:ruleRemoveById=960010" works as well, but they have to be defined before all other rules (and therefore before inclusion of the CRS-rules) to reliably deactivate existing rules. As far as I know mod_security applies rules in the order they are defined, so deactivating a phase:1-rule after it has fired will obviously not prevent log entries that already happened (Deactivating a phase:2-rule in phase 1 seems to always work, which is to be expected). It's somewhat inconvenient that I can't influence the order of application without changing the order of definition.

    Of course, the solution I was really looking for is a deactivation of error log entries in general. It requires far too effort much to find the frequently firing rule IDs for every VHost and deactivate them individually. 10000 VHosts á 10 minutes of configuration -> Almost a year to make it work on every VHost.

    • 0