史上最大 DDoS 降臨 GitHub：每秒 1.269 億個數據包，峰值達到了 1.35 Tbps

科技 03-03

文章來源GitHub博客，雲頭條編譯

2018年2月28日星期三，由於一起分散式拒絕服務（DDoS）攻擊，GitHub.com從17：21至17：26 UTC（協調時間時）處於癱瘓狀態，從17：26至17：30處於時斷時續的狀態。我們深知大家對GitHub的依賴程度，也知道我們服務的可用性對用戶而言至關重要。需要特別說明的是，用戶數據的機密性或完整性在任何時候都沒有處於險境。我們為此事件帶來的影響感到抱歉，為此撰文介紹這起事件、我們為確保可用性付出的努力以及我們將來如何旨在改善響應和應對。

背景介紹

Cloudflare在本周的博文中描述了一個使用memcached針對UDP發動放大攻擊的途徑，詳見《Memcrashed：來自 UDP 埠 11211 的大規模放大攻擊》。攻擊者採用的手法是，濫用互聯網上無意中可被訪問、UDP支持功能被啟用的memcached實例。欺騙IP地址的做法讓memcached的響應得以被攻擊者用來對另一個地址發動攻擊，比如用於服務GitHub.com的地址，並向目標發送更多的數據，未受到欺騙的Source（源頭）不需要發送那麼多的數據。那篇博文中描述的配置不當引起的安全漏洞在這一類攻擊中顯得有點獨特，原因在於放大係數高達51000倍，這意味著攻擊者每發送一個位元組，最多可向目標發送51KB的數據。

在過去的一年，我們為自己的設施部署了額外的轉接容量。在此期間，我們的轉接容量增加了一倍以上，這讓我們得以抵禦某些容量耗盡攻擊（volumetric attack），並不對用戶造成影響。我們將繼續部署額外的轉接容量，並在一系列廣泛的交換中心之間建立起了穩健的對等互聯（peering）關係。即使如此，像這樣的攻擊有時還是需要擁有更龐大轉接網路的合作夥伴給予幫助，才能提供攔截和過濾服務。

事件經過

2月28日17：21至17:30 UTC，我們發現並緩解了一次重大的DDoS容量耗盡攻擊。這次攻擊來自1000多個不同的自治系統（ASN），涉及成千上萬個獨特端點。這是一起放大攻擊，使用上述基於memcached的方法，通過每秒發送1.269億個數據包，峰值速度達到了1.35Tbps。

在17：21 UTC，我們的網路監控系統檢測到入站流量與出站流量比異常，並使用聊天系統通知了隨時待命的工程師及其他人。該圖顯示了轉接鏈路上的入站吞吐量與出站吞吐量：

該圖顯示入站流量大於出站流量

考慮到在我們的一個設施，入站轉接帶寬增加到超過100Gbps，我們決定將流量轉到Akamai，它可以幫助提供額外的邊緣網路容量。在17：26，我們通過ChatOps工具執行了命令，撤銷針對轉接提供商發布的BGP通告，完全在通向Akamai的鏈路上通告AS36459。在接下來幾分鐘，路由重新聚合，訪問控制列表在邊界處緩解了攻擊。監控轉接帶寬數量和負載均衡系統響應代碼表明，系統在17：30完全恢復。在17：34，撤銷了通向互聯網交換中心的路由，這是一個後續措施，將額外的40Gbps從我們的邊緣轉出去。

該圖顯示了流量從交換中心轉出去

攻擊的第一波在高峰期間速度達到1.35Tbps，在18：00過後迎來了第二波小高峰：400Gbps。Akamai提供的這張圖顯示了抵達其邊緣的入站流量（每秒比特數）：

發放akamai邊緣的流量

下幾步

確保GitHub的邊緣基礎設施更能適應互聯網當前和未來的情況，並且少依賴人的干預，這需要更好的自動化干預機制。我們正在研究使用我們的監控基礎設施使提供商緩解DDoS攻擊實現自動化，並繼續衡量響應此類事件的時間，旨在縮短平均恢復時間（MTTR）。

我們會繼續擴大我們的邊緣網路，竭力在新的攻擊途徑影響您在GitHub.com上的工作流程之前識別並緩解這些攻擊。

我們知道您高度依賴GitHub確保項目和公司取得成功。我們會繼續分析影響我們可用性的諸如此類的事件，構建更好的檢測系統，並簡化響應機制。

Memcrashed：來自 UDP 埠 11211 的大規模放大攻擊

文章來自cloudflare公司博客，作者Marek Majkowski

在過去這幾天，我們發現一種隱蔽的放大攻擊途徑非常猖獗：這種攻擊使用memcached協議，來自UDP埠11211。

過去我們多次談論過發生在互聯網上的放大攻擊。最近關於該話題的兩篇博文是：

《突破100Gbps的SSDP放大》（https://blog.cloudflare.com/ssdp-100gbps/）。有意思的是，從那以後，我們成了一種速度為196Gbps的SSDP攻擊的對象。

《關於我們看到的各种放大攻擊的一般性統計數字》（https://blog.cloudflare.com/reflections-on-reflections/）。

所有放大攻擊背後的基本思路都一樣。能夠實施IP欺騙的攻擊者向一台易受攻擊的UDP伺服器發送偽造的請求。UDP伺服器不知道請求是偽造的，準備響應。成千上萬個響應被發往一個渾然不知的目標主機時，大量耗用資源，通常網路本身不堪重負，這時會出現問題。

放大攻擊之所以屢屢得逞，是由於響應數據包常常比請求數據包大得多。一種精心準備的攻擊手法讓IP欺騙能力有限（比如1Gbps）的攻擊者可以發動規模非常大的攻擊（達到100s Gbps），從而「放大」攻擊者的帶寬。

Memcrashed

隱蔽的放大攻擊一直在發生。我們常常看到「chargen」或「call of duty」數據包攻擊我們的伺服器。

不過很少發現一種新的放大效果非常出色的放大攻擊途徑，這種新的memcached UDP DDoS絕對屬於這一類。

奇虎360的DDosMon監測放大攻擊途徑，該圖表顯示了最近的memcached/11211攻擊：

雖然每秒數據包數量不是特別大，但生成的帶寬卻特別大：

高峰時期，我們看到入站UDP memcached流量的速度達到260Gbps。對於一種新的放大攻擊途徑而言，這個數字很大。而數字不會謊言。這是由於所有反射的數據包都非常大。這是它在運行tcpdump後的結果：

大部分數據包的大小是1400位元組。簡單算一下，23Mpps x 1400位元組得出257Gbps的帶寬，正如上圖所示。

Memcached使用UDP？

我驚訝地發現memcached使用UDP，但確實如此！協議規範（https://github.com/memcached/memcached/blob/master/doc/protocol.txt）表明，UDP是迄今用於放大攻擊的最佳協議之一！毫無檢查機制，數據會以驚人的速度發往客戶端！此外，請求可能很小，響應很大（高達1MB）。

發動這種攻擊很容易。首先，攻擊者在一台泄露的memcached伺服器上植入很大的有效載荷（payload）。然後，攻擊者利用目標的Source IP欺騙「get」請求消息。

使用Tcpdump的綜合運行顯示流量：

15個位元組的請求觸發了134KB的響應。放大係數是10000倍！實際上，我們還見過15個位元組的請求觸發750kB的響應（放大了51200倍）。

Source IP

易受攻擊的memcached伺服器遍布全球，在北美和歐洲更為密集。下圖顯示了我們在120多個接入點（POP）看到的Source IP分布圖：