我在几十台服务器上安装了mod_security2（每台服务器都有几十个 VHost），没有时间为每个 VHost 配置它。在默认配置中，它会在日志文件中产生大量误报，所以我选择让它在DetectionOnly-mode 下运行（它不会阻止任何东西，但我仍然可以获得大多数黑客尝试的详细日志），但只有一个选择几个虚拟主机。
我对这个设置很满意，直到我发现一些服务器上的日志文件在不到 3 周的时间内增长到了几个 GB。我决定关闭生成大部分日志条目的少数 VHost 的日志记录。有几种不同的方法可以做到这一点，我最终决定使用非常具体的触发器制定新规则，这些触发器都有"nolog,phase:1,t:none,ctl:secAuditEngine=Off"作为动作。只要审计日志中的条目数量减少到可管理的水平，就可以成功。
但我仍然得到千兆字节的日志，因为我似乎无法阻止 mod_security2 写入错误日志。我尝试过SecDebugLogLevel 0，因为它是唯一与错误日志有关的配置指令（无论如何我都能找到），但无济于事。唯一似乎有帮助的是SecRuleEngine Off，它首先破坏了安装 mod_security2 的目的。
我错过了什么吗？无论我尝试什么，似乎我只能控制记录到审计日志的数量，而无法控制记录到错误日志的数量。
经过大量的试验和错误后，我仍然没有一个完全令人满意的解决方案，但至少有一个解决方法。添加
SecRemoveRuleById内部<Directory>-Blocks 可防止错误日志中的条目 - 但它似乎不适用于所有规则，仅适用于其中一些规则（例如，停用规则 id 960010 有效，但 960243 和 960257 无效）。当然，这只有在 Apache 能够确定目录路径时才有效——对于许多格式错误的请求和缺少关键信息的请求，Apache 不知道路径。通过定义表单的新规则来停用规则
SecRule SERVER_NAME "^domain.tld$" "nolog,phase:1,t:none,id:100,ctl:ruleRemoveById=960010"也可以，但是必须在所有其他规则之前定义它们（因此在包含 CRS 规则之前）才能可靠地停用现有规则。据我所知 mod_security 按定义的顺序应用规则，因此在触发后停用 phase:1-rule 显然不会阻止已经发生的日志条目（在阶段 1 中停用 phase:2-rule 似乎总是工作，这是意料之中的）。在不改变定义顺序的情况下，我无法影响应用程序的顺序，这有点不方便。当然，我真正在寻找的解决方案是停用错误日志条目。为每个 VHost 找到频繁触发的规则 ID 并单独停用它们需要花费太多精力。10000 个 VHosts á 10 分钟的配置 -> 几乎一年的时间让它在每个 VHost 上工作。