GitHub 遭遇史上最大規模 DDoS 攻擊

關鍵時刻，第一時間送達！

據外媒 Wired 報道，美國東部時間本周三下午 12:15，知名代碼託管網站GitHub 遭遇了史上最大規模的 DDoS 網路攻擊，每秒 1.35 TB 的流量瞬間衝擊了這一開發者平台。

來自 DDoS 攻擊的實時流量

儘管 GitHub 曾試圖反抗，但最終還是藉助DDoS 防禦服務提供商Akamai Prolexic 提供的幫助才得以艱難度過。Prolexic 接管了 GitHub 所有的信息流，通過清除和阻止惡意數據包迫使襲擊者停止了攻擊。Akamai 網路安全副總裁 Josh Shau 表示，「我們是基於互聯網所見過的最大規模攻擊的五倍來建模的，以前從沒有遇到過這麼大的流量」。

作為全球最大的社交編程及代碼託管網站，GitHub 一直很受攻擊者的歡迎。2013 年 1 月 15 日，來自 12306 搶票插件用戶的大量訪問導致 GitHub 訪問大幅放緩。2015 年 3 月 26 日，攻擊者利用劫持百度 JS 文件、跨域 攻擊、DDoS 攻擊、TCP SYN 攻擊等方式持續狂轟GitHub 達六天之久。然而本周三的猛攻，卻是 GitHub 有史以來面臨的最嚴重的 DDoS 攻擊事件。

據悉，本次攻擊並非依賴於傳統的殭屍網路，而是使用了 Memcached 伺服器。該伺服器的設計初衷是提升內部網路的訪問速度，而且是不應該被暴露在互聯網中的，但是根據 Akamai 的調查，至少有超過 5 萬台此類伺服器連接到了伺服器上，因此非常容易受到攻擊。犯罪分子可利用 Memcache 伺服器通過非常少的計算資源發動超大規模的 DDoS 攻擊，該漏洞是由於 Memcache 開發人員對 UDP 協議支持方式不安全所導致的，黑客能通過它輕易實現「反射型 DDoS 攻擊」。

那麼什麼是反射型 DDoS 攻擊？犯罪分子是如何利用 UDP 協議進行攻擊的？我們應該採取什麼方式去減少它所帶來的危害？360CERT 昨日發布的 Memcrashed 預警公告進行了解答。

事件背景

黑客利用 Memcache 協議，會發送大量帶有被害者 IP 地址的 UDP 數據包給放大?主機，然後放大?主機對偽造的 IP 地址源做出大量回應，形成分散式拒絕服務攻擊，從而形成 DDoS 反射。

攻擊強度

根據 360netlab DDoSMon 監測結果顯示， 近期內 Memcrashed 事件攻擊情況不斷上升，且由於 Memcache 作為放大器的利用，近幾天攻擊事件開始陡增，影響極為廣泛。

漏洞細節

關於 DDoS 放大：

作為攻擊者，需要偽造 IP，發送?量量偽造來源的請求。未採取 BCP38 的機房（firewallrules and uRPF）；

作為反射服務?，需要滿足 2 個條件。第一，上面運行著容易放大的 UDP 協議，即使用設計不當的UDP服務，能夠滿足特定條件下，響應包遠遠大於請求包。第二，該協議或服務在互聯網上有一定的使用量，如 DNS、NTP 等基礎服務；

受害者一般是金融、遊戲、政治等目標，或出於破壞、炫技等目的。

關於 Memcrashed：

由於 Memcache 同時監聽 TCP 和 UDP，天然滿足反射 DDoS 條件；

Memcache 作為企業應用組建，其業務特性保證了具有較高上傳帶寬；

Memcache 不需要認證即可進行交互；

很多用戶在編譯安裝時，將服務錯誤監聽在 0.0.0.0，且未進行 iptables 規則配置或雲安全租戶配置。

攻擊流程：

掃描全網埠服務；

進行指紋識別，獲取未認證的 Memcache；

過濾所有可以反射的 UDP Memcache；

插入數據狀態進行反射。

緩解措施

對於 Memcache 使用者：

Memcache 的用戶建議將服務放置於可信域內，有外網時不要監聽 0.0.0.0，有特殊需求可以設置 ACL 或者添加安全組；

為預防機器?掃描和 SSRF 等攻擊，修改 Memcache 默認監聽埠；

升級到最新版本的 Memcache，並且使用 SASL 設置密碼來進行許可權控制。

對於網路層防禦：

多個 ISP 已經對 UDP11211 進行限速；

打擊攻擊源，互聯網服務提供商應當禁止在網路上執行 IP 欺騙；

ISP 應允許用戶使用 BGP flowspec 限制入站 UDP11211 的流量，以減輕大型 DRDoS 攻擊時的擁堵。

參考鏈接：

https://www.wired.com/story/github-ddos-memcached/

https://cert.360.cn/warning

本文關於Memcrashed 的技術解讀來源於 360CERT。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！