據外媒 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 文件、跨域< img >攻擊、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 攻擊時的擁堵。

責任編輯：韓希宇