我刚开始使用owasp规则，得到了大量的误报。描述字段中有人写过的示例：
"我们明天要为我们的工作平台选择一些用户。
这被检测为 sql 注入攻击 (id 950007(。其实不然。这是有效的评论。我有很多这样的误报。
首先，我设置了 SecRuleEngine DetectionOnly 来收集信息。然后我开始使用"SecRuleUpdateTargetById 950007！ARGS：desc"或"SecRuleRemoveById 950007"，我已经为此花了一天时间。modsec_audit.log是 alreay> 100MB 的大小。
我对你的经验很感兴趣，你微调了多长时间(大致(。打开它后，您是否仍然会收到误报，您如何设法按时添加白名单(您是否每天分析日志(？
我需要这些信息来告诉老板对这项任务的估计。看来会持续很长时间。
这完全取决于您的网站、技术和测试基础设施。默认情况下，OWASP CRS非常嘈杂，确实需要大量调整。顺便说一下，这个版本正在进行一些工作，下一个版本可能具有正常和偏执模式，希望能减少误报。
举个例子，我照顾一个大小合理的网站，其中包含静态页面和许多用各种技术编写的应用程序(遗留代码 - 咕噜！(和相当数量的访问者。
幸运的是，我在预生产环境中进行了夜间回归运行，覆盖范围很好，所以这是我的第一个停靠港。经过一些初步测试后，我在那里发布了 ModSecurity，在 DetectionOnly 模式下，并在一个月内对其进行了调整，直到我解决了所有问题并愿意转向 prod。当然，这不是一个整整一个月的连续工作，但在大多数日子里，需要 30-60 分钟来检查前几晚的跑步，适当地调整规则并为下一晚的跑步做好准备(该死的饼干和他们的随机字符串！
接下来，我在生产中做了同样的事情，几乎立即遇到了像您一样的自由文本反馈字段的问题(当然，我在回归运行中没有看到其中的大部分(。这需要大量的调整(必须关闭这些字段的大量SQL注入规则(。我还深入了解了有多少机器人和脚本针对我们的网站运行！大多数都是无害的或Wordpress漏洞利用的尝试(幸运的是我没有运行Wordpress(，所以对我的网站没有真正的风险，但仍然令人大开眼界。我最初每小时监控一次日志(偏执狂！(，然后每天，然后每周。
我会凭记忆说，又花了 3 个月左右的时间，直到我完全适应地完全打开它并在接下来的几天里检查了很多。幸运的是，所有的努力都得到了回报，很少有误报。
从那时起，它一直相当稳定，很少有错误警报 - 主要是由于错误数据(例如，email@@example.com输入为未正确验证电子邮件地址的字段的电子邮件地址(，我经常离开这些地方并修复字段验证。
这里给出了我必须调整的一些常见问题和规则： Modsecurity：过多的误报(请注意，您可能不需要或不想关闭您网站中的所有这些规则(。
我们在Web服务器上安装了Splunk(基本上是一个吸收日志文件的工具，然后可以搜索或自动提醒或报告问题(。因此，设置一些警报，当更麻烦的自由文本字段导致 ModSecurity 块(在那里纠正了一两个误报(，以及数量(因此我们在超过阈值时会收到警报，可以看到我们受到持续攻击 - 每年发生几次(和每周/每月报告。
因此，从零开始实施 4-5 个月的时间，在此期间可能需要 30-40 个工日。但这是一个非常复杂的网站，我之前没有ModSecurity/WAF的经验。从好的方面来说，学到了很多关于网络技术、ModSecurity 的知识，并且通过盯着一些规则而变得正则表达式盲目！:-)