DDoS 攻擊，不止于網絡傳輸層
網絡世界里為人們所熟知的 DDoS 攻擊，多數是通過對帶寬或網絡計算資源的持續、大量消耗，最終導致目標網絡與業務的癱瘓；這類 DDOS 攻擊，工作在 OSI 模型的網絡層與傳輸層，利用協議特點構造惡意的請求載荷來達成目標資源耗盡的目的。
除了這類在網絡傳輸層大做文章的 DDoS 攻擊，還有一類 DDoS 攻擊把目光聚焦到了應用層。隨著互聯網的飛速發展，接入流量逐年攀高，承載這些流量的網絡應用也被黑產、黑客們盯上，在 DDoS 攻擊場景中也不例外。
由于應用層流量更貼近業務邏輯，在應用層發起 DDoS 攻擊可以同時對目標網絡與目標服務器的穩定性造成威脅。除此之外，攻擊者往往只需較小的帶寬成本，實現更大的破壞效果，這樣的不對稱性自然更受攻擊者們的關注與青睞。
Cloudflare 在 《DDoS Attack Trends for 2022 Q1》報告指出，全球范圍內應用層 DDoS 攻擊(主要是 HTTP DDoS)呈現著持續增長的態勢。在俄烏的網絡戰爭中，HTTP DDoS 攻擊也扮演著重要的角色。
與此同時，應用層 DDoS 攻擊的攻擊方式與手法在也在不斷演進升級。從集中式高頻請求逐步演進為分布式低頻請求，從請求報文中攜帶顯著惡意特征變化為重放合法請求流量，偽造搜索引擎爬蟲流量等；而在攻擊的頻率與規模上，應用層 DDoS 攻擊也呈現出不斷增長的趨勢。
針對攻擊手法的升級變化，業務防護可以從兩方面著手應對：一是在運營對抗上，在攻擊發生的事前、事中和事后各階段，通過梳理資產信息、分析攻擊報文并進行特征提取、配置防護策略、復盤防護數據等手段不斷提升防護對抗效果；二是在防護能力建設上，可以引入支持多維度特征組合的限速功能、JS Challenge、驗證碼等功能模塊來提升對高級復雜的應用層 DDoS 攻擊的識別處置能力。與此同時，在流量接入鏈路中與 CDN、LB、AGW 等各接入層產品進行聯動合作，通過在不同接入層級落地相關防護策略，實現攻擊流量的分級收斂，在應對大規模應用層 DDoS 攻擊時更能凸顯防護效果。
0 門檻，高收益，一鍵發起攻擊
上面提到的應用層 DDoS 攻擊，是通過向應用程序發送大量惡意請求實現攻擊效果，以每秒請求數 (QPS) 來衡量攻擊量級與規模；這類攻擊也稱為 7 層 DDoS 攻擊，可針對和破壞特定的網絡應用程序，而非整個網絡。雖然這類 DDoS 攻擊難以預防和抵御，但發動起來卻相對比較容易，具體有多容易呢？
由于 7 層 DDoS 通常不需要過高的帶寬成本，也無需構造復雜的協議利用報文，在黑灰產交易渠道，可以非常便捷地獲取到發起 7 層 DDoS 的工具與服務。
即便是知名、成熟的互聯網應用，在這類攻擊面前也存在被攻陷的可能與風險。
HTTP DDoS 攻擊的類型與特點
攻擊類型
7 層 DDoS 攻擊中，癱瘓目標應用與服務是首要目標，根據 HTTP DDoS(CC)攻擊發起的原理與方式，可以總結以下攻擊類型：
HTTP floods
這種攻擊主要分為兩種形式。第一種是 HTTP GET request floods，攻擊者通過構造 HTTP GET 請求報文，向目標服務器發送針對特定資源的大量請求。在客戶端執行一條 HTTP 請求的成本很低，但是目標服務器做出對應的響應成本卻可能很高。比如加載一個網頁，服務端通常需要加載多個文件、查詢數據庫等才能做出響應；在 Web 業務的防護中，對于有 SSR(Server-side rendering)功能頁面的 HTTP floods 攻擊，其量級與頻率更加突出明顯，也更容易對業務造成影響與危害。
第二種是 HTTP POST request floods，與 GET request floods 的顯著區別是，POST 請求往往需要攜帶表單參數或請求體信息，而這通常意味著服務端需要對請求內容進行相關解析處理，并將數據進行持久化(通常需要進行 DB 操作)。發送 POST 請求一般僅需較小的計算與帶寬成本，而服務端進行處理操作的過程往往消耗更高。可以說這種攻擊形式下，形成這種請求響應間資源消耗差異的空間或可能性更大，更容易實現讓服務器過載從而拒絕服務的目標。
Large Payload POST requests
這類攻擊一般通過 POST 方法發送容量大、結構復雜的請求體到目標服務器，使得目標服務器在解析這些請求內容的過程發生過載(CPU 或內存)；一般而言，攻擊者通過構造特定的序列化請求體，如 xml、json 等，在服務端執行反序列化操作時引起服務過載。
Asymmetric requests
這種類型的攻擊顧名思義，利用的就是請求與響應的非對稱性，請求的目標路徑會執行高消耗操作而發起攻擊請求輕而易舉。通常來說，這類攻擊需要對目標服務有一定的熟悉與了解，明確攻擊目標哪些地方存在這種非對稱性利用的可能及利用方式。比如通過從數據庫服務器下載大型文件或大量執行數據庫的查詢等接口，就容易被這種類型攻擊所利用。
Low&Slow attack(Slowloris/Slow Post/Read attack)
這種類型的攻擊更多是面向連接層面，以基于線程的 Web 服務器為目標，通過慢速請求來捆綁每個服務器線程，從而消耗服務器的線程&連接資源，這類攻擊中主要可分為 Slowloris、Slow Post/Read 幾種攻擊方式。
攻擊特點
根據上述總結的 HTTP DDoS 攻擊類型、原理與實現方式，可以總結出 HTTP DDoS 攻擊具備以下特點：
攻擊門檻、成本低
相較于 4 層 DDoS 攻擊，發起 HTTP DDoS 攻擊往往無需構造復雜的攻擊報文，僅需較少的帶寬就能實現強大的攻擊效果。
攻擊目標更精細
攻擊的目標可以精細到服務接口粒度，例如直播頁面等，而不需要癱瘓目標的網絡也能讓業務出現拒絕服務。
破壞范圍廣，危害程度高
雖然 HTTP DDoS 攻擊的首要目標是癱瘓目標服務，但并不意味著對目標網絡的可用性沒有威脅。當 HTTP floods 量級到一定程度時，也存在癱瘓請求接入層網絡的可能性。
攻擊源分布廣，隱匿性強
實際的 HTTP DDoS 攻擊中，攻擊者常常利用規模龐大的肉雞/代理 IP，而 HTTP DDoS 攻擊報文中往往不具備或具備難以察覺的惡意特征。對這些攻擊源進行封禁處置效果有限甚至有誤報風險，攻擊者卻可以隨時更換新一批攻擊源。
請求特征容易偽裝，防護難度大
不同于 Web 注入攻擊場景，HTTP DDoS 的攻擊請求的報文特征常常處在一個難以判定好壞的區間，有時部分的異常特征不足以支撐執行攔截決策。攻擊者可通過模擬、重放正常請求來發起攻擊，即便在請求報文中某些特征被防護方捕獲并針對性處置，攻擊者也能感知到并作出調整。
總體而言，一起復雜的 HTTP DDoS 攻擊，通常不會使用畸形報文，也無需使用偽裝技巧。對比其他類型的 DDoS 攻擊需要更少的帶寬成本就能癱瘓目標站點或服務，甚至特定的目標集群與接口。在影響目標業務可用性的同時，也可能對接入鏈路網絡的穩定性構成威脅。這類攻擊往往通過使用大量的肉雞+IP 代理池發起，所以簡單的封禁策略往往難以起到預期效果。也正因為如此，在進行 HTTP DDoS 攻擊防護過程，要求對業務有更深入的理解，對于攻擊定制針對性策略來實現誤報與漏報的平衡，這也是 HTTP DDoS 難以檢測防護的原因。
兵來將擋，WAF 如何實現有效防護
根據上述 HTTP DDoS 的類型與特點，對于來勢洶洶的攻擊流量，WAF 如何實現有效防護呢？
根據攻擊的原理與類型，可以大致分為三個主要的防護場景：
連接型 HTTP DDoS
這類型的 HTTP DDoS 攻擊，對應上面提到的 Low&Slow attack。由于攻擊是通過建立 TCP 連接后在傳輸 HTTP 報文的過程實現攻擊效果，因此對于業務前面有 7 層接入層設備的業務(CDN、LB 等)，這類攻擊會被前面的 7 層接入層設備所承載。所以對于許多業務而言，這類型的攻擊感知可能并不明顯，但并不表明這類攻擊的危害程度低。相反如果針對特定 7 層接入設備進行此類型攻擊，可能造成的業務影響面會更加廣泛。
由于這類攻擊的特點是“慢速”，那么WAF 可以對 HTTP 的請求 header 讀取、請求、響應 body 的傳輸設置好超時時間。當觸發超時策略時可斷開相應的 TCP 連接，釋放連接資源。同時，可對于異常的 header、body 做檢查與限制（如限制 HTTP 請求 header 的數量）。還可以通過 HTTP 層面的精細化訪問控制來避免誤傷場景（如正常業務的大文件傳輸場景）。
當然，要實現這些能力需要 WAF 與 7 層接入設備做好聯動配合才能實現有效防護。
特征型 HTTP DDoS
這類型的 HTTP DDoS 攻擊，對應上面的 Large Payload POST requests 和 Asymmetric requests，他們的共同點是需要實現這類 HTTP DDoS 攻擊，在 HTTP 請求報文中往往能夠提取出關鍵異常特征。
例如，對于 Large Payload POST requests，WAF 可通過限制 body 長度，檢查 body 內容合法性等手段來實現防護；
{
"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 頭的分片策略實現異常檢測與防護；對于一些漏洞利用，特別是業務使用的服務框架、中間件產生的漏洞造成的 DDoS，利用 WAF 的 Web 漏洞檢測防護能力便能實現有效防護。
floods 型 HTTP DDoS
floods 類型的 HTTP DDoS 在現實網絡流量中更為主流與常見，影響業務穩定性的風險更大，是需要重點關注的防護場景；WAF 在面對這類型攻擊時，可根據 floods 類型 HTTP DDoS 攻擊的特征、特點，分析拆解防護策略，通過以下手段、步驟來實現有效防護：
第一步：鏈路梳理，明確業務場景
當業務面臨 HTTP floods 攻擊防護需求時，首先需要梳理清楚業務的流量接入鏈路。因為 HTTP floods 通常具有持續、量級規模大的特點，因此最佳的防護部署是首先通過在最外接入層實現(例如 CDN)，這樣的優點很明顯，能將惡意的攻擊流量在最外層收斂，減少后續接入層的壓力與成本。但這并不意味著后續接入層無需部署防護，由于防護的精準程度與防護成本往往是正相關關系，經過收斂的流量在貼近業務的接入層做更精細的檢測、處置，往往收益更明顯；
同時，明確業務服務的使用場景在應對 HTTP floods 攻擊時也非常關鍵且必要，業務不同的 host、path 往往有不同的業務特征。比如后端負載能力、是否有登錄態、WebApp 還是 Native App、是否有 API 調用場景等，只有在明確業務場景后才能更好地制定精準、貼合業務需求的防護策略。
業務鏈路梳理&防護部署
第二步：負載兜底，構建防護基線
在 HTTP floods 發生時，最基本的防護需求是要保證業務的可用性，不能出現因攻擊而造成業務癱瘓的情況；在這個需求背景下，最快速有效的策略便是為業務制定負載兜底策略。與業務共同梳理清楚需要防護的目標資產(host、server cluster、path 等)，根據業務場景先配置全局/粗粒度的限速策略，實現對攻擊流量的初步防護收斂；
同時，在明確目標防護資產的負載能力后，進行更細粒度的限流/過載保護策略配置，在流量過載的極端情況下優先保證服務的可用性，構建一層基線防護能力。
第三步：特征分析，過濾惡意流量
采取上述策略手段實現初步防護后，需要對 HTTP floods 流量進一步分析過濾，才能在保障正常業務流量的同時將惡意流量拒之門外。這里就需要 WAF 提供基于 HTTP 請求、響應報文的多維組合、匹配能力，識別出報文中的異常特征并提供針對性的處置手段。例如，在對抗業務遭受的 HTTP floods 惡意流量攻擊過程中，除了提取常見的異常 IP，Params，UA，Referer，Cookie 等特征進行封禁或限速處置外，還會將相關特征進行組合關聯，為策略統計與響應處置提供參考。
通過對攻擊流量特征的分析統計，在 WAF 上進行組合策略配置
除了通過 WAF 豐富的特征分析能力識別惡意流量，在面臨 HTTP floods 攻擊時，提供豐富、梯度的處置動作對于在防護過程平衡誤傷風險也非常關鍵。WAF 可提供封禁、限速、重定向、驗證碼、JS Challenge、自定義響應等多種處置動作與特征識別能力配合，為防護的精準性提供保障。
第四步：能力聯動，提升防護效果
對于專業的 HTTP floods 攻擊，攻擊者會盡可能地模擬、重放正常的用戶請求流量。因此從“HTTP 報文特征”去識別防護惡意流量，可能還遠不足以應對高級復雜的 HTTP floods 攻擊。對于 HTTP floods 攻擊手法的持續升級演進，除了從 HTTP 報文層面抽絲剝繭識別異常，還需要聯動其他維度的信息與能力來提升防護效果，具體而言體現在以下方面：
- 對于高級隱蔽的 HTTP floods，攻擊者必定需要充足的 IP 資源，這些 IP 往往來源于“肉雞”IP 或 IP 代理池，通過結合高質量的 IP 情報信息，可以在攻擊發生時自動實時處置，實現精準防護；
- 同時，專業的 HTTP floods 攻擊離不開自動化工具的支持，這類工具往往具有 BOT 特征。通過對端側信息的采集、校驗，與每個請求進行關聯，可以在攻擊發生時自動識別惡意 BOT 流量，進一步提升防護效果。
WAF 的 JS Challenge 功能，就是通過能力聯動來提升防護效果的一個例子：
不同于對請求報文檢測來識別異常這種“被動”的防護方式，JS Challenge 功能通過在防護檢測過程“主動”向客戶端植入一段 JS 邏輯。通過利用前端瀏覽器的 JS 渲染執行能力，實現對異常流量的識別；在具體的實現過程中，為了對抗重放攻擊、減少繞過風險，可能會引入動態令牌機制；為了更全面地覆蓋業務場景，減少誤傷情況發生，可以利用 JS API 調用判斷瀏覽器環境與兼容性；為了對防護情況的實時掌控，還可能引入埋點、監控邏輯等。
在這些技術細節的實現過程中，WAF 既需要聯動端側瀏覽器的能力，也需要聯動 CDN、LB 等接入組件的能力，最終實現防護效果的進一步提升。
復盤反思，如何快人一步
WAF 在對抗 HTTP DDoS 攻擊的過程中，不斷建設、強化自身能力的同時，也需要不斷復盤、反思防護情況，力求更完善、高效的應對思路與方案。具體可以總結成以下三點：
豐富特征維度
根據 HTTP DDoS 攻擊的特點可以得知，防護難點之一在于攻擊流量特征難以捕捉。其中一個原因是依據現有的特征維度，攻擊流量能實現高度的模擬偽裝。從這個角度出發，從防護視角補充更多維度的特征，就更能識別檢測惡意流量。
就 WAF 產品而言，可以從兩方面著手推進：一方面是豐富報文特征，除了 7 層 HTTP 報文的特征提取，可以嘗試結合 4 層報文的字段因子來實現對惡意流量的識別標記；另一方面是豐富行為特征，由于 HTTP 是無狀態協議，單次請求響應的交互所攜帶的信息往往是有限的。通過關聯、統計具有一定聯系的請求，提取行為特征，也能為制定防護策略提供參考。
提升 BOT 識別&對抗能力
對于 BOT 流量的識別對抗能力，在 HTTP DDoS 攻擊防護中，往往發揮著重要、關鍵的作用。但現實業務流量中往往也會混雜正常的 BOT 流量，這就要求不僅能識別出 BOT 流量，還能區分正常與惡意的 BOT 流量，具備與惡意 BOT 流量的對抗處置能力。
在落地相關方案時，也需要與業務場景緊密貼合。對于 WebApp 而言，正常流量多數通過瀏覽器發起，可以通過 JS Challenge 的方式實現對端側的校驗與信息采集。通過該方案實現 WebApp 場景防護的同時，在技術實現上也需要不斷迭代優化來滿足更多元的業務場景需求。例如對于 JS 相關邏輯用更高效的混淆方式來避免繞過風險，對引入的 JS 資源做好緩存/優化策略提升業務性能與用戶體驗等。
對于 NativeApp 而言，則可以通過 SDK 集成方式來驗證、采集端側信息。但無論是哪種方式、場景，都需要有更完善的誤傷評估、監控體系來保障防護的精準性。對于無法準確識別惡意 BOT 流量的情況，也需要更豐富的柔性處置策略，來實現對流量的進一步過濾校驗。
策略事前布局
預防為主，防治結合，這是人類應對疾病威脅的重要方針，在網絡安全世界中也同樣適用。HTTP DDoS 攻擊發生時往往來勢洶洶，事先并沒有任何征兆。這就意味著事中、事后的處置策略對當前攻擊通常只能起到應急補救的效果。因此，對于存在攻擊風險的業務，提前梳理業務資產，預先進行策略布局就顯得更為重要。
為了實現這個目標可從兩方面著手：一個是與業務團隊緊密配合，做好宣傳引導，在 WAF 產品中對關鍵目標資產實現 HTTP DDoS 防護策略的事前配置；另一個是強化 WAF 的自動化分析能力，對承載業務的目標資產、負載能力、報文特征等數據進行自動化統計分析，輸出對應的防護策略，對生產的策略效果進行實時評估、校準，在提升防護效果的同時也能大幅降低策略運營成本。
