就在幾周前，GitHub 網站遭受了有史以來最嚴重的DDoS攻擊。本文中將使用http-traceroute來深入分析此次攻擊的來源。

攻擊真的來自中國嗎?

GitHub是全球最大的社交編程及代碼托管網站，上面托管了大量的開源項目，比如就有著名開源操作系統Linux。

瑞典網絡安全公司Netresec認為：

這次DDoS攻擊是通過一些中間人劫持設備并劫持了世界上其他地方向中國發起的訪問流量，攻擊者替換了其中的javascript代碼，間接對GitHub發起攻擊。

由于此次攻擊似乎來自任何地方，這讓GitHub難以抵擋。

用TTL值追蹤中間人攻擊

Netresec 通過查看數據包中的 TTL 值可以斷定這是一起中間人攻擊事件。

科普：什么是TTL?

TTL，或者 time-to-live，所有網絡中的數據包中都用這個字段來表示數據包經過了幾跳。每一次路由器將一個數據包發出去的時候，就會將這個字段減一。當這個字段為零的時候，數據包將會被丟棄。以防止路由器無限制發送數據包造成死循環。

很多操作系統發送數據包的時候默認 TTL 值是64，因此，當一個數據包到達的時候，如果 TTL 值為46，我們便會知道這個數據包在你的機器和發送數據包的機器之間經過了18個節點(64-18=46)。

netresec 所發現的結果正如下圖中所示，下圖顯示了客戶端和服務器之間的一些數據包，我機器發送給百度服務器的數據包 TTL 起始值是64，第一個響應包的 TTL 值是46，因為百度發送的數據包起始值為64，期間經過18次路由跳轉才到達我的電腦。當我發起 web 請求之后，我收到的數據包中的 TTL 值很奇怪，TTL 值分別是98和99。這表明數據包明顯不是來自最初的服務器，而是一些中間設備。

我知道在我和百度之間肯定有中間人設備，但是它在哪里?為了回答這個問題，我們使用 traceroute。

Traceroute工具幫了大忙

Traceroute 是一個很棒的工具。它可以發送TTL 為任意值的數據包，比如1，2，3.。。等等。因為有如此低的 TTL，這些數據包無法到達目標機器，當這些數據包的 TTL 值為0的時候，路由器就會丟掉這個包，并且路由器會返回一個用于通知的數據包，叫做Time-Exceeded message，地址是路由器的地址。因此，我可以收集到我喝目標服務器之間的所有路由器。

下圖顯示了這個工具的用法，是我電腦traceroute 到百度服務器的結果：

第二列是時間，如你所見，從我機器到Los Angeles用了大概80毫秒，然后，延遲飆到230毫秒才到達中國，另外，我發送的數據包沒有到達目標服務器，第16跳得時候遇到了防火墻。

那么中間人劫持的設備到底在哪里?為了回答這個問題，我需要寫代碼，我自己寫了一個小的 traceroute 工具，它并不是只發送一個數據包，而是首先建立一個有正常TTL 值的鏈接，所以，無論如何數據包都可以到達目標機器，然后，使用發起一個 http 請求，攜帶的包得 TTL 值是比較小的，所以這個數據包在到達目標前就會被丟棄掉，但是，當中間人劫持設備受到這個數據包的時候，會更新 TTL 的值，這樣，我就可以發現中間人設備在什么地方了。

我發現中間人設備潛伏在11和12跳之間。web請求中 TTL 值為11的時候數據包沒有響應，而 TTL 值為12的時候，返回了正常響應，如下圖所示：

上面黑色被背景的就是我發送的數據包，TTL 值為12，橘黃色的數據包(及它上面的兩個數據包)是從中間人設備傳回的數據包，當我將數據包的 TTL 值置為11的時候，不會從中間人設備獲得響應包。

從traceroute的 IP 地址可以看到，中間人設備放置在中國聯通的骨干網絡中。

下一步就是從其他方面 traceroute，從中國到一個被封鎖的地址。用http://www.linkwan.net/tr.htm,這個網站，獲得了如下數據：

結論

通過http-traceroute，Netresec判定攻擊 GitHub 的中間人設備在中國。當然，這并不說明此次攻擊就是中國發起的——還有其他的可能，比如黑客攻擊或控制了這些網絡設備。