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#副標題#e#
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#副標題#e#測試和調試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://olex.openlogic.com/wazi/2011/protect-and-audit-your-web-server-with-apaches-modsecurity/
