什麼是 WAF？| Web 應用程式防火牆解說

在 WAF 技術出現的同時，OASIS Web 應用程式安全技術委員會 (WAS TC) 的弱點工作也擴展為 開放式 Web 應用程式安全專案 (OWASP) 的十大名單。幾十年後的今天，OWASP Top 10 仍然是 Web 應用程式安全合規性的業界標準。

WAF 和 OWASP Top 10 這兩項發展加起來，為我們提供了防禦措施，協助阻止威脅行為者試圖入侵我們的系統、消耗我們的資源和竊取我們的資料。

WAFs：重要的安全元件

由於 Web 應用程式受到攻擊是導致資料外洩的主要原因，因此保護應用程式和 API 一直是應用程式安全工程師、安全架構師和資訊安全專業人員最關心的問題。由於應用程式在釋出時經常會出現 OWASP Top 10 漏洞，因此 Web 應用程式安全標準必須整合至 軟體開發生命週期 (SDLC)。

網路應用程式防火牆提供了一層網路防火牆無法達到的安全性，從而發揮保護漏洞不被利用的作用。傳統的網路防火牆根本無法保護面向網路的應用程式，因為這些應用程式需要接受並回應來自網際網路的網頁內容要求。

WAF 透過提供過濾網路流量的方式解決問題，同時仍允許應用程式直接連線至網際網路。WAF 並非在內部與外部網路資源之間建立一堵牆，而是像螢幕一樣發揮功能，讓友善的流量通過，但阻擋惡意的流量。

如此一來，WAF 有助於防範一些常見的 Web 應用程式 安全風險，例如設計不當的應用程式和注入式攻擊。雖然 WAF 無法修復 Web 應用程式中的基本弱點或瑕疵，但它們可以防止試圖利用這些瑕疵的攻擊到達應用程式。WAF 可阻止初始探測、阻斷常見的攻擊途徑並限制請求的速率，從而對攻擊者造成挑戰。

此外，Web 應用程式防火牆可以記錄 Web 應用程式流量、攻擊嘗試和企業為保護其 Web 應用程式安全所採取的步驟 - 所有這些都支援稽核和合規性活動。

瞭解威脅形勢

在討論有效的 Web 應用程式防火牆的關鍵元件之前，讓我們先考慮針對 Web 應用程式的不同類型威脅。我們已經提到 XSS、SQL 插入和本機檔案包含。最初應用程式防火牆的目標是防禦這些類型的攻擊，但戰場已經改變，並在不斷地演進。

隨著隨選雲端運算的普及，拒絕服務 (DoS) 攻擊 或 DoS 與 DDoS 攻擊 也變得越來越頻繁。

最新的 OWASP Top 10 名單中現在包含了更多與存取控制和組態相關的風險。破壞存取控制和加密失敗佔據了 2021 年清單的前兩名。從安全設定錯誤到元件過時等相關問題也增加了。除了保護您的服務不受攻擊外，您還需要防止敏感資料意外暴露。

有效 Web 應用程式防火牆的功能

網路應用程式防火牆透過一系列規則或政策運作，這些規則或政策的設計目的是透過監控和過濾使用網路通訊協定 (尤其是 HTTP 和 HTTPS) 的網路流量，以防範網路應用程式的漏洞。

我們可以將 WAF 的功能分為兩個截然不同的部分：保護入站和出站流量。WAF 的入站保護功能負責檢查來自外界的應用程式流量。作為保護 Web 應用程式免受入站流量影響的一部分，WAF 需要識別危險的活動模式、可疑的有效負載和漏洞。

由於駭客不斷創新，入站攻擊的性質也隨之改變。WAF 需要根據一套主動的安全政策來運作，以防範 Web 應用程式中的已知弱點。為了濾除各種類型的惡意流量，每項安全政策都必須保持最新，與不斷演進的攻擊媒介同步。Web 應用程式防火牆特別有效，因為它們是針對安全政策修改而設計的。

出站防護就是防止企業和客戶資料外洩。儘管在現實世界中準確地解析出站資料具有挑戰性，但以 Proxy 為基礎的內嵌式 WAF 可以攔截出站資料，並遮蔽或阻止敏感資料因意外或惡意方式而外洩。

不同類型的 Web 應用程式防火牆

使用 WAF 保護 Web 應用程式時，您可以根據特定條件定義允許、封鎖或監視 Web 請求的規則。例如，您可以自訂 WAF 規則，以封鎖包含特定 HTTP 標頭或來自特定 IP 位址的傳入請求。

封鎖清單與允許清單 WAF

從分類的角度來看，Web 應用程式防火牆可根據其工作方式加以區分。blocklist WAF 基於負向安全模型，而 allowlist WAF 則遵循正向安全模型：

• 封鎖清單 WAF 旨在封鎖特定端點或流量類型，並允許所有其他端點或流量類型。
• Allowlist WAF 的運作方式與 blocklist WAF 有些相反，預設會封鎖所有流量，只允許經過明確核准的流量通過。

Allowlist WAF 被視為更安全，因為它們可將惡意流量因防火牆規則設定不當而逃過防禦的風險降至最低。儘管如此，在您無法預測所有有效流量類型或端點的情況下，允許清單 WAF 的效果並不理想。

鑑於這兩種 WAF 的優缺點，現在許多 WAF 採用混合式「允許清單-封鎖清單」安全模式運作也就不足為奇了。

網路型、主機型和雲端型 WAF

WAF 可根據其部署模式進行分類 - 網路型、主機型和雲端型。

• 網路型：以網路為基礎的 WAF - 採用硬體裝置的形式，必須取得授權並進行維護 - 在網路基礎架構 (例如交換器) 上運作，位於應用程式與網際網路之間。
• 主機型 WAF：主機型 WAF 位於 Web 應用程式所在的伺服器上。由於它們是部署為應用程式作業系統的一部分，因此它們使用作業系統層級的過濾功能來過濾傳遞至網路應用程式的流量，可以輕鬆地大規模擴展。
• 雲端 WAF：雲端託管的應用程式可以使用雲端 WAF，它會與雲端虛擬網路服務或負載平衡器整合，以過濾網路流量。雖然雲端 WAF 不需要龐大的團隊來部署或維護，但通常無法提供完整的威脅情境。

企業使用的 WAF 部署模式部分取決於其網路應用程式的位置。舉例來說，雲端 WAF 只有在應用程式部署在雲端時才會運作。如果在選擇部署模式時要考慮維護問題，以網路和主機為基礎的 WAF 通常需要較多的設定和管理，而以雲端為基礎的 WAF 只需要變更 DNS 或 Proxy 即可。

WAF vs. 其他安全工具

Web 應用程式防火牆提供的功能使其與其他防火牆和安全解決方案相比獨一無二，但它們並非要作為包羅萬象的安全工具。事實上，WAF 並不是為了抵擋所有類型的攻擊而設計的。Web 應用程式防火牆只是安全性的其中一個組成部分，其設計目的在於補充整合式工具套件，以提供整體性的防禦，抵禦所有可以想像到的攻擊媒介。

WAF vs. 傳統防火牆

傳統防火牆的設計目的是定義一個邊界，將在內部網路運作的資源與直接連接到網際網路的資源分隔開來。WAF 更為細微，它們允許應用程式與網際網路連線，同時仍提供一層防護。

WAF vs. 下一代防火牆

下一代防火牆 (NGFW) 是一種應用程式防火牆，結合了傳統網路防火牆和 WAF 的最佳功能。除了透過檢查網路層封包來封鎖進入的請求之外，NGFW 還擁有檢查功能，可以封鎖私人網路中不需要的流量。

雖然 NGFW 和 WAF 功能重疊，但主要差異在於它們的核心責任模式。下一代防火牆可擷取更多網路流量情境，並執行使用者為基礎的政策，以及增加必要的功能，例如防毒和防惡意軟體。此外，透過在安全政策中加入情境，NGFW 可以結合威脅情報引擎來協助決策過程。

相比之下，WAF 僅限於應用程式層。它們專門防止常見的網路攻擊，例如 XSS 或 DDoS 攻擊，因此對於保護面向網際網路和雲端原生應用程式的安全至關重要。

但從 Proxy 的角度來看，最能了解這兩種技術的主要差異。伺服器使用的 WAF 幾乎都是反向代理。NGFW 由用戶端使用，其設計目的是保護用戶端，因此在大多數情況下，NGFW 都是前向代理。

WAF vs. 入侵防護系統

與 WAF 相似，入侵防護系統 (IPS) 旨在識別和封鎖惡意網路流量。不過，IPS 的設計可以過濾所有通訊協定中的所有類型流量。

儘管如此，WAF 在偵測透過 Web 通訊協定運作的複雜攻擊方面，通常提供更精密的能力。IPS 解決方案通常依賴一般攻擊識別碼 (特定類型的封包或流量模式)，而不會廣泛使用情境資料 (歷史流量模式或使用者行為模式) 來判斷哪些流量可能是惡意的。

如何部署 Web 應用程式防火牆

WAF 的部署方式有幾種，取決於應用程式的部署地點、所需的服務、管理方式，以及所需的架構彈性和效能等級。

需要考慮的問題：

• 您要自己管理 WAF，還是要將管理外包？
• 雲端模式是更好的選擇，還是您希望您的 WAF 在內部部署？

您想要如何部署將有助於決定哪一種 WAF 適合您。接下來您需要決定如何將 WAF 整合到您的網路應用程式網路堆疊中。您有三種方法可供選擇：

• 透明橋樑：在透明橋接模式中，WAF 與其保護的 Web 應用程式綁定到相同的連接埠。從 Web 應用程式和連線到這些應用程式的用戶端的角度來看，似乎並沒有安裝防火牆，但是連接埠綁定在幕後運作，允許 WAF 攔截流量，並決定是否允許流量通過。
• 透明的反向代理：在透明反向代理方式下，Web 應用程式知道防火牆的存在，但客戶端並不知道。WAF 接受在外部端點看來是應用程式的連接埠和位址上的流量，但應用程式本身是在不同的內部連接埠和位址上運作。WAF 會檢查流量，並決定是否將流量轉送至這些連接埠和位址。
• 反向代理：反向代理是指用戶端將請求傳送至 WAF，WAF 在用於執行代理服務的連接埠或位址上運作，然後將請求轉發至應用程式。反向代理與透明反向代理類似，主要差別在於簡單的反向代理時，客戶端會知道代理伺服器的存在。

透明網橋模型最容易實作，因為它需要最少的網路綁定、位址和連接埠設定。但它無法在網路層級將 Web 應用程式與 WAF 隔離。Transparent reverse Proxy 和 reverse Proxy 提供更多的隔離性和能力，可在流量到達應用程式前檢查流量。

在部署 WAF 的步驟中，接下來就是選擇將其託管在何處。主要選項有

• 以雲端為基礎的全面管理服務：WAF 以全面管理服務的方式在雲端執行。使用者只需開啟並設定，除了設定所需的網路政策外，不需要任何管理。
• 雲端和自我管理：WAF 託管在雲端，但使用者負責部署、配置和管理。
• 雲端及自動佈建：WAF 託管在雲端。雖然使用者必須設定和管理它，但它會自動填入為配合雲端環境而設計的網路規則。此方法提供了完全管理與自我管理 WAF 選項之間的中間位置。
• 內部部署的進階 WAF：WAF 由內部部署的基礎架構託管。On-prem 涉及較多的設定工作，而且企業必須為 WAF 提供主機基礎架構。取捨是對 WAF 配置方式的更大控制權。
• 代理或無代理 主機型 WAF：WAF 在主機伺服器或應用程式容器上執行。使用者可能需要在每台伺服器上部署代理程式，以託管 Web 應用程式防火牆服務，但也有執行防火牆規則的無代理程式方式。

選擇 Web 應用程式安全解決方案時的注意事項

評估 Web 應用程式防火牆選項時要考慮的因素：

• 支援哪些部署模式？最好的 WAF 支援一系列部署選項，因此可以在內部部署或雲端運作，使用完全管理或自我管理的方式，視適合企業的選項而定。
• WAF 如何過濾流量？WAF 在評估流量時能夠考慮的情境越多，其偵測一般防火牆無法偵測到的複雜攻擊的能力就越強。
• WAF 需要多高的效率？所有 WAF 都應該有效率地運作，避免剝奪應用程式執行所需的基礎架構資源。

在選擇 Web 應用程式安全解決方案時，除了上述的考量之外，將可擴充性納入考量也是明智之舉。WAF 未來需要如何擴充？是否需要支援在混合和多雲架構中運作的應用程式？是否需要 支援 API？由於 API 對應用程式與使用者之間的通訊愈來愈重要，因此保護 API 以及 Web 應用程式的能力將變得至關重要。

Web 應用程式與 API 安全性 (WAAS) 的未來

建立在雲端原生架構上的現代網路應用程式比以往更加複雜。敏捷的開發流程、持續的整合與部署，以及不斷地演進的環境，為傳統的 WAF 帶來了新的挑戰。網頁 應用程式和 API 保護的 下一代是網頁應用程式和 API 安全性 (WAAS)。

WAAS 包括傳統 WAF 功能，例如自動發現 Web 應用程式。它還能進一步發現環境中的所有 API 端點。此方法可簡化安全規則的設定， 以保護您的 Web 應用程式和 API ，或更新環境中的現有應用程式。

透過自動偵測並保護您的 Web 應用程式和 API，您也可以降低應用程式可能被設定錯誤或在沒有保護的情況下部署的風險。

有效的 WAAS 解決方案會接受各種格式的 API 規格，例如 Swagger 和 OpenAPI，並使用這些定義來篩選請求，以判斷是否符合規格。有些端點可能需要較少的保護和較大的存取權限，而處理敏感資料的端點則需要最高等級的保護和審查。此外，WAAS 解決方案包含開箱即用的 DoS 保護。

選擇應用程式安全解決方案時，您應該考慮的其他功能包括根據來源地來篩選請求的能力。您也希望能夠透過自訂規則，自訂每個應用程式或 API 應用的防禦措施等級。您可能還想要根據嚴重性和潛在風險的組合來設定每個應用程式的警示和錯誤報告等級。

為未來保護您的應用程式

隨著雲端運算在產業中的地位日漸鞏固，雲端原生應用程式也不斷地激增，其重要性與複雜性也與日俱增。安全性必須具備與動態威脅環境一樣快速演進的能力。

資訊安全性專業人員 - DevOps 工程師、安全性架構師及應用程式安全性團隊 - 將需要相互合作並汲取彼此的經驗，以建立能夠防禦現代企業的全面的安全性策略。

WAF 常見問題