DDoS 攻擊，不止于網(wǎng)絡傳輸層

網(wǎng)絡世界里為人們所熟知的 DDoS 攻擊，多數(shù)是通過對帶寬或網(wǎng)絡計算資源的持續(xù)、大量消耗，最終導致目標網(wǎng)絡與業(yè)務的癱瘓；這類 DDOS 攻擊，工作在 OSI 模型的網(wǎng)絡層與傳輸層，利用協(xié)議特點構造惡意的請求載荷來達成目標資源耗盡的目的。

除了這類在網(wǎng)絡傳輸層大做文章的 DDoS 攻擊，還有一類 DDoS 攻擊把目光聚焦到了應用層。隨著互聯(lián)網(wǎng)的飛速發(fā)展，接入流量逐年攀高，承載這些流量的網(wǎng)絡應用也被黑產(chǎn)、黑客們盯上，在 DDoS 攻擊場景中也不例外。

由于應用層流量更貼近業(yè)務邏輯，在應用層發(fā)起 DDoS 攻擊可以同時對目標網(wǎng)絡與目標服務器的穩(wěn)定性造成威脅。除此之外，攻擊者往往只需較小的帶寬成本，實現(xiàn)更大的破壞效果，這樣的不對稱性自然更受攻擊者們的關注與青睞。

Cloudflare 在 《DDoS Attack Trends for 2022 Q1》報告指出，全球范圍內(nèi)應用層 DDoS 攻擊(主要是 HTTP DDoS)呈現(xiàn)著持續(xù)增長的態(tài)勢。在俄烏的網(wǎng)絡戰(zhàn)爭中，HTTP DDoS 攻擊也扮演著重要的角色。

與此同時，應用層 DDoS 攻擊的攻擊方式與手法在也在不斷演進升級。從集中式高頻請求逐步演進為分布式低頻請求，從請求報文中攜帶顯著惡意特征變化為重放合法請求流量，偽造搜索引擎爬蟲流量等；而在攻擊的頻率與規(guī)模上，應用層 DDoS 攻擊也呈現(xiàn)出不斷增長的趨勢。

針對攻擊手法的升級變化，業(yè)務防護可以從兩方面著手應對：一是在運營對抗上，在攻擊發(fā)生的事前、事中和事后各階段，通過梳理資產(chǎn)信息、分析攻擊報文并進行特征提取、配置防護策略、復盤防護數(shù)據(jù)等手段不斷提升防護對抗效果；二是在防護能力建設上，可以引入支持多維度特征組合的限速功能、JS Challenge、驗證碼等功能模塊來提升對高級復雜的應用層 DDoS 攻擊的識別處置能力。與此同時，在流量接入鏈路中與 CDN、LB、AGW 等各接入層產(chǎn)品進行聯(lián)動合作，通過在不同接入層級落地相關防護策略，實現(xiàn)攻擊流量的分級收斂，在應對大規(guī)模應用層 DDoS 攻擊時更能凸顯防護效果。

0 門檻，高收益，一鍵發(fā)起攻擊

上面提到的應用層 DDoS 攻擊，是通過向應用程序發(fā)送大量惡意請求實現(xiàn)攻擊效果，以每秒請求數(shù) (QPS) 來衡量攻擊量級與規(guī)模；這類攻擊也稱為 7 層 DDoS 攻擊，可針對和破壞特定的網(wǎng)絡應用程序，而非整個網(wǎng)絡。雖然這類 DDoS 攻擊難以預防和抵御，但發(fā)動起來卻相對比較容易，具體有多容易呢？

由于 7 層 DDoS 通常不需要過高的帶寬成本，也無需構造復雜的協(xié)議利用報文，在黑灰產(chǎn)交易渠道，可以非常便捷地獲取到發(fā)起 7 層 DDoS 的工具與服務。

即便是知名、成熟的互聯(lián)網(wǎng)應用，在這類攻擊面前也存在被攻陷的可能與風險。

HTTP DDoS 攻擊的類型與特點

攻擊類型

7 層 DDoS 攻擊中，癱瘓目標應用與服務是首要目標，根據(jù) HTTP DDoS(CC)攻擊發(fā)起的原理與方式，可以總結以下攻擊類型：

HTTP floods

這種攻擊主要分為兩種形式。第一種是 HTTP GET request floods，攻擊者通過構造 HTTP GET 請求報文，向目標服務器發(fā)送針對特定資源的大量請求。在客戶端執(zhí)行一條 HTTP 請求的成本很低，但是目標服務器做出對應的響應成本卻可能很高。比如加載一個網(wǎng)頁，服務端通常需要加載多個文件、查詢數(shù)據(jù)庫等才能做出響應；在 Web 業(yè)務的防護中，對于有 SSR(Server-side rendering)功能頁面的 HTTP floods 攻擊，其量級與頻率更加突出明顯，也更容易對業(yè)務造成影響與危害。

第二種是 HTTP POST request floods，與 GET request floods 的顯著區(qū)別是，POST 請求往往需要攜帶表單參數(shù)或請求體信息，而這通常意味著服務端需要對請求內(nèi)容進行相關解析處理，并將數(shù)據(jù)進行持久化(通常需要進行 DB 操作)。發(fā)送 POST 請求一般僅需較小的計算與帶寬成本，而服務端進行處理操作的過程往往消耗更高?？梢哉f這種攻擊形式下，形成這種請求響應間資源消耗差異的空間或可能性更大，更容易實現(xiàn)讓服務器過載從而拒絕服務的目標。

Large Payload POST requests

這類攻擊一般通過 POST 方法發(fā)送容量大、結構復雜的請求體到目標服務器，使得目標服務器在解析這些請求內(nèi)容的過程發(fā)生過載(CPU 或內(nèi)存)；一般而言，攻擊者通過構造特定的序列化請求體，如 xml、json 等，在服務端執(zhí)行反序列化操作時引起服務過載。

Asymmetric requests

這種類型的攻擊顧名思義，利用的就是請求與響應的非對稱性，請求的目標路徑會執(zhí)行高消耗操作而發(fā)起攻擊請求輕而易舉。通常來說，這類攻擊需要對目標服務有一定的熟悉與了解，明確攻擊目標哪些地方存在這種非對稱性利用的可能及利用方式。比如通過從數(shù)據(jù)庫服務器下載大型文件或大量執(zhí)行數(shù)據(jù)庫的查詢等接口，就容易被這種類型攻擊所利用。

Low&Slow attack(Slowloris/Slow Post/Read attack)

這種類型的攻擊更多是面向連接層面，以基于線程的 Web 服務器為目標，通過慢速請求來捆綁每個服務器線程，從而消耗服務器的線程&連接資源，這類攻擊中主要可分為 Slowloris、Slow Post/Read 幾種攻擊方式。

攻擊特點

根據(jù)上述總結的 HTTP DDoS 攻擊類型、原理與實現(xiàn)方式，可以總結出 HTTP DDoS 攻擊具備以下特點：

攻擊門檻、成本低

相較于 4 層 DDoS 攻擊，發(fā)起 HTTP DDoS 攻擊往往無需構造復雜的攻擊報文，僅需較少的帶寬就能實現(xiàn)強大的攻擊效果。

攻擊目標更精細

攻擊的目標可以精細到服務接口粒度，例如直播頁面等，而不需要癱瘓目標的網(wǎng)絡也能讓業(yè)務出現(xiàn)拒絕服務。

破壞范圍廣，危害程度高

雖然 HTTP DDoS 攻擊的首要目標是癱瘓目標服務，但并不意味著對目標網(wǎng)絡的可用性沒有威脅。當 HTTP floods 量級到一定程度時，也存在癱瘓請求接入層網(wǎng)絡的可能性。

攻擊源分布廣，隱匿性強

實際的 HTTP DDoS 攻擊中，攻擊者常常利用規(guī)模龐大的肉雞/代理 IP，而 HTTP DDoS 攻擊報文中往往不具備或具備難以察覺的惡意特征。對這些攻擊源進行封禁處置效果有限甚至有誤報風險，攻擊者卻可以隨時更換新一批攻擊源。

請求特征容易偽裝，防護難度大

不同于 Web 注入攻擊場景，HTTP DDoS 的攻擊請求的報文特征常常處在一個難以判定好壞的區(qū)間，有時部分的異常特征不足以支撐執(zhí)行攔截決策。攻擊者可通過模擬、重放正常請求來發(fā)起攻擊，即便在請求報文中某些特征被防護方捕獲并針對性處置，攻擊者也能感知到并作出調(diào)整。

總體而言，一起復雜的 HTTP DDoS 攻擊，通常不會使用畸形報文，也無需使用偽裝技巧。對比其他類型的 DDoS 攻擊需要更少的帶寬成本就能癱瘓目標站點或服務，甚至特定的目標集群與接口。在影響目標業(yè)務可用性的同時，也可能對接入鏈路網(wǎng)絡的穩(wěn)定性構成威脅。這類攻擊往往通過使用大量的肉雞+IP 代理池發(fā)起，所以簡單的封禁策略往往難以起到預期效果。也正因為如此，在進行 HTTP DDoS 攻擊防護過程，要求對業(yè)務有更深入的理解，對于攻擊定制針對性策略來實現(xiàn)誤報與漏報的平衡，這也是 HTTP DDoS 難以檢測防護的原因。

兵來將擋，WAF 如何實現(xiàn)有效防護

根據(jù)上述 HTTP DDoS 的類型與特點，對于來勢洶洶的攻擊流量，WAF 如何實現(xiàn)有效防護呢？

根據(jù)攻擊的原理與類型，可以大致分為三個主要的防護場景：

連接型 HTTP DDoS

這類型的 HTTP DDoS 攻擊，對應上面提到的 Low&Slow attack。由于攻擊是通過建立 TCP 連接后在傳輸 HTTP 報文的過程實現(xiàn)攻擊效果，因此對于業(yè)務前面有 7 層接入層設備的業(yè)務(CDN、LB 等)，這類攻擊會被前面的 7 層接入層設備所承載。所以對于許多業(yè)務而言，這類型的攻擊感知可能并不明顯，但并不表明這類攻擊的危害程度低。相反如果針對特定 7 層接入設備進行此類型攻擊，可能造成的業(yè)務影響面會更加廣泛。

由于這類攻擊的特點是“慢速”，那么WAF 可以對 HTTP 的請求 header 讀取、請求、響應 body 的傳輸設置好超時時間。當觸發(fā)超時策略時可斷開相應的 TCP 連接，釋放連接資源。同時，可對于異常的 header、body 做檢查與限制（如限制 HTTP 請求 header 的數(shù)量）。還可以通過 HTTP 層面的精細化訪問控制來避免誤傷場景（如正常業(yè)務的大文件傳輸場景）。

當然，要實現(xiàn)這些能力需要 WAF 與 7 層接入設備做好聯(lián)動配合才能實現(xiàn)有效防護。

特征型 HTTP DDoS

這類型的 HTTP DDoS 攻擊，對應上面的 Large Payload POST requests 和 Asymmetric requests，他們的共同點是需要實現(xiàn)這類 HTTP DDoS 攻擊，在 HTTP 請求報文中往往能夠提取出關鍵異常特征。

例如，對于 Large Payload POST requests，WAF 可通過限制 body 長度，檢查 body 內(nèi)容合法性等手段來實現(xiàn)防護；

{
  "title": "Liverpool FC                  (1 million more whitespace)",
  "contentFormat": "html",
  "content": "<h1>Liverpool FC</h1><p>You’ll never walk alone.</p>",
  "canonicalUrl": "http://jamietalbot.com/posts/liverpool-fc",
  "tags": ["football", "sport", "Liverpool"],
  "publishStatus": "public"
}

例如針對上述的超大異常 body，可通過 WAF 配置自定義策略限制 body 長度。

對于 Asymmetric requests 攻擊，例如 HTTP Range 頭利用的例子中，WAF 可通過限制 HTTP Range 頭的分片策略實現(xiàn)異常檢測與防護；對于一些漏洞利用，特別是業(yè)務使用的服務框架、中間件產(chǎn)生的漏洞造成的 DDoS，利用 WAF 的 Web 漏洞檢測防護能力便能實現(xiàn)有效防護。

floods 型 HTTP DDoS

floods 類型的 HTTP DDoS 在現(xiàn)實網(wǎng)絡流量中更為主流與常見，影響業(yè)務穩(wěn)定性的風險更大，是需要重點關注的防護場景；WAF 在面對這類型攻擊時，可根據(jù) floods 類型 HTTP DDoS 攻擊的特征、特點，分析拆解防護策略，通過以下手段、步驟來實現(xiàn)有效防護：

第一步：鏈路梳理，明確業(yè)務場景

當業(yè)務面臨 HTTP floods 攻擊防護需求時，首先需要梳理清楚業(yè)務的流量接入鏈路。因為 HTTP floods 通常具有持續(xù)、量級規(guī)模大的特點，因此最佳的防護部署是首先通過在最外接入層實現(xiàn)(例如 CDN)，這樣的優(yōu)點很明顯，能將惡意的攻擊流量在最外層收斂，減少后續(xù)接入層的壓力與成本。但這并不意味著后續(xù)接入層無需部署防護，由于防護的精準程度與防護成本往往是正相關關系，經(jīng)過收斂的流量在貼近業(yè)務的接入層做更精細的檢測、處置，往往收益更明顯；

同時，明確業(yè)務服務的使用場景在應對 HTTP floods 攻擊時也非常關鍵且必要，業(yè)務不同的 host、path 往往有不同的業(yè)務特征。比如后端負載能力、是否有登錄態(tài)、WebApp 還是 Native App、是否有 API 調(diào)用場景等，只有在明確業(yè)務場景后才能更好地制定精準、貼合業(yè)務需求的防護策略。

業(yè)務鏈路梳理&防護部署

第二步：負載兜底，構建防護基線

在 HTTP floods 發(fā)生時，最基本的防護需求是要保證業(yè)務的可用性，不能出現(xiàn)因攻擊而造成業(yè)務癱瘓的情況；在這個需求背景下，最快速有效的策略便是為業(yè)務制定負載兜底策略。與業(yè)務共同梳理清楚需要防護的目標資產(chǎn)(host、server cluster、path 等)，根據(jù)業(yè)務場景先配置全局/粗粒度的限速策略，實現(xiàn)對攻擊流量的初步防護收斂；

同時，在明確目標防護資產(chǎn)的負載能力后，進行更細粒度的限流/過載保護策略配置，在流量過載的極端情況下優(yōu)先保證服務的可用性，構建一層基線防護能力。

第三步：特征分析，過濾惡意流量

采取上述策略手段實現(xiàn)初步防護后，需要對 HTTP floods 流量進一步分析過濾，才能在保障正常業(yè)務流量的同時將惡意流量拒之門外。這里就需要 WAF 提供基于 HTTP 請求、響應報文的多維組合、匹配能力，識別出報文中的異常特征并提供針對性的處置手段。例如，在對抗業(yè)務遭受的 HTTP floods 惡意流量攻擊過程中，除了提取常見的異常 IP，Params，UA，Referer，Cookie 等特征進行封禁或限速處置外，還會將相關特征進行組合關聯(lián)，為策略統(tǒng)計與響應處置提供參考。

通過對攻擊流量特征的分析統(tǒng)計，在 WAF 上進行組合策略配置

除了通過 WAF 豐富的特征分析能力識別惡意流量，在面臨 HTTP floods 攻擊時，提供豐富、梯度的處置動作對于在防護過程平衡誤傷風險也非常關鍵。WAF 可提供封禁、限速、重定向、驗證碼、JS Challenge、自定義響應等多種處置動作與特征識別能力配合，為防護的精準性提供保障。

第四步：能力聯(lián)動，提升防護效果

對于專業(yè)的 HTTP floods 攻擊，攻擊者會盡可能地模擬、重放正常的用戶請求流量。因此從“HTTP 報文特征”去識別防護惡意流量，可能還遠不足以應對高級復雜的 HTTP floods 攻擊。對于 HTTP floods 攻擊手法的持續(xù)升級演進，除了從 HTTP 報文層面抽絲剝繭識別異常，還需要聯(lián)動其他維度的信息與能力來提升防護效果，具體而言體現(xiàn)在以下方面：

• 對于高級隱蔽的 HTTP floods，攻擊者必定需要充足的 IP 資源，這些 IP 往往來源于“肉雞”IP 或 IP 代理池，通過結合高質(zhì)量的 IP 情報信息，可以在攻擊發(fā)生時自動實時處置，實現(xiàn)精準防護；
• 同時，專業(yè)的 HTTP floods 攻擊離不開自動化工具的支持，這類工具往往具有 BOT 特征。通過對端側信息的采集、校驗，與每個請求進行關聯(lián)，可以在攻擊發(fā)生時自動識別惡意 BOT 流量，進一步提升防護效果。

WAF 的 JS Challenge 功能，就是通過能力聯(lián)動來提升防護效果的一個例子：

不同于對請求報文檢測來識別異常這種“被動”的防護方式，JS Challenge 功能通過在防護檢測過程“主動”向客戶端植入一段 JS 邏輯。通過利用前端瀏覽器的 JS 渲染執(zhí)行能力，實現(xiàn)對異常流量的識別；在具體的實現(xiàn)過程中，為了對抗重放攻擊、減少繞過風險，可能會引入動態(tài)令牌機制；為了更全面地覆蓋業(yè)務場景，減少誤傷情況發(fā)生，可以利用 JS API 調(diào)用判斷瀏覽器環(huán)境與兼容性；為了對防護情況的實時掌控，還可能引入埋點、監(jiān)控邏輯等。

在這些技術細節(jié)的實現(xiàn)過程中，WAF 既需要聯(lián)動端側瀏覽器的能力，也需要聯(lián)動 CDN、LB 等接入組件的能力，最終實現(xiàn)防護效果的進一步提升。

復盤反思，如何快人一步

WAF 在對抗 HTTP DDoS 攻擊的過程中，不斷建設、強化自身能力的同時，也需要不斷復盤、反思防護情況，力求更完善、高效的應對思路與方案。具體可以總結成以下三點：

豐富特征維度

根據(jù) HTTP DDoS 攻擊的特點可以得知，防護難點之一在于攻擊流量特征難以捕捉。其中一個原因是依據(jù)現(xiàn)有的特征維度，攻擊流量能實現(xiàn)高度的模擬偽裝。從這個角度出發(fā)，從防護視角補充更多維度的特征，就更能識別檢測惡意流量。

就 WAF 產(chǎn)品而言，可以從兩方面著手推進：一方面是豐富報文特征，除了 7 層 HTTP 報文的特征提取，可以嘗試結合 4 層報文的字段因子來實現(xiàn)對惡意流量的識別標記；另一方面是豐富行為特征，由于 HTTP 是無狀態(tài)協(xié)議，單次請求響應的交互所攜帶的信息往往是有限的。通過關聯(lián)、統(tǒng)計具有一定聯(lián)系的請求，提取行為特征，也能為制定防護策略提供參考。

提升 BOT 識別&對抗能力

對于 BOT 流量的識別對抗能力，在 HTTP DDoS 攻擊防護中，往往發(fā)揮著重要、關鍵的作用。但現(xiàn)實業(yè)務流量中往往也會混雜正常的 BOT 流量，這就要求不僅能識別出 BOT 流量，還能區(qū)分正常與惡意的 BOT 流量，具備與惡意 BOT 流量的對抗處置能力。

在落地相關方案時，也需要與業(yè)務場景緊密貼合。對于 WebApp 而言，正常流量多數(shù)通過瀏覽器發(fā)起，可以通過 JS Challenge 的方式實現(xiàn)對端側的校驗與信息采集。通過該方案實現(xiàn) WebApp 場景防護的同時，在技術實現(xiàn)上也需要不斷迭代優(yōu)化來滿足更多元的業(yè)務場景需求。例如對于 JS 相關邏輯用更高效的混淆方式來避免繞過風險，對引入的 JS 資源做好緩存/優(yōu)化策略提升業(yè)務性能與用戶體驗等。

對于 NativeApp 而言，則可以通過 SDK 集成方式來驗證、采集端側信息。但無論是哪種方式、場景，都需要有更完善的誤傷評估、監(jiān)控體系來保障防護的精準性。對于無法準確識別惡意 BOT 流量的情況，也需要更豐富的柔性處置策略，來實現(xiàn)對流量的進一步過濾校驗。

策略事前布局

預防為主，防治結合，這是人類應對疾病威脅的重要方針，在網(wǎng)絡安全世界中也同樣適用。HTTP DDoS 攻擊發(fā)生時往往來勢洶洶，事先并沒有任何征兆。這就意味著事中、事后的處置策略對當前攻擊通常只能起到應急補救的效果。因此，對于存在攻擊風險的業(yè)務，提前梳理業(yè)務資產(chǎn)，預先進行策略布局就顯得更為重要。

為了實現(xiàn)這個目標可從兩方面著手：一個是與業(yè)務團隊緊密配合，做好宣傳引導，在 WAF 產(chǎn)品中對關鍵目標資產(chǎn)實現(xiàn) HTTP DDoS 防護策略的事前配置；另一個是強化 WAF 的自動化分析能力，對承載業(yè)務的目標資產(chǎn)、負載能力、報文特征等數(shù)據(jù)進行自動化統(tǒng)計分析，輸出對應的防護策略，對生產(chǎn)的策略效果進行實時評估、校準，在提升防護效果的同時也能大幅降低策略運營成本。