ModSecurity是一个免费、开源的Apache模块，可以充当Web应用防火墙（WAF）。它有着丰富功能、强大的社区以及可供选择的商业支持，因而对任何提供非静态内容、需要审查的生产型Apache Web服务器来说必不可少。
ModSecurity的主要功能在于，提供可靠的保护，远离各种网上威胁。它不是将安全重心偏离应用程序，而是增添了全局级别的功能。想对它进行配置，只需为客户机与服务器之间通信的每一个部分用条件和操作来指定规则，这些部分包括请求头、请求主体、响应头和响应主体。因而，ModSecurity可以预防针对Web服务器、PHP、Perl和ASP等解释器以及Web应用程序发动的攻击。
ModSecurity可以比软件开发商先行一步，缓解零日攻击、针对安全漏洞提供保护，最近它就运用规则有效地防范了Apache字节范围头（Range Header）拒绝服务安全漏洞和Java浮点值拒绝服务攻击。
ModSecurity在检查完整通信流的同时，还能够将它记入日志，这意味着该软件可用于审查和排除故障。全面日志功能给Web服务器加大了开销，所以只有当问题需要调试时，才通常开启该功能。不过，全面日志（和审查）在一些高度重视安全的企业必不可少。
一旦ModSecurity遇到了匹配的条件，就能采取极其严格的操作。这些操作可能是破坏性的，比如阻止事务，也可能是非破坏性的，比如将数据记入日志。一旦条件符合，它就能执行Linux命令，这大大扩展了ModSecurity的功能，并且为它提供了Linux用于处理事务的所有能力。它可以将规则串联起来，适用于更复杂的条件。它的会计算法可以用来取代ModEvasive，阻止数量过多的请求和拒绝服务攻击。
ModSecurity的安装
只要从基于Debian的发行版的官方存储库下载，即可获得ModSecurity。如果是CentOS及基于红帽的其他发行版，ModSecurity存在于EPEL存储库（http://fedoraproject.org/wiki/EPEL）中，但是如果你想获得拥有最新功能的最新版本，就要执行手动安装。下面介绍了在CentOS 6中如何来安装:
1. 确保httpd和httpd-devel连同它们的所有依赖项都已安装。
2. 启用Apache中的unique_id_module。为此，编辑文件/etc/httpd/conf/httpd.conf，取消含有LoadModule unique_id_module modules/mod_unique_id.so的这一行的注释。你必须重新装入Apache，变更才会生效。
3. 从该项目网站（http://www.modsecurity.org/download/）下载最新版本的ModSecurity。
4. 抽取已下载的软件包，进入到刚创建的目录modsecurity-apache_2.x.x，其中的x.x是ModSecurity的最新分支。
5. 完成安全源软件包的标准步骤：配置、编译和安装。
6. 如果上述命令成功完成执行，ModSecurity就会安装到系统上。一个新的Apache模块会出现在/etc/httpd/modules/mod_security2.so中，而ModSecurity的可执行文件会出现
在/usr/local/modsecurity/bin/中。
7. 要装入新的ModSecurity模块，编辑Apache的配置文件/etc/httpd/conf/httpd.conf。寻找LoadModule，找到装入所有模块的那部分。在该部分的末尾，添加LoadModule security2_module modules/mod_security2.so。
8. 重启Apache。运行apachectl -D DUMP_MODULES |grep security，确保ModSecurity已正确安装，寻找输出中的security2_module (shared)。
至此，ModSecurity已安装，但还没有被启用或配置，现在不妨对它进行配置。
#p# ModSecurity的配置
当你开始配置ModSecurity时，首先使用主配置文件/etc/httpd/conf/crs/modsecurity_crs_10_config.conf中的全局指令，比如SecRuleEngine，我在后面会详细探讨。不过，对于大多数配置而言，你可以用指令SecRule来创建安全规则。后者对ModSecurity进行微调，往往变得非常复杂。
ModSecurity规则示例看起来像这样：
SecRule Target Operator [Actions]
Target定义了要检查的对象——比如说REQUEST_URI。Operator表明了应该如何进行检查。可选的Actions指定了一旦条件满足，执行什么操作。
从ModSecurity入手并非易事，自行编写安全规则也并非易事。这就是为什么你应该一开始从开放式Web应用程序安全项目（OWASP）发行的核心规则集（https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project）入手。你可以对它进行定制，以满足自己的要求，但是这套规则集很可靠、很成熟，而且涵盖了许多流行的恶意攻击。尽管它不是特别针对Web应用程序，但有助于防范常见的黑客攻击手法。不过，它也会阻止正当请求，所以在部署时一定要小心，还需要定制。
创建另一个目录，里面只保存带规则的ModSecurity文件，比如/etc/httpd/conf/crs/。要告诉Apache包含来自该目录的所有ModSecurity配置指令，只需在配置文件（/etc/httpd/conf/httpd.conf）的末尾添加下面这一行：
Include /etc/httpd/conf/crs/*.conf
将最新规则集下载到临时目录，比如~/mod_security_test/。为此，你可以使用名为rules-updater.pl的Perl脚本来完成这项任务；在默认情况下，你可以在/usr/local/modsecurity/bin/中找到这段脚本。它要求使用Perl模块Crypt::SSLeay，你可以这样来运行它：
/usr/local/modsecurity/bin/rules-updater.pl -rhttp://www.modsecurity.org/autoupdate/repository/ -prules -Smodsecurity-crs
上面这个命令下载带版本号的压缩文件——目前版本是modsecurity-crs_2.2.2.zip，以获得规则。在临时目录里面抽取该压缩文件（unzip modsecurity-crs_2.2.2.zip），然后拷贝ModSecurity的主配置文件，名为modsecurity_crs_10_config.conf.example，并拷贝base_rules中的基本规则：
cp ~/mod_security_test/modsecurity_crs_10_config.conf.example /etc/httpd/conf/crs/modsecurity_crs_10_config.conf
cp ~/mod_security_test/base_rules/* /etc/httpd/conf/crs/
除了基本规则外，核心规则集还提供了针对特定应用程序的规则，比如~/mod_security_test/slr_rules目录中的那些规则。后者专门是为了保护流行的Web应用程序，如Joomla和WordPress。不过，在运用任何特定或试验的规则时，要格外小心，因为它们可能会破坏客户机与Web服务器之间的正当通信。
要开始使用刚安装的规则，编辑文件/etc/httpd/conf/crs/modsecurity_crs_10_config.conf，寻找指令SecRuleEngine，该指令确定了是否执行ModSecurity规则、如何执行。它有三种模式：On（启用）、Off（禁用）和DetectionOnly，后者仅仅记录了规则何时被触发，而不实际执行规则。这第三个选项非常适合从ModSecurity入手，或者确保顺畅无阻地部署新的ModSecurity规则。除了指定这个设置外，还要指定SecDataDir，这是用于存储持续性数据IP地址和会话的目录。存储该数据的一个好地方是/tmp；就在SecRuleEngine设置之后指定SecDataDir /tmp。
#p# 测试和调试ModSecurity
一旦你将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://www.f5.com/products/big-ip/application-security-manager.html）。这种商业替代方案在另外的硬件设备上运行，具有代理和内容加速等额外功能。
原文链接：http://olex.openlogic.com/wazi/2011/protect-and-audit-your-web-server-with-apaches-modsecurity/
