在我們之前有關雲主題的資料中，我們 、如何保護公有雲中的 IT 資源以及為什麼傳統防毒軟體並不完全適合這些目的。 在這篇文章中，我們將繼續雲端安全主題，討論 WAF 的演變以及更好的選擇：硬體、軟體還是雲端。
什麼是WAF
超過75%的駭客攻擊是針對網路應用程式和網站的漏洞：此類攻擊通常對於資訊安全基礎設施和資訊安全服務來說是不可見的。 反過來，Web 應用程式中的漏洞會帶來用戶帳戶和個人資料、密碼和信用卡號的洩漏和詐欺風險。 此外，網站中的漏洞也是攻擊者進入公司網路的入口點。
Web 應用程式防火牆 (WAF) 是一個保護屏障，可阻止對 Web 應用程式的攻擊：SQL 注入、跨站點腳本、遠端程式碼執行、暴力破解和授權繞過。 包括利用零日漏洞的攻擊。 應用程式防火牆透過監控網頁內容（包括 HTML、DHTML 和 CSS）並過濾潛在的惡意 HTTP/HTTPS 請求來提供保護。
第一個決定是什麼？
創建 Web 應用程式防火牆的首次嘗試是在 90 年代初進行的。 據了解，至少有三名工程師曾在該領域工作。 第一個是普渡大學電腦科學教授 Gene Spafford。 他描述了代理應用程式防火牆的體系結構，並於 1991 年在書中發表 .
第二名和第三名是來自貝爾實驗室的資安專家 William Cheswick 和 Marcus Ranum。 他們開發了第一個應用程式防火牆原型。 它由 DEC 分發 - 該產品以 SEAL（安全外部存取連結）的名稱發布。
但 SEAL 並不是一個成熟的 WAF 解決方案。 它是一款具有高級功能的經典網路防火牆 - 能夠阻止對 FTP 和 RSH 的攻擊。 因此，今天第一個WAF解決方案被認為是Perfecto Technologies（後來的Sanctum）的產品。 1999年她 應用盾系統。 當時，Perfecto Technologies正在開發電子商務資訊安全解決方案，線上商店成為他們新產品的目標受眾。 AppShield能夠分析HTTP請求並根據動態資訊安全策略阻止攻擊。
與 AppShield 大約在同一時間（2002 年），第一個開源 WAF 出現。 他成為了 。 它是為了普及WAF技術而創建的，並且仍然受到IT社區的支持（這裡是 ）。 ModSecurity 基於一組標準正規表示式（簽名）阻止對應用程式的攻擊 - 用於根據模式檢查請求的工具 - .
結果，開發人員成功實現了他們的目標——新的WAF解決方案開始出現在市場上，包括基於ModSecurity構建的解決方案。
三代已成為歷史
習慣上區分出三代WAF系統，它們隨著技術的發展而演變。
第一代。 使用正規表示式（或語法）。 這包括 ModSecurity。 系統提供者研究對應用程式的攻擊類型，並產生描述合法和潛在惡意請求的模式。 WAF 檢查這些清單並決定在特定情況下做什麼 - 是否阻止流量。
基於正規表示式的檢測的一個例子就是前面提到的項目 開源。 另一個例子 - ，這也是開源的。 具有正規表示式的系統有許多缺點，特別是當發現新漏洞時，管理員必須手動建立額外的規則。 在大規模IT基礎設施的情況下，可能有數千條規則。 管理如此多的正規表示式是相當困難的，更不用說檢查它們會降低網路效能。
正規表示式也有相當高的誤報率。 著名語言學家諾姆·喬姆斯基提出了語法分類，他將語法分為四個條件複雜性等級。 根據這種分類，正規表示式只能描述不涉及偏離模式的防火牆規則。 這意味著攻擊者可以輕鬆「欺騙」第一代WAF。 解決此問題的一種方法是向應用程式請求添加特殊字符，這些字符不會影響惡意資料的邏輯，但會違反簽名規則。
第二代。 為了規避 WAF 的效能和準確性問題，開發了第二代應用防火牆。 他們現在擁有負責識別嚴格定義的攻擊類型（針對 HTML、JS 等）的解析器。 這些解析器使用描述查詢的特殊標記（例如變數、字串、未知、數字）。 潛在的惡意令牌序列被放置在一個單獨的清單中，WAF 系統會定期檢查該清單。 這種方法首次以 C/C++ 的形式在 Black Hat 2012 會議上展示 ，它允許您檢測 SQL 注入。
與第一代 WAF 相比，專用解析器速度更快。 然而，他們並沒有解決當新的惡意攻擊出現時手動配置系統的困難。
第三代。 第三代檢測邏輯的演進包括使用機器學習方法，使檢測語法盡可能接近受保護系統的真實 SQL/HTML/JS 語法。 此檢測邏輯能夠使圖靈機適應遞歸可枚舉語法。 此外，在第一個神經圖靈機研究發表之前，創建適應性強的圖靈機的任務一直無法解決。
機器學習提供了獨特的能力，可以調整任何語法以覆蓋任何類型的攻擊，無需根據第一代檢測的要求手動創建簽名列表，也無需為新的攻擊類型（例如Memcached、Redis、Cassandra、SSRF 注入）開發新的分詞器/解析器，依照第二代方法的要求。
透過結合所有三代檢測邏輯，我們可以繪製一個新的圖表，其中第三代檢測由紅色輪廓表示（圖3）。 這一代包括我們與 Onsek 一起在雲端中實施的解決方案之一，Onsek 是 Web 應用程式和 Wallarm API 自適應保護平台的開發人員。
檢測邏輯現在使用來自應用程式的回饋來進行自我調整。 在機器學習中，這種回饋循環稱為「強化」。 通常，有一種或多種類型的此類強化：
- 應用響應行為分析（被動）
- 掃描/模糊器（主動）
- 報告文件/攔截程序/陷阱（事後）
- 手冊（由主管定義）
因此，第三代檢測邏輯也解決了準確性的重要問題。 現在不僅可以避免誤報和漏報，還可以偵測有效的真漏報，例如偵測控制面板中的 SQL 指令元件使用情況、網頁範本載入、與 JavaScript 錯誤相關的 AJAX 請求等。
接下來，我們將考慮各種WAF實施方案的技術能力。
硬體、軟體還是雲端——該選擇什麼？
實施應用程式防火牆的選項之一是硬體解決方案。 此類系統是公司在其資料中心本地安裝的專用計算設備。 但在這種情況下，你必須購買自己的設備並向整合商付費以進行設定和調試（如果公司沒有自己的IT部門）。 同時，任何設備都會過時且無法使用，因此客戶被迫為硬體升級制定預算。
部署 WAF 的另一個選擇是軟體實施。 該解決方案作為某些軟體的附加元件安裝（例如，ModSecurity 配置在 Apache 之上），並與其運行在同一台伺服器上。 通常，此類解決方案既可以部署在實體伺服器上，也可以部署在雲端。 它們的缺點是可擴展性和供應商支援有限。
第三個選項是從雲端設定 WAF。 此類解決方案由雲端提供者作為訂閱服務提供。 公司不需要購買和配置專門的硬體；這些任務落在服務提供者的肩上。 重要的一點是，現代雲端 WAF 並不意味著將資源遷移到供應商的平台。 該網站可以部署在任何地方，甚至可以部署在本地。
我們將進一步解釋為什麼人們現在越來越關注雲端 WAF。
WAF在雲端可以做什麼
從技術能力來看：
- 提供者負責更新。 WAF 透過訂閱提供，因此服務提供者會監控更新和授權的相關性。 更新不僅涉及軟體，還涉及硬體。 提供者升級伺服器園區並對其進行維護。 它還負責負載平衡和冗餘。 如果WAF伺服器發生故障，流量會立即重新導向到另一台機器。 合理的流量分配可以避免防火牆進入故障開啟模式的情況 - 它無法應對負載並停止過濾請求。
- 虛擬補丁。 虛擬修補程式會限制對應用程式受損部分的訪問，直到開發人員關閉漏洞。 因此，雲端供應商的客戶有機會平靜地等待這個或那個軟體的供應商發布官方「修補程式」。 盡快完成此任務是軟體供應商的首要任務。 例如，在Wallarm平台中，一個單獨的軟體模組負責虛擬修補程式。 管理員可以新增自訂正規表示式來阻止惡意請求。 該系統可以使用「機密資料」標誌來標記某些請求。 然後它們的參數被屏蔽，並且在任何情況下都不會傳輸到防火牆工作區域之外。
- 內建週邊和漏洞掃描器。 這可讓您使用 DNS 查詢和 WHOIS 協定中的資料獨立確定 IT 基礎架構的網路邊界。 之後，WAF自動分析邊界內執行的服務（執行連接埠掃描）。 此防火牆能夠偵測所有常見類型的漏洞 - SQLi、XSS、XXE 等 - 並識別軟體配置中的錯誤，例如，未經授權存取 Git 和 BitBucket 儲存庫以及對 Elasticsearch、Redis、MongoDB 的匿名呼叫。
- 透過雲端資源監控攻擊。 通常，雲端提供者擁有大量的運算能力。 這使您能夠高精度、快速地分析威脅。 雲端部署了過濾節點集群，所有流量都經過過濾節點集群。 這些節點阻止對 Web 應用程式的攻擊並將統計資料傳送到分析中心。 它使用機器學習演算法來更新所有受保護應用程式的阻止規則。 這種方案的實作如圖所示。 4. 這種量身定制的安全規則最大限度地減少了防火牆錯誤警報的數量。
現在簡單介紹一下雲端WAF在組織問題和管理方面的特點：
- 過渡到營運支出。 就雲端 WAF 而言，實施成本為零，因為提供者已支付所有硬體和許可證的費用；服務費用透過訂閱支付。
- 不同的資費計劃。 雲端服務用戶可以快速啟用或停用其他選項。 功能透過單一控制面板進行管理，這也是安全的。 它透過 HTTPS 訪問，此外還有基於 TOTP（基於時間的一次性密碼演算法）協定的雙重認證機制。
- 透過 DNS 連接。 您可以自行變更 DNS 並設定網路路由。 為了解決這些問題，無需招募和培訓個別專家。 通常，提供者的技術支援可以幫助進行設定。
WAF 技術已經從使用經驗規則的簡單防火牆發展到使用機器學習演算法的複雜保護系統。 應用程式防火牆現在提供了在 90 年代難以實現的廣泛功能。 在許多方面，由於雲端技術，新功能的出現成為可能。 WAF 解決方案及其組件不斷發展。 就像資訊安全的其他領域一樣。
此文字由雲端提供者 #CloudMTS 的資訊安全產品開發經理 Alexander Karpuzikov 撰寫。
來源： www.habr.com