如何選擇合適的Web應用防火墻（WAF）？
譯文【51CTO.COM 獨家翻譯】大概十年前，Web應用防火墻（WAF）進入了IT安全領域，最早提供這類產品的供應商是幾家新興公司，如Perfecto（曾改名為Sanctum，后在2004年被WatchFire收購）、KaVaDo（2005年被Protegrity收購）和NetContinuum（2007年被Barracuda收購）。工作原理相當簡單：隨著攻擊范圍向IP堆棧的上層移動，瞄上針對特定應用的安全漏洞，這時勢必需要開發旨在識別和預防這些攻擊的產品。雖然網絡防火墻在阻止較低層攻擊方面很有效，但并不擅長解開IP數據包層，以分析較高層協議；這就意味著，網絡防火墻缺少應用感知功能，而要關閉自定義Web應用中的漏洞窗口，就需要這種功能。
但是盡管WAF炒得很火，供應商承諾的優點也很多，但最終用戶的使用體驗卻相當差。早期產品存在諸多缺點，比如誤報率高，給受保護應用的性能帶來負面影響，又很難有效地管理。2005年前后，包括思科、思杰和F5在內的大牌網絡供應商或收購或開發了Web層監控技術，WAF隨之成為一道公認的邊界安全防線。促使WAF得到主流用戶采用的另一個因素是，出臺了支付卡行業數據安全標準（PCI-DSS），該標準在第6.6項需求中明確要求使用具有應用層感知功能的防火墻。
如今，WAF已是IT安全工具箱中一個公認的組成部分。但許多企業仍在為這個問題而糾結：該買哪一種WAF、如何最合理地把它們集成到Web應用風險管理產品系列中。本文分析了采購WAF方面一些主要的決策因素，并給出了相應的建議，以便確保它們很適合企業架構和網絡生態系統。
架構和物理尺寸
WAF應該適合于現有的架構，并采用得到安全操作團隊接受和支持的物理尺寸。WAF放置方面主要有兩種架構方案可以考慮：橋接模式（in-line）或分接/跨接模式（tap/span）。
·橋接模式：在這種架構（又叫主動配置）中，WAF就直接放在請求方（如瀏覽器客戶端）與Web應用服務器之間的流量路徑當中。WAF在檢查應用請求和響應之后再傳送請求和響應。
在橋接模式里面，WAN到底采用哪一種方法來傳送流量，企業可以作出眾多選擇。網絡方面的選擇有：路由器（3層）、網橋（2層）和HTTP反向代理系統。WAF還可以直接在主機服務器（Web應用駐留在上面）上使用，這種WAF名為基于主機的WAF或嵌入式WAF。使用網橋模式的WAF可能不需要改動網絡，但流量必須定向至路由器或反向代理模式中的WAF。
要選擇一種最佳模式，先要評估一下目前網絡上的Web應用是如何構建的：該應用是不是已經在反向代理系統的后面？如果是這樣，企業又想繼續使用反向代理架構，可以考慮支持這種需要的WAF。如果企業要求WAF終結SSL連接，以檢查數據包內容，那么反向代理系統是個理想的選擇。不過，在一路發送數據包內容之前終結連接（無論是不是SSL連接）的確需要處理能力，所以需要對這種模式進行造型和測試，確保不會帶來讓人無法接受的延遲。
橋接式WAF經配置后，可以主動阻止違反WAF規則集的請求和流量。這項功能很有用，但使用要慎重--要是橋接式WAF過于主動地阻止，就會阻止合法流量進入到Web服務器，因而導致應用無法使用。在制定任何主動阻止規則之前，先要進行全面測試，確保生產環境中不會出現服務意外受到干擾的情況。另外，可以以橋接方式使用WAF，但要讓它處于純監控（或被動）模式。
架構方面要考慮的另一個因素是，將安裝和管理多少個WAF。如果需要WAF用于多個場合，那不妨考慮支持分布式管理或分布式WAF的解決方案。在這種模式下，可使用中央控制臺來管理用于多個場合的防火墻。可以針對所有WAF統一運用規則或設置；也可以根據每個WAF的情況，逐個運用規則集，具體取決于WAF在保護哪一種Web應用。 #p#
|
優點 |
缺點 |
|
•能防止實時攻擊 |
•Web應用的流量速度 可能會減慢 •合法流量可能被阻止 |
表格1：橋接式WAF的優缺點
分接/跨接模式：這種模式又叫"被動"模式，因為WAF被擋在流量路徑外面，從分接端口或跨接端口監控流量。分接/跨接式WAF常常用于收集數據，以便之后用于調查或取證分析。這種架構模式的一個主要優點是，它并不干擾網絡流量或吞吐量，因為它不是直接嵌入。而另一方面，不在流量路徑當中意味著，這種解決方案無法執行主動的橋接式WAF所能執行的那種阻止操作。不過，支持某些形式的阻止操作，比如連接重置，或者通過聯系到另一個系統（如網絡防火墻），然后讓該系統執行阻止操作。
|
優點 |
缺點 |
|
•非侵入性 •不干擾流量 |
•無法阻止實時流量 |
圖2：分接/跨接式WAF的優缺點
·新的變化：兩個重要變化在促使企業需要WAF使用新的架構模式，這兩個變化就是云計算和虛擬化。基于云的WAF先攔截流量，然后允許合法流量進入到企業網絡；或者對于在云環境也有Web應用的公司來說，允許合法流量通過云進入到服務器。虛擬化環境帶來了一個獨特的挑戰，因為在虛擬機管理程序上運行的虛擬機構成了自己的小型網絡；在這個網絡中，流量從一虛擬服務器傳送到另一虛擬服務器，沒必要通過網絡傳送。為了防止虛擬機內部出現應用攻擊，WAF需要能夠查看流量。使用應用編程接口（API）或其他服務，通過虛擬機管理程序來監控活動，就能做到這一點。
·物理尺寸：探討一下WAF如何捆綁和銷售給客戶的問題。許多WAF支持多種物理尺寸選擇，所以企業不需要為購買硬件設備而大傷腦筋，只要獨立軟件開發商（ISV）的軟件得到批準。換句話說，選擇什么物理尺寸的硬件取決于貴企業最習慣于什么。選擇包括：
◆純軟件--硬件由采購部門負責提供
◆設備--軟件與專門針對WAF進行選型和調整的設備捆綁銷售
◆硬件--WAF智能直接嵌入在硬件本身里面
◆主機--這是一種軟件方案，但軟件安裝在運行Web應用的同一臺服務器上，而不是安裝在單獨的主機或虛擬機上。
檢測技術
剛才已討論了架構和物理尺寸問題，現在要問一下這個問題：WAF如何檢測Web應用中的漏洞以及針對Web應用的攻擊？WAF的目的是智能地保護Web應用，所以擁有細粒度規則和檢測機制很要緊。大多數WAF采用結合不同檢測技術的方法，確保檢測范圍最廣泛、結果最準確。除了問供應商使用哪些檢測技術外，還要讓供應商出示證明誤報率/漏報率的依據以及第三方測試結果，以便更清楚地了解WAF在實際使用時效果會有多好。下面是一些檢測技術，以及向最后選出來的幾家產品供應商詢問的幾個問題：
·特征：與為反惡意軟件和網絡入侵檢測系統（IDS）編寫的特征很相似，WAF特征也將預定字符串或正則表達式（RegEx）與流量進行匹配，以查找已知攻擊。
該產品在交付時隨帶一套特征嗎？#p#
供應商每隔多久更新特征？
·規則：規則在特征概念的基礎上更進了一步，它可以用邏輯"與"運算符把一系列字符串聯系起來，用"或"運算符添加更復雜的匹配機制，或者用"非"運算符實現"排斥"功能。還可以設定規則，尋索非常特定的字符串類型，就像16位號碼（比如信用卡號），作為來自Web服務器的響應而發送。一些WAF能夠動態"學習"流量模式，根據一套基準規則來查找異常行為。"學到"的信息可以發送給管理員，提議針對WAF或互補性保護設備（如IDS或網絡防火墻）設定什么樣的新規則。
供應商提供基準規則嗎？
客戶能夠手動添加新規則嗎？
WAF能夠動態"學習"新規則嗎？
◆規范化：攻擊者的一種慣用手法是，對漏洞的有效載荷做手腳，冒充沒有危害的內容（比如對有效載荷的一部分進行URL編碼），從而避開WAF的檢測。為了檢測出這種攻擊，WAF就要能夠對請求進行規范化處理，以便進行分析。以下是僅僅幾個規范化機制--完整清單請參閱Web應用安全聯盟Web應用防火墻評估標準的第3.1章節。
WAF能夠對轉義字符或編碼字符（如t、�01、%2C、xAA和uAABB）進行規范化嗎？
使用自引用路徑（即使用/./和等效的編碼方案）嗎？
使用混合大小寫和國際字符集嗎？
◆API：如果企業想自行開發自定義檢測技術或規則，以便進行特別評估，比如邏輯檢查，可以通過API來做到這點。咨詢一下供應商，看看對方是否的確支持API；如果支持，這些API與WAF分析引擎的集成又有多緊密？
WAF有API嗎？
API與WAF引擎的集成有多緊密？
供應商為自定義插件提供哪一種支持？
其他考慮因素
◆高可用性和高吞吐量：如果WAF在流量很大的環境下，它應該能夠在不減慢Web應用速度的情況下，處理龐大流量，如果它是橋接式WAF更要有這種功能。如果一個WAF或Web應用失效或超過安全界限，WAF就得支持故障切換，與負載均衡器共同防止服務受到干擾。一些WAF與高可用性設備緊密集成，可作為Web流量管理系統的組件來運行。如果是獨立式WAF，就要確保它們滿足貴公司的高可用性需求，以便同時符合性能和架構方面的要求。
WAF能與現有的高可用性/負載均衡設備兼容嗎？
WAF在不丟失流量或流量丟失有限的情況下支持故障切換嗎？
WAF能支持多大的流量？#p#
受保護應用的性能有沒有出現任何延遲？
添加新的/復雜的規則后，性能有沒有因而下降？
◆日志和報告：作為Web應用的監控器和警衛，WAF具有先天的優勢，可以將流量和活動記入日志。一些WAF能夠捕獲全部流量的完整數據包（這在分接/跨接式解決方案中最常見），但是它們都應該將進出Web應用的事務活動方面的關鍵信息記入日志。
WAF維護完整的事務日志嗎？
日志使用什么格式（如系統日志）？
日志是不是以防篡改/防揭換的方式保存在服務器上？
日志能夠從服務器安全地導出嗎？
產品是否隨帶預配置的報告，以便合規和管理？
◆管理多個WAF：如果WAF要部署在復雜的分布式環境中，集中管理功能將大大減輕管理開銷。
WAF是否工作在用于多處的分布式WAF環境下？
安全策略能不能運用到所有WAF？
針對單個應用的自定義策略是否得到支持？
◆SSL和加密：加密可以保護傳送的數據被人窺視，但這也意味著WAF要是不先對數據解密，就無法檢查數據。這方面有兩個選擇：一是為WAF提供密鑰，那樣就能對數據解密。二是在WAF處終結SSL連接，然后建立一條新的加密隧道，以便數據從WAF傳送到Web服務器/瀏覽器（建立加密隧道是可選功能）。SSL處理給處理器帶來了開銷，所以要精心選擇可合理終結SSL會話的WAF，考慮使用加速板來卸載一部分處理工作。
WAF支持SSL解密嗎？
是否支持橋接式終結？
有沒有實現被動解密的密鑰共享機制？
有沒有加速選件，比如加密加速板？
◆新興協議：規范化和重新組裝HTTP和HTML很棘手，但在Web 2.0及之后的環境中，有許多新興協議和現有的媒體類型會帶來惡意軟件或安全漏洞。沒有哪個WAF能夠分析.swf（Flash），找出所有安全漏洞，但至少應支持圖像檢測，并支持Jscript和PHP等腳本。
WAF能處理dHTML、CSS、XML和SOAP嗎？
WAF能支持對Flash進行掃描嗎？支持圖像（JPG、GIF和PNG）掃描呢？
◆與Web應用掃描器集成：Web應用掃描器這種產品能夠自動掃描來自外部的Web應用，以模擬攻擊者可能會發現的那種安全漏洞。掃描器與WAF互為補充，因為它們能發現管理員利用自定義WAF規則可以緩解的安全漏洞。有些Web應用掃描器供應商與WAF供應商結成了合作伙伴，那樣掃描過程中發現了安全漏洞后，掃描器就能自動提議采用什么樣的自定義規則，使用正確的WAF句法。這有助于迅速消除安全漏洞，也不需要試圖制定防止攻擊的最佳規則所需要的管理開銷。
供應商與Web應用掃描器供應商有沒有合作伙伴關系？
雙方產品之間的集成有多緊密？
規則能自動更新，還是需要手動干預？
總結
你在購買WAF產品之前，需要弄清楚上述問題和考慮因素，它們是確保你買到合適產品的基礎。想了解更多的詳細內容和考慮因素，請參閱Web應用安全聯盟的Web應用防火墻評估標準評估響應矩陣。將上述幾點和評估響應陣里面的更多詳細內容作為基準，列明需求，并確定必要的功能特性，然后向供應商提交采購需求，敲定最后的需求。雖然WAF市場不像其他一些市場來得擁擠，但事先做好明確采購需求方面的工作將大大縮小產品的選擇范圍，并有助于確保企業能夠得到合適的工具。
來源：http://www.esecurityplanet.com/features/article.php/3897346/How-to-Choose-the-Right-Web-Application-Firewall-WAF.htm
【編輯推薦】
