訂閱以接收新文章的通知:

Cloudflare 如何自動緩解一起破世界紀錄的 3.8 Tbps DDoS 攻擊

2024-10-02

閱讀時間:9 分鐘
本貼文還提供以下語言版本:EnglishFrançaisDeutsch日本語한국어PortuguêsEspañol简体中文

自 9 月初以來,Cloudflare 的 DDoS 防護系統一直在對抗一起長達一個月的超流量第 3/4 層 DDoS 攻擊。Cloudflare 防禦系統在整個月內緩解了一百多次超容量第 3/4 層 DDoS 攻擊,許多攻擊超過每秒 20 億個封包 (Bpps) 和每秒 3 TB (Tbps)。最大攻擊峰值達到了 3.8 Tbps,這是迄今為止所有組織公開披露的攻擊中規模最大的一次攻擊。偵測和緩解完全自主完成。下圖顯示了針對同一 Cloudflare 客戶且均已被自主緩解的兩次不同的攻擊事件。

BLOG-2586 2

一起持續 65 秒的每秒 3.8 TB 的 DDoS 攻擊(已緩解)

BLOG-2586 3

一起持續 60 秒的每秒 21.4 億個封包的 DDoS 攻擊(已緩解)

Cloudflare 客戶受到保護

使用 Cloudflare HTTP 反向代理服務(如 Cloudflare WAFCloudflare CDN)的 Cloudflare 客戶會自動受到保護。

使用 SpectrumMagic Transit 的 Cloudflare 客戶也會自動受到保護。Magic Transit 客戶可以透過部署 Magic Firewall 規則來進一步最佳化其保護,以在封包層實施嚴格的主動和被動安全模型。

其他網際網路內容可能並不安全

這些攻擊的規模和頻率前所未有。由於其龐大的規模和每秒位元數/封包速率,這些攻擊能夠摧毀未受保護的網際網路內容、受內部部署設備保護的網際網路內容,以及受網路容量或全球覆蓋範圍不足以在不影響效能的同時處理這些流量和合法流量的雲端提供者保護的網際網路內容。 

而 Cloudflare 確實擁有吸收和自動緩解這些巨大攻擊所需的網路容量、全球覆蓋範圍和智慧系統。 

在這篇部落格文章中,我們將回顧這次攻擊活動,以及其攻擊如此嚴重的原因。我們將詳細解析第 3/4 層 DDoS 攻擊、其目標以及攻擊產生過程。然後,我們將詳細介紹 Cloudflare 的系統如何能夠在不影響客戶效能的情況下自主偵測和緩解這些巨大攻擊。我們將介紹我們防禦系統的主要方面,包括我們的系統如何產生即時(動態)簽章以比對攻擊流量,以及我們如何利用核心功能以線速捨棄封包。

活動分析

我們觀察到這次攻擊活動針對金融服務、網際網路和電信業等產業的多家客戶。這次攻擊活動的目標是頻寬飽和以及內嵌應用程式和裝置的資源耗盡。

這些攻擊主要利用固定連接埠上的 UDP,來源遍布全球,其中越南、俄羅斯、巴西、西班牙和美國占比較大。

高封包速率攻擊似乎源自多種被入侵裝置,包括 MikroTik 裝置、DVR 和 Web 伺服器,這些裝置經過精心策劃,協同工作,用異常大量的流量淹沒目標。高位元率攻擊似乎源於大量遭到入侵的 ASUS 家用路由器,可能是利用 Censys 最近發現的 CVE 9.8(嚴重)漏洞

BLOG-2586 4

DDoS 攻擊剖析

在我們討論 Cloudflare 如何自動偵測和緩解有史以來最大規模的 DDoS 攻擊之前,瞭解 DDoS 攻擊的基礎知識非常重要。 

BLOG-2586 5

DDoS 攻擊的簡化圖

分散式阻斷服務 (DDoS) 攻擊的目標是拒絕合法使用者存取服務。這通常是透過耗盡提供服務所需的資源來完成的。在最近發生的第 3/4 層 DDoS 攻擊中,該資源是 CPU 週期和網路頻寬。

耗盡 CPU 週期

處理封包會消耗 CPU 週期。在常規(非攻擊)流量的情況下,服務收到的合法封包將導致該服務執行某些動作,並且不同的動作需要不同數量的 CPU 處理。然而,在將封包傳送到服務之前,需要完成每個封包的工作。需要剖析和處理第 3 層封包標頭,以將封包傳送到正確的機器和介面。需要處理第 4 層封包標頭並將其路由到正確的套接字(如果有)。可能有多個其他處理步驟來檢查每個封包。因此,如果攻擊者以足夠高的封包速率傳送封包,那麼他們可能會導致可用 CPU 資源飽和,從而拒絕向合法使用者提供服務。

BLOG-2586 6

要抵禦高封包速率攻擊,您需要能夠使用盡可能少的 CPU 週期檢查並捨棄不良封包,從而留下足夠的 CPU 來處理良好封包。您也可以購買更多或更快的 CPU 來執行處理,但這可能是一個非常漫長的過程,成本也很高。 

耗盡網路頻寬

網路頻寬是每次可以傳送到伺服器的資料總量。您可以將頻寬想像成輸水的管道。我們透過吸管輸送的水量少於透過花園軟管輸送的水量。如果攻擊者能夠將超出管道傳送能力的垃圾資料推送到管道中,那麼壞資料好資料都將在管道入口處的上游被丟棄,這就是 DDoS 攻擊會成功的原因。

BLOG-2586 7

防禦可能導致網路頻寬飽和的攻擊可能很困難,因為如果您位於飽和管道的下游側,則無能為力。實際上只有幾個選擇:您可以購買更大的管道,您可以找到一種方法將良好的流量轉移到未飽和的新管道,或者您可以要求管道的上游側停止將部分或全部資料傳送至管道。

產生 DDoS 攻擊

如果我們從攻擊者的角度考慮這意味著什麼,您就會意識到存在類似的限制。就像接收封包需要 CPU 週期一樣,建立封包也需要 CPU 週期。例如,如果傳送和接收封包的成本相等,那麼攻擊者將需要與我們防禦攻擊所需的相同 CPU 能力來產生攻擊。在大多數情況下,情況並非如此——存在成本不對稱,因為攻擊者能夠使用比接收這些封包更少的 CPU 週期來產生封包。然而,值得注意的是,產生攻擊並不是免費的,並且可能需要大量的 CPU 能力。

對於攻擊者來說,使網路頻寬飽和甚至更加困難。這種情況下,攻擊者需要能夠輸出比目標服務配置的更多的頻寬。他們實際上需要能夠超出接收服務的容量。這非常困難,以至於實現網路頻寬攻擊的最常見方法是使用反射/放大攻擊方法,例如 DNS 放大攻擊。這些攻擊允許攻擊者向中間服務傳送小封包,而中間服務將向受害者發送大封包。

在這兩種情況下,攻擊者都需要取得或存取許多裝置才能發動攻擊。這些裝置可以透過多種不同的方式獲得。它們可能是來自雲端提供者或託管服務的伺服器類電腦,也可能是受到攻擊者惡意程式碼感染的 DVR、路由器和網路攝影機等受感染裝置。這些機器共同構成了殭屍網路。

Cloudflare 如何防禦大型攻擊

現在我們已經瞭解了 DDoS 攻擊的基本原理,我們可以解釋 Cloudflare 如何防禦這些攻擊了。

使用全球 Anycast 分散攻擊面

第一個不那麼秘密的原因是,Cloudflare 的網路是建立在 Anycast 之上的。簡而言之,Anycast 允許世界各地的多台機器通告單一 IP 位址。傳送至該 IP 位址的封包將由最近的機器提供服務。這意味著當攻擊者使用其分散式殭屍網路發動攻擊時,攻擊將由 Cloudflare 網路分散接收。德克薩斯州達拉斯的受感染 DVR 會將封包傳送到達拉斯的 Cloudflare 伺服器。倫敦受感染的網路攝影機會將封包傳送到倫敦的 Cloudflare 伺服器。

BLOG-2586 8

Anycast 與 Unicast 網路

我們的 Anycast 網路還允許 Cloudflare 將最近的運算和頻寬資源配置到最需要它們的地區。人口密集的地區會產生大量的合法流量,位於這些地區的資料中心將擁有更多的頻寬和 CPU 資源來滿足這些需求。人口稀少的地區自然會產生較少的合法流量,因此可以適當調整這些地區的 Cloudflare 資料中心的規模。由於攻擊流量主要來自受感染的裝置,因此這些裝置往往會以與正常流量相符的方式進行分佈,將攻擊流量按比例傳送到可以處理它的資料中心。同樣,在資料中心內,流量分散到多台機器。

此外,對於高頻寬攻擊,Cloudflare 的網路還有另一個優勢。Cloudflare 網路上的很大一部分流量並不以對稱方式消耗頻寬。例如,從 Cloudflare 後面的網站取得網頁的 HTTP 請求將是一個相對較小的傳入封包,但會產生大量傳回用戶端的傳出流量。這意味著 Cloudflare 網路發出的合法流量往往比我們收到的流量多得多。然而,配置的網路連結和頻寬是對稱的,這意味著有大量的輸入頻寬可用於接收巨流量攻擊流量。

產生即時簽章

當您到達資料中心內的單個伺服器時,攻擊的頻寬已經足夠分散,沒有任何上游連結飽和。這並不意味著已經完全阻止攻擊,因為我們尚未丟棄不良封包。為此,我們需要對流量進行採樣,對攻擊進行限定,並建立規則來封鎖不良封包。 

對流量進行採樣並丟棄不良封包是我們的 l4drop 元件的工作,該元件使用 XDP (eXpress Data Path) 並利用稱為 eBPF(擴展 BPF)的 Berkeley 封包篩選器的擴展版本。這使我們能夠在核心空間中執行自訂程式碼,並直接在網路介面卡 (NIC) 層級處理(丟棄、轉送或修改)每個封包。此元件可以幫助系統有效地丟棄封包,而不會消耗機器上過多的 CPU 資源。

BLOG-2586 9

Cloudflare DDoS 防護系統概觀

我們使用 XDP 對封包進行採樣,以查找表明存在攻擊的可疑屬性。範例包括來源 IP、來源連接埠、目的地 IP、目的地連接埠、通訊協定、TCP 標誌、序號、選項、封包速率等欄位。此分析由阻斷服務精靈 (dosd) 執行。Dosd 掌握著我們的秘密武器。它有許多篩選器,可根據我們策劃的啟發式方法指導它何時啟動緩解措施。對於我們的客戶來說,這些篩選器按攻擊媒介進行邏輯分組,並作為 DDoS 受管理規則公開。我們的客戶可以根據需要在某種程度上自訂其行為

當 dosd 收到來自 XDP 的樣本時,它將針對可疑流量模式產生多種指紋排列。然後,dosd 將使用資料串流演算法識別最佳指紋來減輕攻擊。一旦限定了攻擊的範圍,dosd 就會將緩解規則作為 eBPF 程式內嵌推送,以手術方式丟棄攻擊流量。 

Dosd 對攻擊的偵測和緩解是在伺服器層級、資料中心層級和全球層級完成的,而且都是由軟體定義的。這使得我們的網路極具彈性,並幾乎可以立即緩解。不存在偏離路徑的「清除中心」或「清除裝置」。相反,每台伺服器都執行完整的 Cloudflare 產品套件,包括 DDoS 偵測和緩解元件。而且這一切都是自主完成的。每個伺服器也會在資料中心內的伺服器之間以及全域資料中心之間傳播(多點傳送)緩解指令。這確保了無論攻擊是局部的還是全球分散的,dosd 都已經內嵌安裝了緩解規則,以確保可靠的緩解。

針對強攻擊的強大防禦能力

我們自主的軟體定義 DDoS 偵測和緩解系統在整個網路中執行。在這篇文章中,我們主要關注我們的動態指紋辨識功能,但我們的防禦系統庫要大得多。Advanced TCP Protection 系統和 Advanced DNS Protection 系統與我們的動態指紋辨識一起工作,識別複雜且高度隨機的 TCP 型 DDoS 攻擊,並利用統計分析來遏止基於 DNS 的複雜 DDoS 攻擊。我們的防禦措施還結合了即時威脅情報、流量分析和機器學習分類,作為我們自適應 DDoS 防護的一部分,以緩解流量異常。

這些系統與全面的 Cloudflare 安全性產品組合一起建立在 Cloudflare 網路(世界上最大的網路之一)之上,以確保我們的客戶免受世界上最大規模的攻擊。

我們保護整個企業網路,協助客戶有效地建置網際網路規模的應用程式,加速任何網站或網際網路應用程式抵禦 DDoS 攻擊,阻止駭客入侵,並且可以協助您實現 Zero Trust

從任何裝置造訪 1.1.1.1,即可開始使用我們的免費應用程式,讓您的網際網路更快速、更安全。

若要進一步瞭解我們協助打造更好的網際網路的使命,請從這裡開始。如果您正在尋找新的職業方向,請查看我們的職缺
DDoSAttacksTrends安全性

在 X 上進行關注

Shawn Bohrer|@bohrers
Omer Yoachimik|@OmerYoahimik
Alex Forster|@alex_forster
Nick Wood|@nickgwood
Cloudflare|@cloudflare

相關貼文

2024年9月27日 下午1:00

Advancing cybersecurity: Cloudflare implements a new bug bounty VIP program as part of CISA Pledge commitment

Cloudflare strengthens its commitment to cybersecurity by joining CISA's "Secure by Design" pledge. In line with this commitment, we're enhancing our vulnerability disclosure policy by launching a VIP bug bounty program, giving top researchers early access to our products. Keep an eye out for future updates regarding Cloudflare's CISA pledge as we work together to shape a safer digital future....

2024年9月27日 下午1:00

Network trends and natural language: Cloudflare Radar’s new Data Explorer & AI Assistant

The Cloudflare Radar Data Explorer provides a simple Web-based interface to build more complex API queries, including comparisons and filters, and visualize the results. The accompanying AI Assistant translates a user’s natural language statements or questions into the appropriate Radar API calls....