一旦你将SecRuleEngine设成了DetectionOnly模式，重新装入Apache，即可让变更生效。然后，你可以甚至在生产环境下开始测试ModSecurity，因为它不会造成任何危害。默认情况下，ModSecurity将内容记入到Apache的错误日志；在CentOS中，该错误日志是/var/log/httpd/error_log。

作为第一次测试，访问虚假的URL，比如http://yourserverip/etc/。在Apache的错误日志中，你应该会看到有个错误含有“ModSecurity: Warning. Pattern match “\\\\/etc\\\\/”.”。这表明，ModSecurity规则已启用。如果你看到“404 Not Found”页面，它证实了ModSecurity处于学习模式（SecRuleEngine DetectionOnly）。如果ModSecurity的规则已执行（SecRuleEngine On），你会看到“403 Forbidden”页面。

当你首次实施ModSecurity后，可能会遇到关于正当请求的许多警告和错误。假设你在网站上果真有一个名为etc的目录。据Apache的错误日志显示，由于ModSecurity的规则编号958700，该目录会受到阻止。下面是来自日志的内容片段：

[Wed Nov 09 05:40:34 2011] [error] [client 10.0.2.2] ModSecurity: Warning. Pattern 
match "\\\\/etc\\\\/" at REQUEST_FILENAME. [file
"/etc/httpd/conf/crs/modsecurity_crs_40_generic_attacks.conf"] [line "221"] [id
"958700"] [rev "2.2.2"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity
"CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [tag "WASCTC/WASC-33"] [tag 
"OWASP_TOP_10/A4"] [tag "PCI/6.5.4"] [hostname "localhost"] [uri "/etc/"] [unique_id
 "TrpYon8AAAEAAAYaVy4AAAAA"]

据该日志条目显示，这个规则位于文件/etc/httpd/conf/crs/modsecurity_crs_40_generic_attacks.conf中的221行上。至此，你有两个选择：

1. 使用指令SecRuleRemoveById，禁用整个规则。该语句应该放在在所有其他ModSecurity文件和规则之后装入的文件中。创建modsecurity_crs_70_exceptions.conf，把它放在/etc/httpd/conf/crs中。该文件旨在让版本之间保持兼容，并且长期确保一致性，所以当ModSecurity的规则更新后，被忽视的规则就会被记住。

2. 不过禁用这个规则也许不是明智之举，因为该规则的功能不仅仅是阻止/etc/目录。该规则被禁用后，服务器就会暴露在某些攻击面前，比如远程文件访问（RFA）攻击。

为了提高安全性和可靠性，一种更好的办法也许是编辑该规则，消除起冲突的部分。不过，编辑规则并非总是很容易，因为它们经常使用复杂的正式表达式。另外，未来的更新版本会覆盖掉旧的ModSecurity规则和文件，包括所有定制内容。

在我们这个例子中，规则很简单，也很具体： SecRule REQUEST_COOKIES|REQUEST_COOKIES_NAMES|REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\/etc\/" \。想采用第一个选择，就要使用指令SecRuleRemoveById 958700。要采用第二个选择，只要去掉REQUEST_FILENAME。这将确保Web服务器受到保护，可以防范客户机请求其他部分中的攻击。

结束语
除了WAF所能提供的一切外，ModSecurity还提供了更多的功能。不过，对它进行配置并非易事；该软件还缺少图形化界面。这就是为什么拥有庞大IT预算的一些企业可能更偏爱其他的商业解决方案，比如F5公司的Big-IP 应用安全管理器。这种商业替代方案在另外的硬件设备上运行，具有代理和内容加速等额外功能。

原文链接：http://olex.openlogic.com/wazi/2011/protect-and-audit-your-web-server-with-apaches-modsecurity/