HTTP2快速重置攻擊：Cloudflare發(fā)現(xiàn)并緩解史上最大規(guī)模的新型網(wǎng)絡(luò)威脅

從2023年8月25日開(kāi)始，我們開(kāi)始注意到一些異常嚴(yán)重的HTTP攻擊攻擊了很多我們的用戶。幸運(yùn)的是我們的自動(dòng)化DDoS系統(tǒng)檢測(cè)到并緩解了這些攻擊。然而，沒(méi)過(guò)多久，它們的規(guī)模就開(kāi)始達(dá)到破紀(jì)錄的水平，并最終達(dá)到每秒略高于2.01億個(gè)請(qǐng)求的峰值。這相當(dāng)于我們之前有記錄以來(lái)最大攻擊規(guī)模的三倍。而更令人擔(dān)憂的是，攻擊者能夠利用僅由20,000臺(tái)機(jī)器組成的僵尸網(wǎng)絡(luò)發(fā)起此類攻擊。而如今的僵尸網(wǎng)絡(luò)規(guī)模可達(dá)數(shù)十萬(wàn)或數(shù)百萬(wàn)臺(tái)機(jī)器。整個(gè)web網(wǎng)絡(luò)通常每秒處理10-30億個(gè)請(qǐng)求，因此使用此方法可以將整個(gè)web網(wǎng)絡(luò)的請(qǐng)求數(shù)量等級(jí)集中在少數(shù)目標(biāo)上，而這并非不可想象。

如果您正在遭受類似攻擊或想尋求增強(qiáng)安全防護(hù)支持，請(qǐng)即刻聯(lián)系我們。

檢測(cè)和緩解情況概述

這是一種規(guī)?？涨暗男滦凸羰侄?，Cloudflare現(xiàn)有的保護(hù)措施在很大程度上能夠抵御這種攻擊的沖擊。雖然最初我們看到了對(duì)客戶流量的一些影響（在第一波攻擊期間影響了大約1%的請(qǐng)求），但今天我們已經(jīng)能夠改進(jìn)我們的緩解方法，以阻止任何針對(duì)Cloudflare客戶的攻擊，也不影響我們自身的系統(tǒng)正常運(yùn)行。

我們注意到這些攻擊的同時(shí)，另外兩個(gè)主要行業(yè)參與者——谷歌和AWS——也看到了同樣的情況。我們致力于強(qiáng)化Cloudflare的系統(tǒng)，以確保今天我們的所有客戶都能免受這種新的DDoS攻擊方法的影響，而不會(huì)對(duì)客戶造成任何影響。我們還與Google和AWS合作，向受影響的供應(yīng)商和關(guān)鍵基礎(chǔ)設(shè)施提供商協(xié)調(diào)披露此次攻擊。

這種攻擊是通過(guò)濫用HTTP/2協(xié)議的某些功能和服務(wù)器實(shí)現(xiàn)細(xì)節(jié)而實(shí)現(xiàn)的（有關(guān)詳細(xì)信息，請(qǐng)參閱CVE-2023-44487）。由于該攻擊利用了HTTP/2協(xié)議中的潛在弱點(diǎn)，因此我們相信任何實(shí)施了HTTP/2的供應(yīng)商都將受到攻擊。這包括所有現(xiàn)代網(wǎng)絡(luò)服務(wù)器。我們與Google和AWS一起向Web服務(wù)器供應(yīng)商披露了攻擊方法，我們預(yù)計(jì)他們將實(shí)施補(bǔ)丁。與此同時(shí)，最好的防御措施是在任何Web或API服務(wù)器前面使用Cloudflare等DDoS緩解服務(wù)。

這篇文章深入探討了HTTP/2協(xié)議的詳細(xì)信息、攻擊者用來(lái)生成這些大規(guī)模攻擊的方法，以及我們?yōu)榇_保所有客戶受到保護(hù)而采取的緩解策略。我們希望通過(guò)發(fā)布這些詳細(xì)信息，其他受影響的網(wǎng)絡(luò)服務(wù)器和服務(wù)將獲得實(shí)施緩解策略所需的信息。此外，HTTP/2協(xié)議標(biāo)準(zhǔn)團(tuán)隊(duì)以及致力于未來(lái)Web標(biāo)準(zhǔn)的團(tuán)隊(duì)可以更好地設(shè)計(jì)它們以防止此類攻擊。

RST攻擊細(xì)節(jié)

HTTP是為Web提供支持的應(yīng)用程序協(xié)議。HTTP語(yǔ)義對(duì)于所有版本的HTTP都是通用的—整體架構(gòu)、術(shù)語(yǔ)和協(xié)議方面，例如請(qǐng)求和響應(yīng)消息、方法、狀態(tài)代碼、標(biāo)頭和尾部字段、消息內(nèi)容等等。每個(gè)單獨(dú)的HTTP版本都定義了如何將語(yǔ)義轉(zhuǎn)換為“有線格式”以通過(guò)Internet進(jìn)行交換。例如，客戶端必須將請(qǐng)求消息序列化為二進(jìn)制數(shù)據(jù)并發(fā)送，然后服務(wù)器將其解析回它可以處理的消息。

HTTP/1.1使用文本形式的序列化。請(qǐng)求和響應(yīng)消息作為ASCII字符流進(jìn)行交換，通過(guò)可靠的傳輸層（如TCP）發(fā)送，使用以下格式（其中CRLF表示回車和換行）：

例如，對(duì)于https://blog.cloudflare.com/的一個(gè)非常簡(jiǎn)單的GET請(qǐng)求在線路上將如下所示：

響應(yīng)將如下所示：

這種格式在線路上構(gòu)造消息，這意味著可以使用單個(gè)TCP連接來(lái)交換多個(gè)請(qǐng)求和響應(yīng)。但是，該格式要求每條消息都完整發(fā)送。此外，為了正確地將請(qǐng)求與響應(yīng)關(guān)聯(lián)起來(lái)，需要嚴(yán)格的排序；這意味著消息是串行交換的并且不能多路復(fù)用。https://blog.cloudflare.com/和https://blog.cloudflare.com/page/2/的兩個(gè)GET請(qǐng)求將是：

而response是：

網(wǎng)頁(yè)需要比這些示例更復(fù)雜的HTTP交互。訪問(wèn)Cloudflare博客時(shí)，您的瀏覽器將加載多個(gè)腳本、樣式和媒體資產(chǎn)。如果您使用HTTP/1.1訪問(wèn)首頁(yè)并決定快速導(dǎo)航到第2頁(yè)，您的瀏覽器可以從兩個(gè)選項(xiàng)中進(jìn)行選擇。在第2頁(yè)甚至可以啟動(dòng)之前，等待您不再需要的頁(yè)面的所有排隊(duì)響應(yīng)，或者通過(guò)關(guān)閉TCP連接并打開(kāi)新連接來(lái)取消正在進(jìn)行的請(qǐng)求。這些都不太實(shí)用。瀏覽器傾向于通過(guò)管理TCP連接池（每個(gè)主機(jī)最多6個(gè)）并在池上實(shí)現(xiàn)復(fù)雜的請(qǐng)求分派邏輯來(lái)解決這些限制。

HTTP/2解決了HTTP/1.1的許多問(wèn)題。每個(gè)HTTP消息都被序列化為一組HTTP/2幀，這些幀具有類型、長(zhǎng)度、標(biāo)志、流標(biāo)識(shí)符（ID）和有效負(fù)載。流ID清楚地表明線路上的哪些字節(jié)適用于哪個(gè)消息，從而允許安全的多路復(fù)用和并發(fā)。流是雙向的?？蛻舳税l(fā)送幀，服務(wù)器使用相同的ID回復(fù)幀。

在HTTP/2中，我們對(duì)https://blog.cloudflare.com的GET請(qǐng)求將通過(guò)流ID 1進(jìn)行交換，客戶端發(fā)送一個(gè)HEADERS幀，服務(wù)器使用一個(gè)HEADERS幀進(jìn)行響應(yīng)，后跟一個(gè)或多個(gè)DATA幀?？蛻舳苏?qǐng)求始終使用奇數(shù)流ID，因此后續(xù)請(qǐng)求將使用流ID 3、5等?？梢砸匀魏雾樞蛱峁╉憫?yīng)，并且來(lái)自不同流的幀可以交織。

流復(fù)用和并發(fā)是HTTP/2的強(qiáng)大功能。它們可以更有效地使用單個(gè)TCP連接。HTTP/2優(yōu)化了資源獲取，尤其是與優(yōu)先級(jí)結(jié)合使用時(shí)。另一方面，與HTTP/1.1相比，使客戶端能夠輕松啟動(dòng)大量并行工作可能會(huì)增加對(duì)服務(wù)器資源的峰值需求。這是一個(gè)明顯的拒絕服務(wù)向量。

為了提供一些防護(hù)，HTTP/2提供了最大活動(dòng)并發(fā)流的概念。SETTINGS_MAX_CONCURRENT_STREAMS參數(shù)允許服務(wù)器通告其并發(fā)限制。例如，如果服務(wù)器規(guī)定限制為100，則任何時(shí)候只能有100個(gè)請(qǐng)求處于活動(dòng)狀態(tài)。如果客戶端嘗試打開(kāi)超過(guò)此限制的流，則服務(wù)器必須使用RST_STREAM幀拒絕它。流拒絕不會(huì)影響連接上的其他正在進(jìn)行的流。

真實(shí)的故事有點(diǎn)復(fù)雜。流有生命周期。下圖是HTTP/2流狀態(tài)機(jī)的示意圖?？蛻舳撕头?wù)器管理自己的流狀態(tài)視圖。HEADERS、DATA和RST_STREAM幀在發(fā)送或接收時(shí)會(huì)觸發(fā)轉(zhuǎn)換。雖然流狀態(tài)的視圖是獨(dú)立的，但它們是同步的。

HEADERS和DATA幀包含END_STREAM標(biāo)志，當(dāng)設(shè)置為值1（真）時(shí)，可以觸發(fā)狀態(tài)轉(zhuǎn)換。

讓我們通過(guò)一個(gè)沒(méi)有消息內(nèi)容的GET請(qǐng)求示例來(lái)解決這個(gè)問(wèn)題?？蛻舳艘訦EADERS幀的形式發(fā)送請(qǐng)求，并將END_STREAM標(biāo)志設(shè)置為1。客戶端首先將流從空閑狀態(tài)轉(zhuǎn)換為打開(kāi)狀態(tài)，然后立即轉(zhuǎn)換為半關(guān)閉狀態(tài)?？蛻舳税腙P(guān)閉狀態(tài)意味著它不能再發(fā)送HEADERS或DATA，只能發(fā)送WINDOW_UPDATE、PRIORITY或RST_STREAM幀。然而它可以接收任何幀。

一旦服務(wù)器接收并解析了HEADERS幀，它就會(huì)將流狀態(tài)從空閑轉(zhuǎn)變?yōu)榇蜷_(kāi)，然后半關(guān)閉，因此它與客戶端匹配。服務(wù)器半關(guān)閉狀態(tài)意味著它可以發(fā)送任何幀，但只能接收WINDOW_UPDATE、PRIORITY或RST_STREAM幀。

對(duì)GET的響應(yīng)包含消息內(nèi)容，因此服務(wù)器發(fā)送END_STREAM標(biāo)志設(shè)置為0的HEADERS，然后發(fā)送END_STREAM標(biāo)志設(shè)置為1的DATA。DATA幀觸發(fā)服務(wù)器上流從半關(guān)閉到關(guān)閉的轉(zhuǎn)換。當(dāng)客戶端收到它時(shí)，它也會(huì)轉(zhuǎn)換為關(guān)閉狀態(tài)。一旦流關(guān)閉，就無(wú)法發(fā)送或接收任何幀。

將此生命周期應(yīng)用回并發(fā)上下文中，HTTP/2指出：

處于“打開(kāi)”狀態(tài)或任一“半關(guān)閉”狀態(tài)的流計(jì)入允許端點(diǎn)打開(kāi)的最大流數(shù)。處于這三種狀態(tài)中任何一種狀態(tài)的流都會(huì)計(jì)入SETTINGS_MAX_CONCURRENT_STREAMS設(shè)置中公布的限制。

理論上，并發(fā)限制是有用的。然而，有一些實(shí)際因素阻礙了其有效性——我們將在本文后續(xù)介紹。

HTTP/2請(qǐng)求取消

早些時(shí)候，我們討論了客戶取消傳遞中請(qǐng)求的情況。HTTP/2以比HTTP/1.1更有效的方式支持這一點(diǎn)?？蛻舳丝梢詾閱蝹€(gè)流發(fā)送RST_STREAM幀，而不需要拆除整個(gè)連接。這指示服務(wù)器停止處理請(qǐng)求并中止響應(yīng)，從而釋放服務(wù)器資源并避免浪費(fèi)帶寬。

讓我們考慮一下之前的3個(gè)請(qǐng)求的示例。這次，在發(fā)送所有標(biāo)頭后，客戶端取消了流1上的請(qǐng)求。服務(wù)器在準(zhǔn)備好提供響應(yīng)之前解析此RST_STREAM幀，并且僅響應(yīng)流3和5：

請(qǐng)求取消是一個(gè)有用的功能。例如，當(dāng)滾動(dòng)包含多個(gè)圖像的網(wǎng)頁(yè)時(shí)，網(wǎng)絡(luò)瀏覽器可以取消落在視口之外的圖像，這意味著進(jìn)入視口的圖像可以更快地加載。與HTTP/1.1相比，HTTP/2使這種行為更加高效。

被取消的請(qǐng)求流會(huì)快速過(guò)渡整個(gè)流生命周期。END_STREAM標(biāo)志設(shè)置為1的客戶端HEADERS狀態(tài)從空閑狀態(tài)轉(zhuǎn)換為打開(kāi)狀態(tài)再到半關(guān)閉狀態(tài)，然后RST_STREAM立即導(dǎo)致從半關(guān)閉狀態(tài)轉(zhuǎn)換為關(guān)閉狀態(tài)。

回想一下，只有處于打開(kāi)或半關(guān)閉狀態(tài)的流才會(huì)影響流并發(fā)限制。當(dāng)客戶端取消流時(shí)，它立即能夠在其位置打開(kāi)另一個(gè)流，并可以立即發(fā)送另一個(gè)請(qǐng)求。這是CVE-2023-44487發(fā)揮作用的關(guān)鍵。

快速重置導(dǎo)致拒絕服務(wù)

HTTP/2請(qǐng)求取消可能被濫用來(lái)快速重置無(wú)限數(shù)量的流。當(dāng)HTTP/2服務(wù)器能夠足夠快地處理客戶端發(fā)送的RST_STREAM幀并拆除狀態(tài)時(shí)，這種快速重置不會(huì)導(dǎo)致問(wèn)題。當(dāng)整理工作出現(xiàn)任何延誤或滯后時(shí)，問(wèn)題就會(huì)開(kāi)始出現(xiàn)?？蛻舳丝赡軙?huì)處理大量請(qǐng)求，從而導(dǎo)致工作積壓，從而導(dǎo)致服務(wù)器上資源的過(guò)度消耗。

常見(jiàn)的HTTP部署架構(gòu)是在其他組件之前運(yùn)行HTTP/2代理或負(fù)載均衡器。當(dāng)客戶端請(qǐng)求到達(dá)時(shí)，它會(huì)被快速分派，并且實(shí)際工作在其他地方作為異步活動(dòng)完成。這使得代理能夠非常有效地處理客戶端流量。然而，這種關(guān)注點(diǎn)分離可能會(huì)使代理很難整理正在進(jìn)行的作業(yè)。因此，這些部署更有可能遇到快速重置帶來(lái)的問(wèn)題。

當(dāng)Cloudflare的反向代理處理傳入的HTTP/2客戶端流量時(shí)，它們會(huì)將數(shù)據(jù)從連接的套接字復(fù)制到緩沖區(qū)中，并按順序處理緩沖的數(shù)據(jù)。當(dāng)讀取每個(gè)請(qǐng)求（標(biāo)頭和數(shù)據(jù)幀）時(shí)，它被分派到上游服務(wù)。當(dāng)讀取RST_STREAM幀時(shí)，請(qǐng)求的本地狀態(tài)將被拆除，并通知上游請(qǐng)求已被取消。沖洗并重復(fù)，直到耗盡整個(gè)緩沖區(qū)。然而，這種邏輯可能會(huì)被濫用：當(dāng)惡意客戶端開(kāi)始發(fā)送大量請(qǐng)求鏈并在連接開(kāi)始時(shí)重置時(shí)，我們的服務(wù)器會(huì)急切地讀取所有請(qǐng)求，并對(duì)上游服務(wù)器造成壓力，導(dǎo)致無(wú)法處理任何新傳入的請(qǐng)求。

需要強(qiáng)調(diào)的重要一點(diǎn)是，流并發(fā)本身無(wú)法緩解快速重置。無(wú)論服務(wù)器選擇的SETTINGS_MAX_CONCURRENT_STREAMS值如何，客戶端都可以攪動(dòng)請(qǐng)求以創(chuàng)建高請(qǐng)求率。

快速重置剖析

以下是使用概念驗(yàn)證客戶端嘗試發(fā)出總共1000個(gè)請(qǐng)求的快速重置示例。我使用了現(xiàn)成的服務(wù)器，沒(méi)有任何緩解措施；在測(cè)試環(huán)境中偵聽(tīng)端口443。為了清楚起見(jiàn)，使用Wireshark剖析流量并進(jìn)行過(guò)濾以僅顯示HTTP/2流量。下載pcap以進(jìn)行后續(xù)操作。

有點(diǎn)難看，因?yàn)橛泻芏鄮?。我們可以通過(guò)Wireshark的Statistics>HTTP2工具得到一個(gè)快速的總結(jié)：

此跟蹤中的第一幀（數(shù)據(jù)包14中）是服務(wù)器的SETTINGS幀，它通告最大流并發(fā)數(shù)為100。在數(shù)據(jù)包15中，客戶端發(fā)送一些控制幀，然后開(kāi)始發(fā)出快速重置的請(qǐng)求。第一個(gè)HEADERS幀長(zhǎng)26個(gè)字節(jié)，所有后續(xù)的HEADERS只有9個(gè)字節(jié)。這種大小差異是由于稱為HPACK的壓縮技術(shù)造成的。數(shù)據(jù)包15總共包含525個(gè)請(qǐng)求，直至流1051。

有趣的是，流1051的RST_STREAM不適合數(shù)據(jù)包15，因此在數(shù)據(jù)包16中我們看到服務(wù)器以404響應(yīng)進(jìn)行響應(yīng)。然后，在數(shù)據(jù)包17中，客戶端發(fā)送RST_STREAM，然后繼續(xù)發(fā)送剩余的475個(gè)請(qǐng)求。

請(qǐng)注意，雖然服務(wù)器通告了100個(gè)并發(fā)流，但客戶端發(fā)送的兩個(gè)數(shù)據(jù)包發(fā)送的HEADERS幀比這多得多?？蛻舳瞬槐氐却?wù)器的任何返回流量，它僅受其可以發(fā)送的數(shù)據(jù)包大小的限制。在此跟蹤中沒(méi)有看到服務(wù)器RST_STREAM幀，這表明服務(wù)器沒(méi)有觀察到并發(fā)流違規(guī)。

對(duì)客戶的影響

如上所述，當(dāng)請(qǐng)求被取消時(shí)，上游服務(wù)會(huì)收到通知，并可以在浪費(fèi)太多資源之前中止請(qǐng)求。這次攻擊就是這種情況，大多數(shù)惡意請(qǐng)求從未轉(zhuǎn)發(fā)到源服務(wù)器。然而，這些攻擊的規(guī)模確實(shí)造成了一些影響。

首先，隨著傳入請(qǐng)求的速率達(dá)到前所未有的峰值，我們收到了客戶發(fā)現(xiàn)的502錯(cuò)誤數(shù)量增加的報(bào)告。這種情況發(fā)生在我們受影響最嚴(yán)重的數(shù)據(jù)中心，因?yàn)樗鼈冋谂μ幚硭姓?qǐng)求。讓我們更深入地了解細(xì)節(jié)，重點(diǎn)關(guān)注傳入請(qǐng)求到達(dá)我們的數(shù)據(jù)中心之一時(shí)如何處理：

我們可以看到我們的基礎(chǔ)設(shè)施由一系列具有不同職責(zé)的不同代理服務(wù)器組成。特別是，當(dāng)客戶端連接到Cloudflare發(fā)送HTTPS流量時(shí)，它首先會(huì)命中我們的TLS解密代理：它解密TLS流量，處理HTTP 1、2或3流量，然后將其轉(zhuǎn)發(fā)到我們的“業(yè)務(wù)邏輯”代理。它負(fù)責(zé)加載每個(gè)客戶的所有設(shè)置，然后將請(qǐng)求正確路由到其他上游服務(wù)-更重要的是，在我們的例子中，它還負(fù)責(zé)安全功能。這是處理L7攻擊緩解的地方。

這種攻擊媒介的問(wèn)題在于它能夠在每個(gè)連接中非?？焖俚匕l(fā)送大量請(qǐng)求。在我們有機(jī)會(huì)阻止它們之前，它們中的每一個(gè)都必須轉(zhuǎn)發(fā)到業(yè)務(wù)邏輯代理。隨著請(qǐng)求吞吐量變得高于我們的代理容量，連接這兩個(gè)服務(wù)的管道在我們的一些服務(wù)器中達(dá)到了飽和水平。

發(fā)生這種情況時(shí)，TLS代理無(wú)法再連接到其上游代理，這就是為什么某些客戶端在最嚴(yán)重的攻擊期間看到“502 Bad Gateway”錯(cuò)誤的原因。值得注意的是，截至今天，用于創(chuàng)建HTTP分析的日志也由我們的業(yè)務(wù)邏輯代理發(fā)出。其結(jié)果是這些錯(cuò)誤在Cloudflare儀表板中不可見(jiàn)。我們的內(nèi)部?jī)x表板顯示，大約1%的請(qǐng)求在第一波攻擊期間（在我們實(shí)施緩解措施之前）受到影響，在8月29日最嚴(yán)重的攻擊期間，峰值在12%左右，持續(xù)了幾秒鐘。下圖顯示了發(fā)生這種情況時(shí)兩個(gè)小時(shí)內(nèi)這些錯(cuò)誤的比率：

我們?cè)诮酉聛?lái)的幾天里努力大幅減少這個(gè)數(shù)字，本文稍后將詳細(xì)介紹。由于我們堆棧的變化以及我們的緩解措施大大減少了這些攻擊的規(guī)模，今天這個(gè)數(shù)字實(shí)際上為零：

499錯(cuò)誤和HTTP/2流并發(fā)的挑戰(zhàn)

一些客戶報(bào)告的另一個(gè)癥狀是499錯(cuò)誤增加。其原因有點(diǎn)不同，與本文前面詳細(xì)介紹的HTTP/2連接中的最大流并發(fā)有關(guān)。

HTTP/2設(shè)置在連接開(kāi)始時(shí)使用SETTINGS幀進(jìn)行交換。如果沒(méi)有接收顯式參數(shù)，則應(yīng)用默認(rèn)值。一旦客戶端建立了HTTP/2連接，它就可以等待服務(wù)器的設(shè)置（慢），也可以采用默認(rèn)值并開(kāi)始發(fā)出請(qǐng)求（快）。對(duì)于SETTINGS_MAX_CONCURRENT_STREAMS，默認(rèn)值實(shí)際上是無(wú)限制的（流ID使用31位數(shù)字空間，請(qǐng)求使用奇數(shù)，因此實(shí)際限制為1073741824）。規(guī)范建議服務(wù)器提供不少于100個(gè)流?？蛻舳送ǔＦ蛴谒俣?，因此不要等待服務(wù)器設(shè)置，這會(huì)產(chǎn)生一些競(jìng)爭(zhēng)條件。客戶端正在對(duì)服務(wù)器可能選擇的限制進(jìn)行賭博；如果他們選擇錯(cuò)誤，請(qǐng)求將被拒絕并必須重試。在1073741824流上賭博有點(diǎn)愚蠢。相反，許多客戶端決定限制自己發(fā)出100個(gè)并發(fā)流，希望服務(wù)器遵循規(guī)范建議。當(dāng)服務(wù)器選擇低于100的值時(shí)，客戶端賭博就會(huì)失敗并且流會(huì)被重置。

服務(wù)器重置流超出并發(fā)限制的原因有很多。HTTP/2是嚴(yán)格的，要求在出現(xiàn)解析或邏輯錯(cuò)誤時(shí)關(guān)閉流。2019年，Cloudflare開(kāi)發(fā)了多種緩解措施來(lái)應(yīng)對(duì)HTTP/2 DoS漏洞。其中幾個(gè)漏洞是由客戶端行為不當(dāng)引起的，導(dǎo)致服務(wù)器重置流。遏制此類客戶端的一個(gè)非常有效的策略是計(jì)算連接期間服務(wù)器重置的次數(shù)，當(dāng)超過(guò)某個(gè)閾值時(shí)，使用GOAWAY幀關(guān)閉連接。合法客戶可能會(huì)在連接中犯一兩個(gè)錯(cuò)誤，這是可以接受的。犯太多錯(cuò)誤的客戶端可能已損壞或惡意，關(guān)閉連接可以解決這兩種情況。

在響應(yīng)CVE-2023-44487啟用的DoS攻擊時(shí)，Cloudflare將最大流并發(fā)數(shù)降低到64。在進(jìn)行此更改之前，我們沒(méi)有意識(shí)到客戶端不會(huì)等待SETTINGS，而是假設(shè)并發(fā)數(shù)為100。某些網(wǎng)頁(yè)，例如作為一個(gè)圖片庫(kù)，確實(shí)會(huì)導(dǎo)致瀏覽器在連接開(kāi)始時(shí)立即發(fā)送100個(gè)請(qǐng)求。不幸的是，超出限制的36個(gè)流都需要重置，這觸發(fā)了我們的計(jì)數(shù)緩解措施。這意味著我們關(guān)閉了合法客戶端上的連接，導(dǎo)致頁(yè)面加載完全失敗。當(dāng)我們意識(shí)到這個(gè)互操作性問(wèn)題后，我們將最大流并發(fā)數(shù)更改為100。

Cloudflare措施和建議

2019年，發(fā)現(xiàn)了多個(gè)與HTTP/2實(shí)現(xiàn)相關(guān)的DoS漏洞。Cloudflare開(kāi)發(fā)并部署了一系列檢測(cè)和緩解措施作為響應(yīng)。CVE-2023-44487是HTTP/2漏洞的另一種表現(xiàn)形式。然而，為了緩解這一問(wèn)題，我們能夠擴(kuò)展現(xiàn)有的保護(hù)措施來(lái)監(jiān)視客戶端發(fā)送的RST_STREAM幀，并在它們被濫用時(shí)關(guān)閉連接。RST_STREAM的合法客戶端使用不受影響。

除了直接修復(fù)之外，我們還對(duì)服務(wù)器的HTTP/2幀處理和請(qǐng)求分派代碼進(jìn)行了多項(xiàng)改進(jìn)。此外，業(yè)務(wù)邏輯服務(wù)器還對(duì)排隊(duì)和調(diào)度進(jìn)行了改進(jìn)，減少了不必要的工作并提高了取消響應(yīng)能力。這些共同減少了各種潛在濫用模式的影響，并為服務(wù)器在飽和之前提供了更多空間來(lái)處理請(qǐng)求。

盡早緩解攻擊

Cloudflare已經(jīng)擁有適當(dāng)?shù)南到y(tǒng)，可以通過(guò)更便宜的方法有效地緩解非常大的攻擊。其中之一被命名為“IP Jail”。對(duì)于超容量攻擊，該系統(tǒng)會(huì)收集參與攻擊的客戶端IP，并阻止它們連接到受攻擊的財(cái)產(chǎn)（無(wú)論是在IP級(jí)別還是在我們的TLS代理中）。然而，該系統(tǒng)需要幾秒鐘才能完全生效；在這寶貴的幾秒鐘內(nèi)，源頭已經(jīng)受到保護(hù)，但我們的基礎(chǔ)設(shè)施仍然需要吸收所有HTTP請(qǐng)求。由于這種新的僵尸網(wǎng)絡(luò)實(shí)際上沒(méi)有啟動(dòng)期，因此我們需要能夠在攻擊成為問(wèn)題之前將其消滅。

為了實(shí)現(xiàn)這一目標(biāo)，我們擴(kuò)展了IP Jail系統(tǒng)來(lái)保護(hù)我們的整個(gè)基礎(chǔ)設(shè)施：一旦IP被“監(jiān)禁”，不僅會(huì)阻止它連接到受攻擊的財(cái)產(chǎn)，我們還會(huì)禁止相應(yīng)的IP使用HTTP/2訪問(wèn)任何其他域在Cloudflare上使用了一段時(shí)間。由于使用HTTP/1.x不可能進(jìn)行此類協(xié)議濫用，因此這限制了攻擊者運(yùn)行大型攻擊的能力，而共享同一IP的任何合法客戶端在此期間只會(huì)看到非常小的性能下降?；贗P的緩解措施是一種非常生硬的工具——這就是為什么我們?cè)诖笠?guī)模使用它們時(shí)必須非常小心，并盡可能避免誤報(bào)。此外，僵尸網(wǎng)絡(luò)中給定IP的生命周期通常很短，因此任何長(zhǎng)期緩解措施都可能弊大于利。下圖顯示了我們目睹的攻擊中IP的流失情況：

正如我們所看到的，在某一天發(fā)現(xiàn)的許多新IP隨后很快就消失了。

由于所有這些操作都發(fā)生在HTTPS管道開(kāi)始處的TLS代理中，因此與常規(guī)L7緩解系統(tǒng)相比，這可以節(jié)省大量資源。這使我們能夠更順利地抵御這些攻擊，現(xiàn)在由這些僵尸網(wǎng)絡(luò)引起的隨機(jī)502錯(cuò)誤數(shù)量已降至零。

攻擊可觀測(cè)性改進(jìn)

我們正在做出改變的另一個(gè)方面是可觀察性。在客戶分析中不可見(jiàn)的情況下向客戶返回錯(cuò)誤是不令人滿意的。幸運(yùn)的是，早在最近的攻擊發(fā)生之前，一個(gè)對(duì)這些系統(tǒng)進(jìn)行徹底檢修的項(xiàng)目就已經(jīng)開(kāi)始進(jìn)行。最終，它將允許我們基礎(chǔ)設(shè)施中的每個(gè)服務(wù)記錄自己的數(shù)據(jù)，而不是依賴我們的業(yè)務(wù)邏輯代理來(lái)合并和發(fā)出日志數(shù)據(jù)。這次事件凸顯了這項(xiàng)工作的重要性，我們正在加倍努力。

我們還致力于更好的連接級(jí)日志記錄，使我們能夠更快地發(fā)現(xiàn)此類協(xié)議濫用，從而提高我們的DDoS緩解能力。

結(jié)論

雖然這是最新的破紀(jì)錄攻擊，但我們知道這不會(huì)是最后一次。隨著攻擊變得越來(lái)越復(fù)雜，Cloudflare不斷努力主動(dòng)識(shí)別新威脅-為我們的全球網(wǎng)絡(luò)部署對(duì)策，以便我們數(shù)百萬(wàn)的客戶立即得到自動(dòng)保護(hù)。