解鎖網路應用程式防火牆的精髓：從新手到進階

解鎖網路應用程式防火牆的精髓：從新手到進階

這篇部落格文章是我們最近一次網路研討會的重點回顧，解答了以下問題：

如何能快速部署一個基本的網頁應用程式防火牆 (WAF)？
WAF 應如何正確配置？
有哪些進階技術可以用來強化 WAF 的安全性？

本次網路研討會將討論基本的 WAF 概念，並提供更深入的了解，教您如何有效地部署、配置、優化和運營 WAF。

觀看 WAF Essentials Unlocked: 從初學者到進階者所需的一切的網路研討會錄影。

WAF 101 (簡介)

在現代應用程式安全的環境中，WAF（Web Application Firewall）是網頁應用程式的一個關鍵安全層。對於不太熟悉的人來說，WAF是一種安全設備，能夠過濾、監控和阻擋網路流量（HTTP）。值得一提的是，一個好的WAF也是雙向的：它除了可以檢查進入應用程式伺服器的請求流量外，還可以（選擇性地）檢查返回給客戶端的回應流量。

A WAF（網路應用程式防火牆）位於特定網路應用程式的使用者與應用程式伺服器之間。WAF 的佈局相當靈活：可以放在公有雲中、在靠近網頁伺服器的 DMZ 中，甚至可以直接安裝在網頁伺服器上。從圖形上看，情況大致如下：

負載均衡器與WAF

很常見的是，WAF會與負載均衡器（反向代理）一起包裝供應。在進行完整的第七層（應用層）負載均衡時，將HTTP流量透過WAF引擎來傳遞相對簡單，並能獲得其防禦與安全性的好處。

負載平衡層可以處理以下事項：

TLS 終止（僅將明文 HTTP 傳送到 WAF 引擎）
伺服器負載平衡（跨可擴展的網頁伺服器集群）
高可用性（協助維持關鍵服務的可用性）

深度防護

在資訊安全的領域中，深度防禦的概念廣泛應用。其核心原則是，確保系統（如網頁應用程式）安全的最佳方式是使用多個獨立的安全層，就像是一個多層的洋蔥一樣：在現實世界中，沒有任何單一的安全措施是完美的，這也包括WAF（Web Application Firewall）。如果有一個或多個安全措施被繞過，那麼還有多層額外的防禦層可以阻止攻擊。WAF是現代網頁應用程式中一個重要的防禦層，尤其是對於那些暴露於更廣泛公網的應用程式。

“強制性的WAF”

假設有這樣的情境：一位部門主管或團隊負責人轉過身來說，「我們需要在我們的網頁應用程式前面安裝一個 WAF（Web Application Firewall）. 我們新的安全政策規定如此。請讓這件事實現。」這是一個「強制性的 WAF」部署：它必須被部署，而且很可能這項任務不會額外提供時間或資源來讓它成為現實。

當企業的IT政策更新時，可能會增加一項新要求，例如「所有面對外部的網路應用程式必須配置WAF以確保安全性。」同樣地，滿足外部安全標準的需求，如PCI DSS，也可能產生類似的效果，因為它們為網路應用程式定義了類似的WAF需求。

這類安全需求要求部署 WAF 通常需要三個要素：

WAF 必須能夠偵測威脅
WAF 必須在事件發生時記錄偵測到的事件
WAF 必須具備封鎖的能力

有趣的是，部署和設定 WAF 的具體細節幾乎總是沒有明確說明。這部分通常是交給負責部署 WAF 的人去判斷。安全標準中幾乎不會定義 WAF 應該使用什麼樣的敏感性等級或是 WAF 規則集應該有多激進。只要 WAF 符合上述三個要點，應該就能滿足大部分「強制性 WAF」的情境。

快速簡單的「Mandated WAF」與 LoadMaster

使用LoadMaster解決方案部署這種WAF快速又簡單。部署的過程如下：將LoadMaster解決方案指向應用伺服器，然後啟用WAF引擎：
設置虛擬服務（簡單的應用層反向代理）大約需要 60 秒：定義客戶端將連接的 IP 位址，定義應用伺服器的 IP 位址，然後就完成了。

啟用 WAF 引擎非常簡單，只需在網頁介面中展開「WAF」選項，並勾選啟用框，如下所示：

就是這麼簡單！讓我們來檢視需求清單：

WAF 必須能夠偵測威脅 ✅
- 一旦勾選「啟用」，此項目即完成
WAF 必須在偵測事件發生時進行紀錄 ✅
- 所有偵測事件都會寫入 WAF 日誌
WAF 必須具有阻擋的能力 ✅
- 一旦勾選「啟用」，此項目即完成（並且可以稍後進行微調）

接下來的步驟：一個「有牙的WAF」

在超越基本的「強制性」WAF 部署之後，可以為其增添一些「強制力」，以創造出更具體、強健的安全層。這需要滿足一些前提條件，但對於大多數部署 WAF 的人而言，仍然在可達範圍內。
提升 WAF 提供的安全層級的前提條件：

確定需要的安全等級
了解網頁應用程式及其流量（至少要了解一點）
時間，來:
- 制定計畫
- 實驗 WAF
- 紀錄部署過程

確定適當的安全級別

大部分的 WAF 都採用或者至少提供 OWASP CRS 規則集：這包括 LoadMaster WAF。OWASP CRS 是一套事實上被廣泛使用的免費且開源的 WAF 規則，並由 OWASP 基金會發佈。
CRS WAF 規則分為四個「偏執等級」類別，每個等級提供不同程度的安全防護：

最低級別的「偏執程度 1」（PL 1）是簡單且不具爭議的 WAF 規則的一個子集，這些規則不易導致誤判（也就是說，這個規則子集很少會因合法的網路流量而錯誤地被觸發）。

升級到 PL 2 會增加一層額外的規則。這些額外的規則提供更廣泛的檢測範圍，但同時也帶來了更高的複雜性，增加了遇到誤報的可能性。

PL 3 增加了更加激進且容易出錯的規則。最後，在 PL 4，所有規則都會生效，包括那些最具侵略性的規則。PL 4 提供了非常高的安全性，但同時也會產生非常多的誤報需要處理。

在安全性與可用性之間找到合適的平衡是非常重要的。雖然「強制性 WAF」在 PL 1 時可能已經能夠提供足夠的保護，但面對公開於網際網路的實際網頁應用程式，預設應該提供 PL 2 的保護。這個層級能夠提供良好的安全防護，同時不會讓 WAF 團隊不得不處理過多的誤報。

高風險及敏感環境（例如：銀行、電廠、電子投票）可能會使用 PL 3 和 PL 4，但是像這樣的專業、高警戒層級部署通常需要大量的時間和諮詢才能正確運行。高安全性的代價就是需要花費大量時間來駕馭這些在高警戒層級中極為嚴格的規則。

了解網頁流量

使用中的技術

被保護的網頁應用程式使用了哪些技術？它有使用 PHP 嗎？有使用任何 Java 嗎？是否涉及資料庫？WAF 的偵測規則被分成不同的類別。如果其中某些類別不相關，則可以將其關閉：這樣可以將規則移除，並避免之後出現誤報。

請求內容檢查

檢查HTTP請求的主體是否重要？雖然HTTP請求行和請求標頭是預設會被檢查的，但解析和檢查請求主體則是可選的。

對於典型的 WAF 部署，這個選項 應該啟用，位置在 LoadMaster 解決方案的 WAF > 進階設定中：

這在保護API時特別重要，因為它允許解析和檢查JSON和XML的負載。

在「進階設定」頁面上：應該檢查多少身體數據？這個設定應該盡量保持在最低限度，以避免因為過度佔用 CPU 而讓 WAF 面臨拒絕服務攻擊的風險。

對於生產環境來說，16 KkB 的主體大小限制可能是合理的，不過有時為了相容性原因，可能需要更大的限制。

合法流量看起來是什麼樣的？

應該允許哪些 HTTP 方法呢？預設允許的方法有 GET、HEAD、POST 和 OPTIONS。有些網頁應用程式可能需要額外的方法，例如 PUT、DELETE 或一些其他不常見的方法。

哪些檔案副檔名應該被禁止？根據預設，惡意和看起來不尋常的檔案副檔名會被標記，例如「.bat」、「.config」和「.ini」。雖然這樣的情況不太可能發生，但如果有任何這些副檔名是合法需要的話，則應該對預設列表進行修正。

最後，哪些請求標頭欄位應該被禁止使用呢？一些舊版請求標頭已知容易被濫用，例如「accept-charset」，它可以用來透過 WAF 走私有效負載而不被發現（如果請求了一種奇特的字元編碼，而 WAF 無法讀取，可能會導致它失明！）。如果任何預設禁止的標頭是合法需要的，那麼這個清單應該被修正。

使用我們的 LoadMaster WAF 模板

為了讓這個過程儘可能簡單，我們提供了一個新的範本，其中包含上述所有步驟，呈現為易於跟隨的問卷形式，同時附上文件說明、背景資訊、預設設定列表以及建議。

WAF 調整 (簡介)

當合法的 HTTP 請求錯誤地觸發了 WAF 規則時，這被稱為誤報（false positive）。

誤報會引發多種問題：它們造成不佳的使用者體驗，讓真正的攻擊偵測和阻止變得困難，並且可能導致合規性問題。如需深入了解誤報及其解決方案，請參考我們最近的部落格文章：什麼是 WAF 誤報，為什麼我需要關心，還有我該如何解決它們？

總而言之，必須透過調整執行問題規則的時間與條件來消除假陽性。LoadMaster 360 平台提供了一系列自動化工具來協助這個過程。首先，會檢查 WAF 日誌，並自動標記出最有可能為假陽性的候選項，以引起注意：

這可以處理潛在數十萬行的日誌資料，並挑選出十幾個可能的假陽性候選項，供人員檢視。這是透過使用智慧過濾器來實現的，可以為操作人員節省大量時間。

一旦確認了錯誤正回饋，LoadMaster 360 也會自動寫入調整配置，來排除這個錯誤正回饋：

這樣一來，就不需要學習任何 WAF 配置語言，這對於未經 WAF 訓練的操作人員來說，可能是一個主要的進入障礙。

一些進階的WAF概念分享

測試、測試、再測試

透過 WAF 測試應用程式是非常重要的。定期進行測試可以幫助減少未來可能出現的問題。例如，在更新網頁應用程式後運行自動化測試套件，可能會標記出由於應用程式內部新功能或變更而產生的新假陽性。在測試過程中標記出新問題，總比讓客戶在生產環境中遇到這些問題要好。

甚至進行一個非常簡單的測試也能回答那個普遍的問題：「我的 WAF 有在運作嗎？」透過 WAF 堆疊發送一個簡單的請求，例如：

my-app.local/foo?bar=/bin/bash

這足以觸發 Unix 命令注入規則並產生一個日誌條目。如果出現一個日誌條目，標記「/bin/bash」對應到測試機器的 IP 地址，那麼可以確認 WAF 正在正常運作（如前面提到的，「偵測威脅」和「記錄偵測事件」）。

虛擬補丁

考慮一種情況，其中一個後端網頁應用程式存在已知的安全漏洞，但無法進行修補。這種情況可能有許多原因，例如：

使用專有軟體時，供應商可能尚未釋出修復程式
政策或實際考量可能要求等待維護時間
該應用程式可能為舊版且無法獲得支援（但無法被淘汰）

這就是虛擬補丁可以發揮作用的地方。

如果漏洞的性質被充分理解，這通常是情況，那麼可能可以編寫自訂的 WAF 規則來偵測並阻擋攻擊嘗試。例如，如果某個漏洞需要向脆弱位置 /api/foo 發送特別精心設計的 HTTP POST 請求，則會有幾種可能的方法：

偵測特殊的有效載荷並在發現時封鎖
封鎖對 /api/foo 的 POST 請求（如果不會影響正常的應用程式運作）
移除對 /api/foo 的任何訪問（如果不會影響正常的應用程式運作，例如這是一個舊版或未使用的功能）
以上任意組合

這些做法都可以透過 LoadMaster WAF 引擎來實現。自訂規則相當於一個「虛擬補丁」，用來保護對網頁應用程式的存取，直到應用程式本身能夠完全且正確地進行補丁更新。

WAF 設定與部署 101 回顧

從一個「指定的 WAF」開始，設置快速又簡單。只需準備一台 LoadMaster 設備，將其指向需要保護的網頁伺服器，然後在 WAF 標籤中點擊「啟用」，就這樣：大部分要求必須有 WAF 的安全需求立即得到滿足。

讓 WAF 更具威力的方法是選擇適合的防範等級（安全等級）來運行。同時也需要對應用程式及其流量有一定的了解，並根據這些資訊來配置 WAF。

當假陽性發生時，需要進行調整以排除它們。處理假陽性的方式有很多，這是一個龐大的主題（最近也有專門的部落格文章探討）。LoadMaster 360 自動完成許多繁重的工作，透過其智慧日志過濾器和自動規則調整工具來協助用戶。

最後，有幾個進階的想法可以擴展 WAF 的功能和可用性。測試是關鍵，因為應用程式在經過 WAF 時必須正確運作。不僅僅是今天的應用程式版本，還包括下一個修補版本以及之後的每一個版本。自動化測試套件可以提供幫助。對於無法對軟體漏洞進行修補的情況，虛擬補丁可以填補「目前有漏洞」和「明天完全修補」之間的差距。

這一切，甚至更多，都可以透過 LoadMaster 負載平衡器來實現。

來試用我們的 30天免費試用，看看這是否符合您作為使用者友善的負載均衡器及內建WAF的需求。

如果你有任何問題，隨時聯絡我們，我們很樂意在你的負載平衡及 WAF 旅程中提供支援。

文章來源: Unlocking Web Application Firewall Essentials: From Beginner to Advanced