2018年進(jìn)入3月份以來，知名代碼托管網(wǎng)站 GitHub 就遭遇了有史以來最嚴(yán)重的 DDoS 網(wǎng)絡(luò)攻擊，峰值流量達(dá)到了前所未有的 1.35Tbps。消息一出，全世界的程序員立馬炸了鍋，知道我們這里有多少牛人么，連我們都敢黑？！
作為開源代碼庫以及版本控制系統(tǒng)，Github 擁有上百萬的開發(fā)者用戶，被坊間稱為程序員的“另類”社交網(wǎng)絡(luò)、 全球最大的黑客聚集地。
但即使社區(qū)牛人再多，它也未逃 DDoS 攻擊魔掌，據(jù)外媒 bleepingcomputer 透露，攻擊者是利用前不久公開的 Memcached 漏洞執(zhí)行攻擊，能成倍的放大攻擊效果，被稱為 DRDoS 反射攻擊。
那么，與傳統(tǒng)的 DDoS 相比，何為 DRDoS 反射攻擊？Github 目前情況如何？如再有黑客利用 Memcached 漏洞進(jìn)行攻擊，應(yīng)該怎么防？
從小米加步槍到飛機加大炮
大家都知道，DDoS 攻擊的特點就是利用如潮水般的流量同時涌入網(wǎng)站，不過本次攻擊不同之處在于采用了更厲害的放大技術(shù)，目的是能對主機服務(wù)器產(chǎn)生更嚴(yán)重的影響。
其實，Memcache 本身是一套分布式的高速緩存系統(tǒng)，目前被許多網(wǎng)站使用以提升網(wǎng)站的訪問速度，尤其對于一些大型的、需要頻繁訪問數(shù)據(jù)庫的網(wǎng)站效果顯著。
其實早有安全團隊在去年年中就針對 Memcache 放大的攻擊技術(shù)發(fā)布了預(yù)警。
之所以被稱作放大的 DDoS 攻擊，是因為攻擊者利用 Memcached 協(xié)議，發(fā)送大量帶有被害者 IP 地址的 UDP 數(shù)據(jù)包給主機，然后放大，主機對偽造的 IP 地址源做回應(yīng)，形成分布式拒絕服務(wù)攻擊，從而形成 DRDoS 反射。
對這次事件和相關(guān)技術(shù)進(jìn)行了持續(xù)監(jiān)控的 360 安全團隊 0Kee Team 李豐沛介紹，之所以 Memcached 被黑客盯上，有兩個原因。
一是因為當(dāng)被用作反射點時，它的放大倍數(shù)超高，可超過 5 萬倍。對比其他常見 DDoS 的反射點，放大比率通常只有 10 到 100 倍之前。
比如，一個 203 字節(jié)的傳入 Memcached 請求會導(dǎo)致大約 100 兆字節(jié)的響應(yīng)。
如果說之前傳統(tǒng)的 DDoS 攻擊是小米加步槍，這次針對 Memcache 的 DRDoS 攻擊則是飛機加大炮。
二是，Memcached 服務(wù)器往往是企業(yè)用來做數(shù)據(jù)服務(wù)的，所以服務(wù)器的資源好，有比較大的帶寬。如果單臺服務(wù)器能打出 1Gbps 攻擊帶寬的話，只要 1000 臺服務(wù)器就能打出 1Tbps 的攻擊帶寬了。而 11 月份統(tǒng)計的數(shù)據(jù)線網(wǎng)中受影響的設(shè)備可能有 6 萬臺。
其實，為了安全起見，Memcache 應(yīng)該是不能暴露在互聯(lián)網(wǎng)中的。此類服務(wù)器沒有認(rèn)證協(xié)議，連接到互聯(lián)網(wǎng)中意味著任何人都可以查詢它們。
在此前的研究報告中，360 的 0Kee 團隊預(yù)估 Memcached 服務(wù)器可能會被濫用以發(fā)起約 2Tbps 的 DDoS 攻擊，也就是說，這次針對 GitHub 的攻擊也許只用了六七成的功力。
目前 GitHub 情況如何？其他網(wǎng)站如何預(yù)防？
據(jù)雷鋒網(wǎng)了解，GitHub 在得到 Akamai 的幫助后，在不到 10 分鐘的時間內(nèi)化解了這次危機。GitHub 也證實，網(wǎng)站上用戶數(shù)據(jù)的機密性和完整性沒有受到影響。
恩，程序員哥哥們的頭發(fā)沒有白掉，代碼還在。
據(jù)了解，目前在外開放的 Memcache 存儲系統(tǒng)數(shù)量級在十萬左右，都可能會受到此類攻擊影響。而且預(yù)計會出現(xiàn)更多利用 Memcached 進(jìn)行 DRDoS 的事件，如果本次攻擊效果被其他 DDoS 團隊所效仿，將會帶來后果更嚴(yán)重的攻擊。
李豐沛告訴雷鋒網(wǎng)，暴露在互聯(lián)網(wǎng)中歸根結(jié)底是用戶和他的供應(yīng)商的選擇，之后建議大家就不要輕易暴露，即使暴露，也應(yīng)該加上用戶口令認(rèn)證或者網(wǎng)絡(luò)訪問限制等。
以下是他提出的相關(guān)建議。
對于 Memcache 使用者，
1. Memcache 的用戶建議將服務(wù)放置于可信域內(nèi)，有外網(wǎng)時不要監(jiān)聽 0.0.0.0，有特殊需求可以設(shè)置 acl 或者添加安全組。
2. 為預(yù)防機器?掃描和 ssrf 等攻擊，修改 memcache 默認(rèn)監(jiān)聽端口。
3. 升級到最新版本的 memcache，并且使用 SASL 設(shè)置密碼來進(jìn)行權(quán)限控制。
對于網(wǎng)絡(luò)層防御，
1. 多個 ISP 已經(jīng)對 UDP11211 進(jìn)行限速。
2. 打擊攻擊源：互聯(lián)網(wǎng)服務(wù)提供商應(yīng)當(dāng)禁止在網(wǎng)絡(luò)上執(zhí)行 IP 欺騙。IP 欺騙 DRDoS 的根本原因。具體措施可以參考 BCP38。
3. ISP 應(yīng)允許用戶使用 BGP flowspec 限制入站 UDP11211 的流量，以減輕大型 DRDoS 攻擊時的擁堵。
延伸閱讀：2015 年 GitHub 也曾遭遇 DDoS 攻擊
要說，這也不是 GitHub 第一次被黑客盯上了。
早在 2015 年 3 月 26 日，它就遭遇了當(dāng)時也被稱為“史上最大規(guī)模的 DDoS 攻擊”，而且一直持續(xù)到了 4 月 7 號，算下來有將近兩周的時間。
GitHub 指出，攻擊者的目的是逼迫 Github 移除反審查項目 Greatfire。
GitHub 官方博客發(fā)文指出，攻擊者的目的是逼迫 Github 刪除某些特定內(nèi)容的頁面。根據(jù)第三方的研究稱，此次攻擊采用了 HTTP 劫持，加密連接不受影響。攻擊者的設(shè)備設(shè)在國際互聯(lián)網(wǎng)和國內(nèi)互聯(lián)網(wǎng)的邊界上，用惡意的代碼替代百度的 js 文件，載入惡意代碼后用戶的瀏覽器將會以每 2 秒一次的頻率，訪問域名 https://github.com/greatfire/和 https://github.com/cn-nytimes/。
據(jù)悉，攻擊者先后使用了四種 DDoS 技術(shù)攻擊 GitHub：
第一波是創(chuàng)造性的劫持百度 JS 文件利用中國海外用戶的瀏覽器每 2 秒向托管在 GitHub 上的兩個反審查項目發(fā)出請求，這一手段被 GitHub 用彈出 JS 警告 alert ()防住；
第二輪是跨域<img> 攻擊，被 GitHub 檢查 Referer 擋住；
第三波是 DDoS 攻擊 GitHub Pages；
第四波是正在進(jìn)行中的 TCP SYN 洪水攻擊，利用 TCP 協(xié)議缺陷發(fā)送大量偽造的 TCP 連接請求，讓 GitHub 耗盡資源
最后，Github 的反制措施是用 alert (“WARNING: malicious javascript detected on this domain”)替換了原網(wǎng)頁的內(nèi)容。
