如何為應用程式實施第 7 層 DDoS 防護

大多數遭受應用程式層攻擊的團隊都已部署了分散式阻斷服務防護。然而，防護並未涵蓋正確的層級。第 7 層分散式阻斷服務防護解決的問題與網路層防禦的問題根本不同，將兩者視為可互換的，是生產環境中最常見且代價高昂的基礎設施錯誤之一。.

層級分離是一項架構決策，而不僅僅是分類

L3/L4 防護——BGP黑洞、任播清洗、SYN洪水保護——基於封包量和通訊協定行為進行運作。它們非常擅長吸收 100 Gbps 的 UDP 放大攻擊或 SYN 洪水，因為這些攻擊僅憑數量就可與合法流量區分開來。硬體可以在線速率處理它們，而無需理解封包的內容。.

L7 攻擊有所不同。HTTP 洪水、慢速 POST、快取繞過掃描或認證填充攻擊，看起來都像是有效的 TCP 連線，並配有格式正確的 HTTP 標頭。封包一個接一個抵達，從網路角度來看，每一個封包都是合法的。直到目標伺服器崩潰，基於流量的系統才發現異常。.

建築上的後果是不可協商的：L7 檢查需要一個完整的內嵌 HTTP 代理。. 你無法通過 BGP 流量轉發來帶外清除應用程式層攻擊——因為僅能看到封包流量的網路清除中心無法檢查請求主體、標頭和會話模式。如果你的 DDoS 供應商沒有終止每一個 HTTP 連線並將乾淨的請求代理到你的來源伺服器，那麼無論供應商儀表板上顯示什麼，你都沒有任何 L7 保護。.

那不像攻擊的攻擊

最危險的 L7 模式也最少被討論： 快取旁路攻擊.

攻擊者若能了解你的應用程式的快取金鑰結構——而大多數 CDN 的快取行為都是公開可見的——就可以精心設計請求，系統性地避開快取的內容。最簡單的版本是附加一個隨機的查詢參數（?v=7f3a2b, ?t=1718290000) 向每個要求。更具針對性的版本會輪播 Accept-Language 標頭, Accept-Encoding 價值觀，或 X-Forwarded-For 擊敗快取正規化規則的地址.

結果：每次請求都會傳遞到源站。沒有 CDN 快取命中。沒有邊緣吸收。在每秒 5,000 次請求的速率下 — 這產生的頻寬不到 50 Mbps — 中等級別的應用程式伺服器可在兩到三分鐘內耗盡其資料庫連線集區。源站回應時間退化，連線佇列堆積，健康檢查開始失敗，負載平衡器將節點標記為不健康。.

從 L3/4 監控儀表板來看，這似乎是一個小幅的流量上漲。沒有觸發頻寬警示。沒有越過封包傳輸率的閾值。等到操作人員注意到來源錯誤率上升時，應用程式已經無法使用。.

根據 SIRAYA 在亞太地區部署環境中的觀察，由於團隊將監控重點放在頻寬圖表上，而非源伺服器連線深度與快取命中率，因此這種模式往往被低估。 在五分鐘內，快取命中率從 92.1% 驟降至 15.1%，這才是真正的先行指標——而大多數團隊並未設定此類警示。.

API 的終端盲點

還有另一種失敗模式同樣值得關注。WAF 產品透過 JavaScript 驗證機制來保護網頁應用程式：CDN 會傳送一段輕量級的 JavaScript 程式碼片段，驗證瀏覽器能否執行該程式碼，然後發放一個通行 cookie。瀏覽器會自動通過這項驗證，但無法執行 JavaScript 的機器人則無法通過。.

這對 HTML 應用程式效果良好。但對於 API 端點，則完全無法運作。.

你的 /api/v1/authenticate 端點、您的 GraphQL 端點、您的 webhook 接收器——這些都不是由瀏覽器在渲染網頁時所呼叫的。它們是由行動應用程式、後端服務、自動化客戶端所呼叫的，同樣地，也由憑證填充工具和 API 洪水攻擊腳本所呼叫。 在 API 端點上實施 JS 驗證機制，不僅會破壞您的合法整合，更無法對那些本就不遵守此規則的機器人提供任何防護。.

一種會造成此安全風險的常見部署模式：在主要網域上配置了 WAF 及機器人管理規則，其中 /api/* 這些路徑要麼被排除在挑戰規則之外，要麼由一個完全缺乏 WAF 覆蓋範圍的獨立來源處理。而 API 端點——這些端點通常是資料外洩、帳戶接管及服務中斷最具價值的攻擊面——則處於暴露狀態。.

對於 API 路徑，第 7 層 DDoS 防護需要一套不同的工具組：以驗證過的安全憑證或 API 金鑰（而非 IP 位址）為範圍的速率限制、 TLS 指紋分析（使用 JA3/JA4 簽名識別非瀏覽器客戶端）、請求正文異常檢測，以及針對實際流量基準（而非全域預設值）所調整的各端點 RPS 閾值。.

為何基於 IP 的速率限制在亞太地區規模擴大時會失效

基於 IP 的速率限制是大多數團隊優先考慮的第一個控制措施，而在許多亞太地區的部署中，它反而會帶來更多問題，而不是解決問題。.

東南亞、韓國和中國部分地區的行動網路營運商使用大型的網路位址轉譯 (CGNAT)。成千上萬的合法使用者可以共用單一的公開 IP 位址。為封鎖頻繁爬蟲而設的 IP 速率限制，會觸發行動網路營運商的主要 IP 區塊，在中途攔截真實使用者的合法流量。這會顯示為 429 錯誤的突然激增，且集中在行動裝置使用者群段——這常被歸咎於 CDN，有時歸咎於應用程式，很少追溯到速率限制設定。.

與此同時，一個資金雄厚的攻擊者如果透過住宅代理網絡發動攻擊，其攻擊流量將分散在數萬個IP位址上，讓每個IP位址的個別請求速率都低於任何能同時解決CGNAT問題的閾值。.

在應用層，更為穩健的做法是依據經過驗證的連線、API 憑證或行為指紋來實施速率限制，而非依據 IP 位址。對於無法採用上述方法的未驗證終端，應考慮採用較短時間窗的突發流量限制，並結合漸進式驗證強度提升機制，而非對每個 IP 位址實施硬性限制。.

零網邊緣保護的原始 IP 洩漏

若攻擊者已知曉您的源伺服器 IP 位址並直接鎖定該目標，即使部署了具備完整 WAF 及 L7 DDoS 防護功能的 CDN，也無法提供任何保護。.

原始 IP 位址比大多數團隊想像的更容易被發現。歷史 DNS 記錄（CDN 遷移之前）、SSL 憑證透明度日誌、應用程式層級錯誤訊息中留下的 IPv6 位址、CDN 未涵蓋的子網域上的 A 記錄，或錯誤設定的暫存環境的回應——任何這些都可能暴露原始位址。攻擊者在發動應用程式層級攻擊之前，通常會例行性地列舉這些位址，特別是為了繞過邊緣保護。.

修復方法是將來源 IP 隱藏視為 L7 DDoS 防護架構的一項硬性要求，而非錦上添花。在防火牆層級，僅接受來自 CDN 提供者已發布 IP 範圍的入站 HTTP/HTTPS 連線，並拒絕所有其他連線。對於更高安全性的設定，請完全以出站通道（Cloudflare Tunnel、AWS PrivateLink 或同等技術）取代直接暴露來源，這樣來源根本無需接受公開的入站連線。.

選擇合適的防禦架構

實際的決定不是「L3/4 或 L7」——而是了解哪個層代表您主要的攻擊面。.

如果您經營的基礎設施因其性質（例如大型 DNS 解析器、金融交易平台、處理大量連線的遊戲平台）而成為流量攻擊的目標，那麼您就需要能夠處理大量流量的 L3/4 層級的 anycast 網路解決方案，並將其部署在所有其他服務的上游。.

如果您正在運行一個網路應用程式或 API，L7 層幾乎可以確定是風險最集中的地方。一個中型應用程式是不會遭遇 500 Gbps 的 UDP 洪水攻擊的。 它可能會面臨每秒 30,000 次發送至未經身份驗證的密碼重設端點的 HTTP 請求，或是 8,000 個佔用所有可用工作執行緒的慢速連線，又或是旨在耗盡您的搜尋索引查詢配額的針對性爬取攻擊。.

對於大多數網路和 API 工作負載而言，在 CDN 邊緣實施的 L7 內聯防護，所涵蓋的實際攻擊面比僅靠 L3/4 過濾更為廣泛。. 兩個層級結合起來是生產級的解決方案，但如果必須考慮成本或營運複雜性來優先考慮覆蓋範圍，那麼應用程式層就是現代攻擊的著力點。.

SIRAYA 針對部署於亞太地區的應用程式所推薦的一種常見架構，採用三層架構：第一層為整合了 WAF 及機器人管理功能的 Anycast CDN 邊緣節點，作為首個接觸點；第二層為負載平衡器層的源伺服器級連線速率限制（設定為保守值以避免 CGNAT 誤判）， 以及在 API 閘道層針對已驗證的 API 路徑實施的端點級速率限制。各層級負責處理其最擅長偵測的威脅；不期望單一層級能阻擋所有攻擊。.

WAF 模式的部署風險

有一種運作失誤似乎以驚人的頻率發生：部署於「偵測」或「僅記錄」模式的 WAF 規則集，在流量激增之前從未被提升至「阻擋」模式。.

這種考量可以理解——團隊在嚴格執行規則之前，希望先觀察到誤報的情況。但「偵測模式」並非防護措施，而是監控機制。在面臨真實攻擊的生產環境中，一個僅記錄事件而不進行阻擋的 WAF 系統，只會為事後報告增添內容，而非預防事件發生。.

較佳的運作做法是，先在風險較低的終端點（如靜態資產路徑、文件頁面）以區塊模式部署並進行監控，隨後逐步將規則執行範圍擴展至敏感度較高的路徑，例如驗證及 API 終端點。此舉可在觀察期間建立對規則調校的信心，同時避免讓整個應用程式暴露於風險之中。.

第 7 層 DDoS 防護並非買了就能置之不理的產品。這是一項必須配合您特定應用程式的流量模式、API 架構、驗證模型以及用戶地理分布所進行的配置。 在真實的針對性攻擊下，預設設定極少能發揮作用。能夠抵禦攻擊的團隊，是那些已根據自身基礎流量調整規則、精確掌握負載下的快取行為，並在攻擊者開始搜尋之前就已隱藏原始伺服器的團隊。.