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