從2023年8月25日開始，我們開始注意到一些異常嚴(yán)重的HTTP攻擊攻擊了很多我們的用戶。幸運的是我們的自動化DDoS系統(tǒng)檢測到并緩解了這些攻擊。然而，沒過多久，它們的規(guī)模就開始達到破紀(jì)錄的水平，并最終達到每秒略高于2.01億個請求的峰值。這相當(dāng)于我們之前有記錄以來最大攻擊規(guī)模的三倍。而更令人擔(dān)憂的是，攻擊者能夠利用僅由20,000臺機器組成的僵尸網(wǎng)絡(luò)發(fā)起此類攻擊。而如今的僵尸網(wǎng)絡(luò)規(guī)模可達數(shù)十萬或數(shù)百萬臺機器。整個web網(wǎng)絡(luò)通常每秒處理10-30億個請求，因此使用此方法可以將整個web網(wǎng)絡(luò)的請求數(shù)量等級集中在少數(shù)目標(biāo)上，而這并非不可想象。
如果您正在遭受類似攻擊或想尋求增強安全防護支持，請即刻聯(lián)系我們。
檢測和緩解情況概述
這是一種規(guī)?？涨暗男滦凸羰侄?，Cloudflare現(xiàn)有的保護措施在很大程度上能夠抵御這種攻擊的沖擊。雖然最初我們看到了對客戶流量的一些影響（在第一波攻擊期間影響了大約1%的請求），但今天我們已經(jīng)能夠改進我們的緩解方法，以阻止任何針對Cloudflare客戶的攻擊，也不影響我們自身的系統(tǒng)正常運行。
我們注意到這些攻擊的同時，另外兩個主要行業(yè)參與者——谷歌和AWS——也看到了同樣的情況。我們致力于強化Cloudflare的系統(tǒng)，以確保今天我們的所有客戶都能免受這種新的DDoS攻擊方法的影響，而不會對客戶造成任何影響。我們還與Google和AWS合作，向受影響的供應(yīng)商和關(guān)鍵基礎(chǔ)設(shè)施提供商協(xié)調(diào)披露此次攻擊。
這種攻擊是通過濫用HTTP/2協(xié)議的某些功能和服務(wù)器實現(xiàn)細(xì)節(jié)而實現(xiàn)的（有關(guān)詳細(xì)信息，請參閱CVE-2023-44487）。由于該攻擊利用了HTTP/2協(xié)議中的潛在弱點，因此我們相信任何實施了HTTP/2的供應(yīng)商都將受到攻擊。這包括所有現(xiàn)代網(wǎng)絡(luò)服務(wù)器。我們與Google和AWS一起向Web服務(wù)器供應(yīng)商披露了攻擊方法，我們預(yù)計他們將實施補丁。與此同時，最好的防御措施是在任何Web或API服務(wù)器前面使用Cloudflare等DDoS緩解服務(wù)。
這篇文章深入探討了HTTP/2協(xié)議的詳細(xì)信息、攻擊者用來生成這些大規(guī)模攻擊的方法，以及我們?yōu)榇_保所有客戶受到保護而采取的緩解策略。我們希望通過發(fā)布這些詳細(xì)信息，其他受影響的網(wǎng)絡(luò)服務(wù)器和服務(wù)將獲得實施緩解策略所需的信息。此外，HTTP/2協(xié)議標(biāo)準(zhǔn)團隊以及致力于未來Web標(biāo)準(zhǔn)的團隊可以更好地設(shè)計它們以防止此類攻擊。
RST攻擊細(xì)節(jié)
HTTP是為Web提供支持的應(yīng)用程序協(xié)議。HTTP語義對于所有版本的HTTP都是通用的—整體架構(gòu)、術(shù)語和協(xié)議方面，例如請求和響應(yīng)消息、方法、狀態(tài)代碼、標(biāo)頭和尾部字段、消息內(nèi)容等等。每個單獨的HTTP版本都定義了如何將語義轉(zhuǎn)換為“有線格式”以通過Internet進行交換。例如，客戶端必須將請求消息序列化為二進制數(shù)據(jù)并發(fā)送，然后服務(wù)器將其解析回它可以處理的消息。
HTTP/1.1使用文本形式的序列化。請求和響應(yīng)消息作為ASCII字符流進行交換，通過可靠的傳輸層（如TCP）發(fā)送，使用以下格式（其中CRLF表示回車和換行）：
例如，對于https://blog.cloudflare.com/的一個非常簡單的GET請求在線路上將如下所示：
響應(yīng)將如下所示：
這種格式在線路上構(gòu)造消息，這意味著可以使用單個TCP連接來交換多個請求和響應(yīng)。但是，該格式要求每條消息都完整發(fā)送。此外，為了正確地將請求與響應(yīng)關(guān)聯(lián)起來，需要嚴(yán)格的排序；這意味著消息是串行交換的并且不能多路復(fù)用。https://blog.cloudflare.com/和https://blog.cloudflare.com/page/2/的兩個GET請求將是：
而response是：
網(wǎng)頁需要比這些示例更復(fù)雜的HTTP交互。訪問Cloudflare博客時，您的瀏覽器將加載多個腳本、樣式和媒體資產(chǎn)。如果您使用HTTP/1.1訪問首頁并決定快速導(dǎo)航到第2頁，您的瀏覽器可以從兩個選項中進行選擇。在第2頁甚至可以啟動之前，等待您不再需要的頁面的所有排隊響應(yīng)，或者通過關(guān)閉TCP連接并打開新連接來取消正在進行的請求。這些都不太實用。瀏覽器傾向于通過管理TCP連接池（每個主機最多6個）并在池上實現(xiàn)復(fù)雜的請求分派邏輯來解決這些限制。
HTTP/2解決了HTTP/1.1的許多問題。每個HTTP消息都被序列化為一組HTTP/2幀，這些幀具有類型、長度、標(biāo)志、流標(biāo)識符（ID）和有效負(fù)載。流ID清楚地表明線路上的哪些字節(jié)適用于哪個消息，從而允許安全的多路復(fù)用和并發(fā)。流是雙向的。客戶端發(fā)送幀，服務(wù)器使用相同的ID回復(fù)幀。
在HTTP/2中，我們對https://blog.cloudflare.com的GET請求將通過流ID 1進行交換，客戶端發(fā)送一個HEADERS幀，服務(wù)器使用一個HEADERS幀進行響應(yīng)，后跟一個或多個DATA幀?？蛻舳苏埱笫冀K使用奇數(shù)流ID，因此后續(xù)請求將使用流ID 3、5等。可以以任何順序提供響應(yīng)，并且來自不同流的幀可以交織。
流復(fù)用和并發(fā)是HTTP/2的強大功能。它們可以更有效地使用單個TCP連接。HTTP/2優(yōu)化了資源獲取，尤其是與優(yōu)先級結(jié)合使用時。另一方面，與HTTP/1.1相比，使客戶端能夠輕松啟動大量并行工作可能會增加對服務(wù)器資源的峰值需求。這是一個明顯的拒絕服務(wù)向量。
為了提供一些防護，HTTP/2提供了最大活動并發(fā)流的概念。SETTINGS_MAX_CONCURRENT_STREAMS參數(shù)允許服務(wù)器通告其并發(fā)限制。例如，如果服務(wù)器規(guī)定限制為100，則任何時候只能有100個請求處于活動狀態(tài)。如果客戶端嘗試打開超過此限制的流，則服務(wù)器必須使用RST_STREAM幀拒絕它。流拒絕不會影響連接上的其他正在進行的流。
真實的故事有點復(fù)雜。流有生命周期。下圖是HTTP/2流狀態(tài)機的示意圖?？蛻舳撕头?wù)器管理自己的流狀態(tài)視圖。HEADERS、DATA和RST_STREAM幀在發(fā)送或接收時會觸發(fā)轉(zhuǎn)換。雖然流狀態(tài)的視圖是獨立的，但它們是同步的。
HEADERS和DATA幀包含END_STREAM標(biāo)志，當(dāng)設(shè)置為值1（真）時，可以觸發(fā)狀態(tài)轉(zhuǎn)換。
讓我們通過一個沒有消息內(nèi)容的GET請求示例來解決這個問題?？蛻舳艘訦EADERS幀的形式發(fā)送請求，并將END_STREAM標(biāo)志設(shè)置為1。客戶端首先將流從空閑狀態(tài)轉(zhuǎn)換為打開狀態(tài)，然后立即轉(zhuǎn)換為半關(guān)閉狀態(tài)?？蛻舳税腙P(guān)閉狀態(tài)意味著它不能再發(fā)送HEADERS或DATA，只能發(fā)送WINDOW_UPDATE、PRIORITY或RST_STREAM幀。然而它可以接收任何幀。
一旦服務(wù)器接收并解析了HEADERS幀，它就會將流狀態(tài)從空閑轉(zhuǎn)變?yōu)榇蜷_，然后半關(guān)閉，因此它與客戶端匹配。服務(wù)器半關(guān)閉狀態(tài)意味著它可以發(fā)送任何幀，但只能接收WINDOW_UPDATE、PRIORITY或RST_STREAM幀。
對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)客戶端收到它時，它也會轉(zhuǎn)換為關(guān)閉狀態(tài)。一旦流關(guān)閉，就無法發(fā)送或接收任何幀。
將此生命周期應(yīng)用回并發(fā)上下文中，HTTP/2指出：
處于“打開”狀態(tài)或任一“半關(guān)閉”狀態(tài)的流計入允許端點打開的最大流數(shù)。處于這三種狀態(tài)中任何一種狀態(tài)的流都會計入SETTINGS_MAX_CONCURRENT_STREAMS設(shè)置中公布的限制。
理論上，并發(fā)限制是有用的。然而，有一些實際因素阻礙了其有效性——我們將在本文后續(xù)介紹。
HTTP/2請求取消
早些時候，我們討論了客戶取消傳遞中請求的情況。HTTP/2以比HTTP/1.1更有效的方式支持這一點?？蛻舳丝梢詾閱蝹€流發(fā)送RST_STREAM幀，而不需要拆除整個連接。這指示服務(wù)器停止處理請求并中止響應(yīng)，從而釋放服務(wù)器資源并避免浪費帶寬。
讓我們考慮一下之前的3個請求的示例。這次，在發(fā)送所有標(biāo)頭后，客戶端取消了流1上的請求。服務(wù)器在準(zhǔn)備好提供響應(yīng)之前解析此RST_STREAM幀，并且僅響應(yīng)流3和5：
請求取消是一個有用的功能。例如，當(dāng)滾動包含多個圖像的網(wǎng)頁時，網(wǎng)絡(luò)瀏覽器可以取消落在視口之外的圖像，這意味著進入視口的圖像可以更快地加載。與HTTP/1.1相比，HTTP/2使這種行為更加高效。
被取消的請求流會快速過渡整個流生命周期。END_STREAM標(biāo)志設(shè)置為1的客戶端HEADERS狀態(tài)從空閑狀態(tài)轉(zhuǎn)換為打開狀態(tài)再到半關(guān)閉狀態(tài)，然后RST_STREAM立即導(dǎo)致從半關(guān)閉狀態(tài)轉(zhuǎn)換為關(guān)閉狀態(tài)。
回想一下，只有處于打開或半關(guān)閉狀態(tài)的流才會影響流并發(fā)限制。當(dāng)客戶端取消流時，它立即能夠在其位置打開另一個流，并可以立即發(fā)送另一個請求。這是CVE-2023-44487發(fā)揮作用的關(guān)鍵。
快速重置導(dǎo)致拒絕服務(wù)
HTTP/2請求取消可能被濫用來快速重置無限數(shù)量的流。當(dāng)HTTP/2服務(wù)器能夠足夠快地處理客戶端發(fā)送的RST_STREAM幀并拆除狀態(tài)時，這種快速重置不會導(dǎo)致問題。當(dāng)整理工作出現(xiàn)任何延誤或滯后時，問題就會開始出現(xiàn)?？蛻舳丝赡軙幚泶罅空埱螅瑥亩鴮?dǎo)致工作積壓，從而導(dǎo)致服務(wù)器上資源的過度消耗。
常見的HTTP部署架構(gòu)是在其他組件之前運行HTTP/2代理或負(fù)載均衡器。當(dāng)客戶端請求到達時，它會被快速分派，并且實際工作在其他地方作為異步活動完成。這使得代理能夠非常有效地處理客戶端流量。然而，這種關(guān)注點分離可能會使代理很難整理正在進行的作業(yè)。因此，這些部署更有可能遇到快速重置帶來的問題。
當(dāng)Cloudflare的反向代理處理傳入的HTTP/2客戶端流量時，它們會將數(shù)據(jù)從連接的套接字復(fù)制到緩沖區(qū)中，并按順序處理緩沖的數(shù)據(jù)。當(dāng)讀取每個請求（標(biāo)頭和數(shù)據(jù)幀）時，它被分派到上游服務(wù)。當(dāng)讀取RST_STREAM幀時，請求的本地狀態(tài)將被拆除，并通知上游請求已被取消。沖洗并重復(fù)，直到耗盡整個緩沖區(qū)。然而，這種邏輯可能會被濫用：當(dāng)惡意客戶端開始發(fā)送大量請求鏈并在連接開始時重置時，我們的服務(wù)器會急切地讀取所有請求，并對上游服務(wù)器造成壓力，導(dǎo)致無法處理任何新傳入的請求。
需要強調(diào)的重要一點是，流并發(fā)本身無法緩解快速重置。無論服務(wù)器選擇的SETTINGS_MAX_CONCURRENT_STREAMS值如何，客戶端都可以攪動請求以創(chuàng)建高請求率。
快速重置剖析
以下是使用概念驗證客戶端嘗試發(fā)出總共1000個請求的快速重置示例。我使用了現(xiàn)成的服務(wù)器，沒有任何緩解措施；在測試環(huán)境中偵聽端口443。為了清楚起見，使用Wireshark剖析流量并進行過濾以僅顯示HTTP/2流量。下載pcap以進行后續(xù)操作。
有點難看，因為有很多幀。我們可以通過Wireshark的Statistics>HTTP2工具得到一個快速的總結(jié)：
此跟蹤中的第一幀（數(shù)據(jù)包14中）是服務(wù)器的SETTINGS幀，它通告最大流并發(fā)數(shù)為100。在數(shù)據(jù)包15中，客戶端發(fā)送一些控制幀，然后開始發(fā)出快速重置的請求。第一個HEADERS幀長26個字節(jié)，所有后續(xù)的HEADERS只有9個字節(jié)。這種大小差異是由于稱為HPACK的壓縮技術(shù)造成的。數(shù)據(jù)包15總共包含525個請求，直至流1051。
有趣的是，流1051的RST_STREAM不適合數(shù)據(jù)包15，因此在數(shù)據(jù)包16中我們看到服務(wù)器以404響應(yīng)進行響應(yīng)。然后，在數(shù)據(jù)包17中，客戶端發(fā)送RST_STREAM，然后繼續(xù)發(fā)送剩余的475個請求。
請注意，雖然服務(wù)器通告了100個并發(fā)流，但客戶端發(fā)送的兩個數(shù)據(jù)包發(fā)送的HEADERS幀比這多得多?？蛻舳瞬槐氐却?wù)器的任何返回流量，它僅受其可以發(fā)送的數(shù)據(jù)包大小的限制。在此跟蹤中沒有看到服務(wù)器RST_STREAM幀，這表明服務(wù)器沒有觀察到并發(fā)流違規(guī)。
對客戶的影響
如上所述，當(dāng)請求被取消時，上游服務(wù)會收到通知，并可以在浪費太多資源之前中止請求。這次攻擊就是這種情況，大多數(shù)惡意請求從未轉(zhuǎn)發(fā)到源服務(wù)器。然而，這些攻擊的規(guī)模確實造成了一些影響。
首先，隨著傳入請求的速率達到前所未有的峰值，我們收到了客戶發(fā)現(xiàn)的502錯誤數(shù)量增加的報告。這種情況發(fā)生在我們受影響最嚴(yán)重的數(shù)據(jù)中心，因為它們正在努力處理所有請求。讓我們更深入地了解細(xì)節(jié)，重點關(guān)注傳入請求到達我們的數(shù)據(jù)中心之一時如何處理：
我們可以看到我們的基礎(chǔ)設(shè)施由一系列具有不同職責(zé)的不同代理服務(wù)器組成。特別是，當(dāng)客戶端連接到Cloudflare發(fā)送HTTPS流量時，它首先會命中我們的TLS解密代理：它解密TLS流量，處理HTTP 1、2或3流量，然后將其轉(zhuǎn)發(fā)到我們的“業(yè)務(wù)邏輯”代理。它負(fù)責(zé)加載每個客戶的所有設(shè)置，然后將請求正確路由到其他上游服務(wù)-更重要的是，在我們的例子中，它還負(fù)責(zé)安全功能。這是處理L7攻擊緩解的地方。
這種攻擊媒介的問題在于它能夠在每個連接中非?？焖俚匕l(fā)送大量請求。在我們有機會阻止它們之前，它們中的每一個都必須轉(zhuǎn)發(fā)到業(yè)務(wù)邏輯代理。隨著請求吞吐量變得高于我們的代理容量，連接這兩個服務(wù)的管道在我們的一些服務(wù)器中達到了飽和水平。
發(fā)生這種情況時，TLS代理無法再連接到其上游代理，這就是為什么某些客戶端在最嚴(yán)重的攻擊期間看到“502 Bad Gateway”錯誤的原因。值得注意的是，截至今天，用于創(chuàng)建HTTP分析的日志也由我們的業(yè)務(wù)邏輯代理發(fā)出。其結(jié)果是這些錯誤在Cloudflare儀表板中不可見。我們的內(nèi)部儀表板顯示，大約1%的請求在第一波攻擊期間（在我們實施緩解措施之前）受到影響，在8月29日最嚴(yán)重的攻擊期間，峰值在12%左右，持續(xù)了幾秒鐘。下圖顯示了發(fā)生這種情況時兩個小時內(nèi)這些錯誤的比率：
我們在接下來的幾天里努力大幅減少這個數(shù)字，本文稍后將詳細(xì)介紹。由于我們堆棧的變化以及我們的緩解措施大大減少了這些攻擊的規(guī)模，今天這個數(shù)字實際上為零：
499錯誤和HTTP/2流并發(fā)的挑戰(zhàn)
一些客戶報告的另一個癥狀是499錯誤增加。其原因有點不同，與本文前面詳細(xì)介紹的HTTP/2連接中的最大流并發(fā)有關(guān)。
HTTP/2設(shè)置在連接開始時使用SETTINGS幀進行交換。如果沒有接收顯式參數(shù)，則應(yīng)用默認(rèn)值。一旦客戶端建立了HTTP/2連接，它就可以等待服務(wù)器的設(shè)置（慢），也可以采用默認(rèn)值并開始發(fā)出請求（快）。對于SETTINGS_MAX_CONCURRENT_STREAMS，默認(rèn)值實際上是無限制的（流ID使用31位數(shù)字空間，請求使用奇數(shù)，因此實際限制為1073741824）。規(guī)范建議服務(wù)器提供不少于100個流?？蛻舳送ǔＦ蛴谒俣?，因此不要等待服務(wù)器設(shè)置，這會產(chǎn)生一些競爭條件。客戶端正在對服務(wù)器可能選擇的限制進行賭博；如果他們選擇錯誤，請求將被拒絕并必須重試。在1073741824流上賭博有點愚蠢。相反，許多客戶端決定限制自己發(fā)出100個并發(fā)流，希望服務(wù)器遵循規(guī)范建議。當(dāng)服務(wù)器選擇低于100的值時，客戶端賭博就會失敗并且流會被重置。
服務(wù)器重置流超出并發(fā)限制的原因有很多。HTTP/2是嚴(yán)格的，要求在出現(xiàn)解析或邏輯錯誤時關(guān)閉流。2019年，Cloudflare開發(fā)了多種緩解措施來應(yīng)對HTTP/2 DoS漏洞。其中幾個漏洞是由客戶端行為不當(dāng)引起的，導(dǎo)致服務(wù)器重置流。遏制此類客戶端的一個非常有效的策略是計算連接期間服務(wù)器重置的次數(shù)，當(dāng)超過某個閾值時，使用GOAWAY幀關(guān)閉連接。合法客戶可能會在連接中犯一兩個錯誤，這是可以接受的。犯太多錯誤的客戶端可能已損壞或惡意，關(guān)閉連接可以解決這兩種情況。
在響應(yīng)CVE-2023-44487啟用的DoS攻擊時，Cloudflare將最大流并發(fā)數(shù)降低到64。在進行此更改之前，我們沒有意識到客戶端不會等待SETTINGS，而是假設(shè)并發(fā)數(shù)為100。某些網(wǎng)頁，例如作為一個圖片庫，確實會導(dǎo)致瀏覽器在連接開始時立即發(fā)送100個請求。不幸的是，超出限制的36個流都需要重置，這觸發(fā)了我們的計數(shù)緩解措施。這意味著我們關(guān)閉了合法客戶端上的連接，導(dǎo)致頁面加載完全失敗。當(dāng)我們意識到這個互操作性問題后，我們將最大流并發(fā)數(shù)更改為100。
Cloudflare措施和建議
2019年，發(fā)現(xiàn)了多個與HTTP/2實現(xiàn)相關(guān)的DoS漏洞。Cloudflare開發(fā)并部署了一系列檢測和緩解措施作為響應(yīng)。CVE-2023-44487是HTTP/2漏洞的另一種表現(xiàn)形式。然而，為了緩解這一問題，我們能夠擴展現(xiàn)有的保護措施來監(jiān)視客戶端發(fā)送的RST_STREAM幀，并在它們被濫用時關(guān)閉連接。RST_STREAM的合法客戶端使用不受影響。
除了直接修復(fù)之外，我們還對服務(wù)器的HTTP/2幀處理和請求分派代碼進行了多項改進。此外，業(yè)務(wù)邏輯服務(wù)器還對排隊和調(diào)度進行了改進，減少了不必要的工作并提高了取消響應(yīng)能力。這些共同減少了各種潛在濫用模式的影響，并為服務(wù)器在飽和之前提供了更多空間來處理請求。
盡早緩解攻擊
Cloudflare已經(jīng)擁有適當(dāng)?shù)南到y(tǒng)，可以通過更便宜的方法有效地緩解非常大的攻擊。其中之一被命名為“IP Jail”。對于超容量攻擊，該系統(tǒng)會收集參與攻擊的客戶端IP，并阻止它們連接到受攻擊的財產(chǎn)（無論是在IP級別還是在我們的TLS代理中）。然而，該系統(tǒng)需要幾秒鐘才能完全生效；在這寶貴的幾秒鐘內(nèi)，源頭已經(jīng)受到保護，但我們的基礎(chǔ)設(shè)施仍然需要吸收所有HTTP請求。由于這種新的僵尸網(wǎng)絡(luò)實際上沒有啟動期，因此我們需要能夠在攻擊成為問題之前將其消滅。
為了實現(xiàn)這一目標(biāo)，我們擴展了IP Jail系統(tǒng)來保護我們的整個基礎(chǔ)設(shè)施：一旦IP被“監(jiān)禁”，不僅會阻止它連接到受攻擊的財產(chǎn)，我們還會禁止相應(yīng)的IP使用HTTP/2訪問任何其他域在Cloudflare上使用了一段時間。由于使用HTTP/1.x不可能進行此類協(xié)議濫用，因此這限制了攻擊者運行大型攻擊的能力，而共享同一IP的任何合法客戶端在此期間只會看到非常小的性能下降?；贗P的緩解措施是一種非常生硬的工具——這就是為什么我們在大規(guī)模使用它們時必須非常小心，并盡可能避免誤報。此外，僵尸網(wǎng)絡(luò)中給定IP的生命周期通常很短，因此任何長期緩解措施都可能弊大于利。下圖顯示了我們目睹的攻擊中IP的流失情況：
正如我們所看到的，在某一天發(fā)現(xiàn)的許多新IP隨后很快就消失了。
由于所有這些操作都發(fā)生在HTTPS管道開始處的TLS代理中，因此與常規(guī)L7緩解系統(tǒng)相比，這可以節(jié)省大量資源。這使我們能夠更順利地抵御這些攻擊，現(xiàn)在由這些僵尸網(wǎng)絡(luò)引起的隨機502錯誤數(shù)量已降至零。
攻擊可觀測性改進
我們正在做出改變的另一個方面是可觀察性。在客戶分析中不可見的情況下向客戶返回錯誤是不令人滿意的。幸運的是，早在最近的攻擊發(fā)生之前，一個對這些系統(tǒng)進行徹底檢修的項目就已經(jīng)開始進行。最終，它將允許我們基礎(chǔ)設(shè)施中的每個服務(wù)記錄自己的數(shù)據(jù)，而不是依賴我們的業(yè)務(wù)邏輯代理來合并和發(fā)出日志數(shù)據(jù)。這次事件凸顯了這項工作的重要性，我們正在加倍努力。
我們還致力于更好的連接級日志記錄，使我們能夠更快地發(fā)現(xiàn)此類協(xié)議濫用，從而提高我們的DDoS緩解能力。
結(jié)論
雖然這是最新的破紀(jì)錄攻擊，但我們知道這不會是最后一次。隨著攻擊變得越來越復(fù)雜，Cloudflare不斷努力主動識別新威脅-為我們的全球網(wǎng)絡(luò)部署對策，以便我們數(shù)百萬的客戶立即得到自動保護。
Cloudflare
專欄
閩公網(wǎng)安備 35010202001226號
