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

大多數遭受應用層攻擊的團隊，其實已經部署了 DDoS 防護。問題只是防護並未涵蓋正確的層級。第 7 層 DDoS 防護所解決的問題，與網路層防禦有本質上的不同；將兩者視為可以互換，是生產環境中最常見且代價高昂的基礎架構錯誤之一。

層級區分是一項架構決策，而不只是分類

L3/L4 防禦——BGP 黑洞路由、Anycast 清洗、SYN 洪水防護——是根據封包量與協定行為運作。它們非常適合吸收 100 Gbps 的 UDP 放大攻擊或 SYN 洪水攻擊，因為這些攻擊僅憑流量大小就能與合法流量區分。硬體可以在線速下處理它們，而不需要理解封包內容。

L7 攻擊則不同。HTTP 洪水攻擊、慢速 POST、繞過快取的掃描，或憑證填充攻擊，看起來都像是具有格式正確 HTTP 標頭的有效 TCP 連線。封包逐一抵達，從網路角度來看，每一個封包本身都是合法的。以流量為基礎的系統在來源伺服器崩潰之前，看不出任何異常。

其架構上的結論是不容妥協的：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% 降到 15%，才是真正的領先指標——而多數團隊並未設定這項警報。

API 端點盲點

第二種失效模式同樣值得關注。WAF 產品會使用 JavaScript 挑戰來保護 Web 應用程式：CDN 提供一段輕量的 JS 程式碼片段，驗證瀏覽器能夠執行它，然後發放通行 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 為基礎的速率限制是多數團隊首先採用的控制措施，但在許多亞太地區的部署中，它造成的問題往往比解決的問題更多。

東南亞、南韓以及中國部分地區的行動電信網路使用大規模電信級 NAT（CGNAT）。數千名合法使用者可能共用同一個公用 IP 位址。若以 IP 為基礎的速率限制被調整為阻擋激進爬蟲，就會在主要行動電信業者的 IP 區段上觸發，導致真實使用者在工作階段中途的合法流量被丟棄。這通常表現為行動使用者族群中 429 錯誤突然飆升——常被歸咎於 CDN，有時歸咎於應用程式，卻很少追溯到速率限制設定本身。

同時，資源充足的攻擊者若透過住宅代理網路發動攻擊，會將攻擊流量分散到數萬個 IP 上，使每個 IP 的個別請求速率都低於任何同時能避免 CGNAT 問題的閾值。

在應用層更持久有效的方法，是依據已驗證的工作階段、API 權杖或行為指紋進行速率限制，而不是依據 IP。對於無法這麼做的未驗證端點，應考慮採用較短時間視窗的突發限制，並結合漸進式挑戰升級，而不是採取僵硬的每 IP 截止限制。

使邊緣防護失效的源站 IP 暴露

部署具備完整 WAF 與 L7 DDoS 防護的 CDN，若攻擊者知道你的源站伺服器 IP 位址並直接鎖定它攻擊，便無法提供任何保護。

源站 IP 位址比多數團隊預期的更容易被發現。歷史 DNS 記錄（遷移到 CDN 之前）、SSL 憑證透明度記錄、遺留在應用程式層級錯誤訊息中的 IPv6 位址、未受 CDN 覆蓋的子網域 A 記錄，或設定錯誤的預備環境回應——其中任何一項都可能暴露源站。攻擊者在發動應用層攻擊之前，通常會例行列舉這些資訊，目的就是繞過邊緣防護。

解決方法是將源站 IP 隱藏視為 L7 DDoS 防護架構的硬性要求，而不是錦上添花。在防火牆層級，只接受來自你的 CDN 供應商已公布 IP 範圍的入站 HTTP/HTTPS 連線，並拒絕其他所有連線。對於更高保證的部署，應以出站通道（Cloudflare Tunnel、AWS PrivateLink 或同等方案）完全取代源站直接暴露，使源站根本不需要接受任何公開入站連線。

選擇正確的防禦架構

實務上的決策並不是「L3/4 或 L7」——而是要了解哪一層代表你的主要攻擊面。

如果你營運的基礎設施本質上就是容量型攻擊的目標——例如大型 DNS 解析器、金融交易所、處理大量連線的遊戲平台——你需要在所有其他環節之前，於上游部署具備高容量 anycast 網路的 L3/4 防護。

如果你營運的是 Web 應用程式或 API，風險幾乎可以肯定會集中在 L7。中型應用程式不太可能遭遇 500 Gbps 的 UDP 洪水攻擊。它會遇到的是每秒 30,000 個 HTTP 請求打向未驗證的密碼重設端點，或 8,000 個慢速連線耗盡所有可用的工作執行緒，或專門設計來耗盡搜尋索引查詢預算的定向爬取。

對於大多數 Web 與 API 工作負載而言，在 CDN 邊緣部署 L7 內嵌防護，比單靠 L3/4 清洗更能涵蓋真實的攻擊面。 兩個層級並用才是生產級的答案；但如果受限於成本或營運複雜度而必須排定防護優先順序，應用層正是現代攻擊最常落點之處。

SIRAYA 建議部署於亞太地區的應用程式採用一種常見的三層架構：以整合 WAF 與機器人管理的任播 CDN 邊緣作為第一接觸點；在負載平衡器層級實施源站層級的連線速率限制（採取保守調校以避免 CGNAT 誤判）；並在 API 閘道層針對已驗證 API 路徑執行每個端點的速率限制。每一層都處理其最適合偵測的內容；不應期望任何單一層能阻擋所有攻擊。

WAF 模式部署風險

一個令人意外地頻繁出現的營運失誤是：WAF 規則集以「偵測」或「僅記錄」模式部署，卻在流量增加前從未提升為「阻擋」模式。

這樣的考量可以理解——團隊希望在積極執行規則前先觀察誤判情況。但「偵測模式」並不是防護，而是監控。在真實攻擊條件下的生產環境中，只記錄而不阻擋的 WAF，是在為你的事後事件報告提供素材，而不是在防止事件發生。

較佳的營運做法是先在較低風險的端點（如靜態資產路徑、文件頁面）以阻擋模式部署並同時監控，然後逐步將規則執行擴展到較高敏感度的路徑，例如驗證與 API 端點。這能在不讓整個應用程式於觀察期間暴露的情況下，建立對規則調校的信心。

第 7 層 DDoS 防護不是買了就可以忘記的產品。它是一項必須符合你特定應用程式流量模式、API 結構、驗證模型以及使用者地理分布的設定。預設值很少能在真正的針對性攻擊下撐住。能撐住的團隊，是那些已根據自身基準流量調校規則、清楚了解快取在負載下的行為，並且在攻擊者開始尋找源站之前就已將其隱藏起來的團隊。