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

如果您正在遭受類似攻擊或想尋求增強安全防護支持               

檢測和緩解情況概述

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

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

這種攻擊是通過濫用 HTTP/2 協(xié)議的某些功能和服務器實現(xiàn)細節(jié)而實現(xiàn)的。 由于該攻擊利用了 HTTP/2 協(xié)議中的潛在弱點，因此我們相信任何實施了 HTTP/2 的供應商都將受到攻擊。 這包括所有現(xiàn)代網(wǎng)絡服務器。 我們與 Google 和 AWS 一起向 Web 服務器供應商披露了攻擊方法，我們預計他們將實施補丁。 與此同時，最好的防御措施是在任何 Web 或 API 服務器前面使用 Cloudflare 等 DDoS 緩解服務。

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

RST攻擊細節(jié)

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

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

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

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

在 HTTP/2 中，我們對 https://blog.cloudflare.com 的 GET 請求將通過流 ID 1 進行交換，客戶端發(fā)送一個 HEADERS 幀，服務器使用一個 HEADERS 幀進行響應，后跟一個或多個 DATA 幀。 客戶端請求始終使用奇數(shù)流 ID，因此后續(xù)請求將使用流 ID 3、5 等。 可以以任何順序提供響應，并且來自不同流的幀可以交織。

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

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

真實的故事有點復雜。 流有生命周期。 下圖是 HTTP/2 流狀態(tài)機的示意圖。 客戶端和服務器管理自己的流狀態(tài)視圖。 HEADERS、DATA 和 RST_STREAM 幀在發(fā)送或接收時會觸發(fā)轉(zhuǎn)換。 雖然流狀態(tài)的視圖是獨立的，但它們是同步的。

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

讓我們通過一個沒有消息內(nèi)容的 GET 請求示例來解決這個問題。 客戶端以 HEADERS 幀的形式發(fā)送請求，并將 END_STREAM 標志設置為 1?？蛻舳耸紫葘⒘鲝目臻e狀態(tài)轉(zhuǎn)換為打開狀態(tài)，然后立即轉(zhuǎn)換為半關閉狀態(tài)。 客戶端半關閉狀態(tài)意味著它不能再發(fā)送HEADERS或DATA，只能發(fā)送 WINDOW_UPDATE、PRIORITY或RST_STREAM幀。 然而它可以接收任何幀。

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

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

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

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

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

HTTP/2 請求取消

早些時候，我們討論了客戶取消傳遞中請求的情況。 HTTP/2 以比 HTTP/1.1 更有效的方式支持這一點。 客戶端可以為單個流發(fā)送 RST_STREAM 幀，而不需要拆除整個連接。 這指示服務器停止處理請求并中止響應，從而釋放服務器資源并避免浪費帶寬。

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

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

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

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

快速重置導致拒絕服務

HTTP/2 請求取消可能被濫用來快速重置無限數(shù)量的流。 當 HTTP/2 服務器能夠足夠快地處理客戶端發(fā)送的 RST_STREAM 幀并拆除狀態(tài)時，這種快速重置不會導致問題。 當整理工作出現(xiàn)任何延誤或滯后時，問題就會開始出現(xiàn)。 客戶端可能會處理大量請求，從而導致工作積壓，從而導致服務器上資源的過度消耗。

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

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

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

快速重置剖析

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

有點難看，因為有很多幀。 我們可以通過Wireshark的Statistics > HTTP2工具得到一個快速的總結(jié)：

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

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

請注意，雖然服務器通告了 100 個并發(fā)流，但客戶端發(fā)送的兩個數(shù)據(jù)包發(fā)送的 HEADERS 幀比這多得多。 客戶端不必等待服務器的任何返回流量，它僅受其可以發(fā)送的數(shù)據(jù)包大小的限制。 在此跟蹤中沒有看到服務器 RST_STREAM 幀，這表明服務器沒有觀察到并發(fā)流違規(guī)。

對客戶的影響

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

首先，隨著傳入請求的速率達到前所未有的峰值，我們收到了客戶發(fā)現(xiàn)的 502 錯誤數(shù)量增加的報告。 這種情況發(fā)生在我們受影響最嚴重的數(shù)據(jù)中心，因為它們正在努力處理所有請求。讓我們更深入地了解細節(jié)，重點關注傳入請求到達我們的數(shù)據(jù)中心之一時如何處理：

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

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

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

我們在接下來的幾天里努力大幅減少這個數(shù)字，本文稍后將詳細介紹。 由于我們堆棧的變化以及我們的緩解措施大大減少了這些攻擊的規(guī)模，今天這個數(shù)字實際上為零：

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

一些客戶報告的另一個癥狀是 499 錯誤增加。 其原因有點不同，與本文前面詳細介紹的 HTTP/2 連接中的最大流并發(fā)有關。

HTTP/2 設置在連接開始時使用 SETTINGS 幀進行交換。 如果沒有接收顯式參數(shù)，則應用默認值。 一旦客戶端建立了 HTTP/2 連接，它就可以等待服務器的設置（慢），也可以采用默認值并開始發(fā)出請求（快）。 對于 SETTINGS_MAX_CONCURRENT_STREAMS，默認值實際上是無限制的（流 ID 使用 31 位數(shù)字空間，請求使用奇數(shù)，因此實際限制為 1073741824）。 規(guī)范建議服務器提供不少于 100 個流。 客戶端通常偏向于速度，因此不要等待服務器設置，這會產(chǎn)生一些競爭條件。 客戶端正在對服務器可能選擇的限制進行賭博； 如果他們選擇錯誤，請求將被拒絕并必須重試。 在 1073741824 流上賭博有點愚蠢。 相反，許多客戶端決定限制自己發(fā)出 100 個并發(fā)流，希望服務器遵循規(guī)范建議。 當服務器選擇低于 100 的值時，客戶端賭博就會失敗并且流會被重置。

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

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

Cloudflare措施和建議

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

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

盡早緩解攻擊

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

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

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

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

攻擊可觀測性改進

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

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

結(jié)論

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

自 2017 年以來，Cloudflare 一直為我們的所有客戶提供免費、不計量且無限制的 DDoS 保護。此外，我們還提供一系列附加安全功能，以滿足各種規(guī)模組織的需求。 如果您不確定自己是否受到保護或想了解如何受到保護。