許多企業將Web應用程序防火墻(WAF)默認為保護Web應用程序時的優秀實踐或合規性要求。WAF是一種特定的防火墻，旨在識別和阻止Web應用程序流量的攻擊。期望防火墻將阻止命令注入攻擊、跨站點腳本攻擊、協議違規以及其他針對Web應用程序的常見攻擊。

[[319177]]

隨著企業數字轉型和“安全上云”運動的開展，以及當下疫情加重的Web安全焦慮，越來越多的企業開始考慮云WAF防火墻產品，使用在云中預配置的WAF對Web應用進行保護。除了專業WAF廠商外，目前主要的云供應商都通過收購或者研發豐富了自己的WAF產品，它們與服務商自己的負載均衡器很好地集成在一起。

與傳統硬件WAF相比，除了巨大的價格優勢外，云WAF還有以下突出優點：

部署簡單，維護成本低

這也是云WAF最有價值和受用戶喜愛的一點，無需安裝任何軟件或者部署任何硬件設備，只需修改DNS即可將網站部署到云WAF的防護范圍之內。

用戶無需更新

云WAF的防護規則都處于云端，新漏洞爆發時，由云端負責規則的更新和維護，用戶無需擔心因為疏忽導致受到新型的漏洞攻擊。

可充當CDN

云WAF在提供防護功能的同時，還同時具有CDN的功能，在進行防護的同時還可以提高網站訪問的速率，CDN通過跨運營商的多線智能解析調度將靜態資源動態負載到全國的云節點，用戶訪問某個資源時會被引導至最近的云端節點從而提高訪問速度。

但是，目前國際市場上一些有代表性的云WAF產品(本文主要討論云計算服務商提供的云WAF)，到底“能不能打”?

在Gartner的調研報告下面，很多企業安全人員的留言對云WAF也是褒貶不一，一位軟件工程師認為AWS Web Application Firewall是“最可靠的軟件”。但另一位專家稱云WAF有“需要進一步解決的問題”。至于Azure，評論似乎更加復雜。一位架構師認為，“仍準備了專用WAF設備作為備份”，盡管許多人認為它“易于實施和使用”。

由于目前市場上很少有第三方機構對云計算服務商的云WAF產品進行實戰檢測，因此客戶對云WAF性能和功能的認知，有時候可能只是一種對云安全的“蜜汁自信”。云WAF是否可以很好地阻止常見的Web應用程序攻擊?

近日，網絡安全團隊Fraktal針對AWS WAF (Amazon)、AWS WAF (Fortinet)、AZURE WAF (CRS 3.1)、BARRACUDA(梭子魚)WAF-as-a-service四款常見的云服務商的云WAF產品(服務)做了一個實戰測試，結果有些令人吃驚。測試內容如下：

測試設置

我們在AWS和Azure中搭建了測試環境，以測試云WAF。我們的設置包括以下內容：

• 攻擊者的主機在特定的目標Web主機上執行數千個腳本化的測試用例。我們將有效負載注入了發往目標主機的HTTP GET和POST請求。
• 在云容器平臺上，目標Web主機運行容器化自定義Web服務器——AWS Elastic Container Service ECS或Azure容器實例ACI。該Web服務器對所有傳入HTTP請求反饋HTTP響應代碼“200 OK”。
• 目標Web主機前置一個具備WAF功能的云負載平衡器——AWS Elastic Load Balancer ELB或Azure Web Application Gateway。
• 從Azure Marketplace配置的梭子魚WAF即服務(WaaS)，將流量定向到Azure ACI上的目標Web主機。

測試團隊為AWS和Azure內部解決方案挑選了云托管版本的商業WAF產品進行對比測試。四款產品采用的規則/服務如下：

• Azure應用程序網關WAF，使用來自開放式Web應用程序安全項目(OWASP)的CRS 3.1規則
• 使用梭子魚托管規則從Azure市場配置的梭子魚WAF即服務(WaaS)
• 使用Amazon托管規則的AWS WAF
• 使用Fortinet托管規則的AWS WAF

在Azure云中，總體測試體系結構如下所示，在AWS云上的測試環境采用了完全相同的設置。

用于測試連接到Azure和AWS云負載平衡器的WAF的高級測試體系結構

測試梭子魚WAF即服務需要采用備用設置，測試團隊在Azure云上配置了服務，對前述設置進行了最小的更改。

用于在Azure中測試梭子魚WAF即服務的高級體系結構

測試團隊使用2月19日當日上述云服務上可用的托管默認值進行了測試。為了準確模擬用戶使用這些服務的最常見方式，測試者沒有刪除或添加任何可能影響檢測或阻止攻擊能力的規則或定義。對于AWS托管規則，用戶必須選擇規則組，因為可以同時啟用的規則組數量受到限制，測試者選擇了一種可以最好地覆蓋OWASP十大威脅的規則組合，為測試用例提供最佳保護。

所選規則組

• AWS-AWSManagedRulesSQLiRuleSet
• AWS-AWSManagedRulesLinuxRuleSet
• AWS-AWSManagedRulesKnownBadInputsRuleSet
• AWS-AWSManagedRulesCommonRuleSet
• AWS-AWSManagedRulesPHPRuleSet
• AWS-AWSManagedRulesAdminProtectionRuleSet

測試用例

為了測試WAF，測試團隊挑選了幾種現實中常見的幾種攻擊和繞過方法，針對自定義Web服務器通過HTTP發起這些攻擊，目標服務器將記錄那些通過WAF的請求。

測試使用的攻擊方法如下(詞條解釋引用自owasp.org)：

• 命令執行：通過向應用程序中注入命令破壞系統。
• 服務器端包含注入(SSI)：SSI是Web應用程序上存在的指令，用于向HTML頁面提供動態內容。服務器端包含攻擊允許通過將腳本注入HTML頁面或遠程執行任意代碼來利用Web應用程序。
• SQL注入：向客戶端到應用程序的輸入數據中注入SQL查詢。
• 路徑遍歷：路徑遍歷攻擊(也稱為目錄遍歷)旨在訪問存儲在Web根文件夾外部的文件和目錄。
• 格式錯誤的XML文檔：格式錯誤的文檔可用于消耗資源或注入惡意命令。
• 跨站點腳本(XSS)：跨站點腳本(XSS)攻擊是一種注入攻擊，其中，惡意腳本通過網絡瀏覽器從惡意網站注入到原本良性和可信任的網站中。

這組測試方法代表了針對網站的典型攻擊。測試用例的目的不涉及業務邏輯弱點，以及其他可被惡意利用的應用邏輯。

檢測結果

結果是令人震驚的，除了Azure WAF，其他幾款云WAF的表現都是災難性的。

四大云WAF測試結果數據(百分比表示被阻止的攻擊比重，數字越高越好)

肉眼可見，使用CRS 3.1規則的Azure WAF的攻擊防護成功率遠高于其他三款云WAF產品，也是在整個測試用例集中能可靠執行的唯一云WAF服務。

測試報告的另外一個有趣發現是，是否使用URL字符編碼，對WAF的安全性能表現影響極大!例如，梭子魚阻止了我們所有未編碼的SSI測試用例，但在編碼時則僅能阻止一半。因此，從攻擊者的角度來看，嘗試使用不同的編碼可能是逃避WAF保護的有效方法。

幾個小事實

AWS托管的WAF在本次測試中的表現最為“寬松”，它會放行以下有效載荷進行攻擊：

此外，AWS中托管的Fortinet WAF和Azure中的梭子魚WAF即服務也都允許這兩個示例。

從有效載荷和拒絕的響應來看，很難對WAF的內部運作得出許多結論。有時，WAF的各種行為看上去非?；靵y和搞笑，例如：

• AWS托管WAF對POST和GET請求的處理方式似乎完全不同。例如這個請求在GET請求中被阻止，但在POST請求中被允許：%2e%2e//etc/passwd。
• AWS托管WAF能夠阻止有效負載ls-l/var/www/*，但卻又允許有效負載&& ls-l/var/www/*，|ls-l/var/www/*依此類推。
• 梭子魚WAF即服務在該字符'是有效載荷的唯一字符時會堅定地阻止該字符，但同時又允許這樣的有效載荷，例如eval('sleep 5');和'whoami。

結論

結果表明，云WAF服務生下來就是不平等的，而且大多數IaaS云服務商的WAF服務還遠遠趕不上第三方方案。接受測試的AWS、Azure和梭子魚中，Azure WAF無疑是贏家，并且是唯一運行良好的服務。而AWS和梭子魚的產品，對一些最常見的攻擊類型都“睜一只眼閉一只眼”。

如果企業要在云中構建應用程序，則應留意“選配”的安全服務是否能夠達到安全需求。雖然購買云WAF可能是一種合規需要，但用戶應當清醒地認識到，云計算廠商的“免費午餐”，有時候安全性能可能與您想象得不太一樣。

聲明

本項云WAF測試由Fraktal網絡安全團隊的Tuomo、Tommi和Marko完成，其測試結果僅基于特定測試環境和配置，除了在特定測試環境和用例中比較云WAF服務的相對性能之外，這些測試結果無意在任何其他上下文應用場景中進行解釋或作為用戶選擇產品的依據。

【本文是51CTO專欄作者“安全牛”的原創文章，轉載請通過安全牛（微信公眾號id:gooann-sectv）獲取授權】

戳這里，看該作者更多好文