[转]剥开层层迷雾，深度追踪针对GitHub的DDoS攻击

就在几周前，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 的中间人设备在中国。当然，这并不说明此次攻击就是中国发起的——还有其他的可能，比如黑客攻击或控制了这些网络设备。

打赏

微信扫一扫，打赏作者吧～