路由跟踪tracert分析统信uos系统路由跟踪


Traceroute是Linux和MacOS等系统默认提供的路由追踪小程序,Tracert是Windows系统默认提供的路由追踪小程序。二者的功能相同,都能探测数据包从源地址到目的地址经过的路由器的IP地址。Traceroute/Tracert的实现都借助了TTL:通过向目的地址发送一系列的探测包,设置探测包的TTL初始值分别为1,2,3…,根据返回的超时通知(ICMPTimeExceededMessage)得到源地址与目的地址之间的每一跳路由信息。虽然两者输出结果一致,但在实现原理上还有着显著的差别。



3.当TTL变为0时,包被丢弃,路由器向源地址发回一个ICMP超时通知(ICMPTimeExceededMessage),内含发送IP包的源地址,IP包的所有内容及路由器的IP地址;



6.直至目标地址收到探测数据包,并返回端口不可达通知(ICMPPortUnreachable);



1.Linux和MacOS等系统使用UDP包进行探测,目标端口号默认为,每次探测目标端口号加
1。Traceroute故意使用了一个大于的目标端口号,以保证目标地址收到数据包后能够返回一个“端口不可达”的ICMP报文,于是源地址就可将端口不可达报文当作跟踪结束的标志。



2.Traceroute每跳默认发送3个探测包(发包的数量可通过-q进行设置),探测包的返回会受到网络情况的影响。如果防火墙封掉了ICMP的返回信息,那么相应的延时位置会以*显示。如果某台网关阻塞或者某台DNS出现问题,那么相应行的延时会变长。可以加-n参数来避免DNS解析,以IP格式输出数据。



3.每个探测包都有唯一的标识号,使得Traceroute能够识别返回的包。UDP数据包使用递增的目标端口号进行标识。



1.从源地址发出一个ICMP请求回显(ICMPEchoRequest)数据包到目的地址,并将TTL设置为1;



1.Windows系统使用ICMP请求回显(ICMPEchoRequest)数据包进行探测,源地址以目的地址返回的ICMP回应答复(ICMPEchoReply)作为跟踪结束标志。



2.Traceroute每跳默认发送3个探测包。在未能到达路由器或未返回ICMP超时通知的情况下,相应的延时位置会以*显示。

本次实验通过追踪本机到达所经过的路由信息,并使用Wireshark抓取数据包进行简要分析来验证traceroute和tracert的实现原理。

如图,Traceroute能够显示到达目的地址所需的跳数、经过的路由器的IP地址、延时、丢包情况等信息。第一跳为10.203.4.225,第二跳为10.2.30.1,第三跳为10.2.1.1;每条记录输出3个延时结果,说明源地址每次默认发送三个数据包;在11条记录只有1个延时结果,说明源地址只收到了1个ICMP超时通知消息。

如图,源地址10.203.4.244向目的地址119.75.218.70发送UDP数据包,每跳默认发送3个,TTL设置为1;数据包遇到路由器之后,被丢弃,返回Timetoliveexceeded超时通知,解析出路由器IP地址10.203.4.225。源地址再发数据包,设置TTL=

2,从而解析出第二跳路由10.2.30.1。同理,解析出第三跳路由10.2.1.1。与终端显示的信息相符。

从图中还可以看出,数据包目标端口号从开始并且每次加1,traceroute能够通过UDP数据包递增的目标端口号来唯一识别返回的包。

如图,第11跳的61.51.113.202路由只返回了一个ICMP超时通知,与终端显示的信息相符。

如图,TTL=34时,ICMP数据包中Type=3(Destinationunreachable),Code=3(Portunreachable),说明目的地址向源地址发送了端口不可达通知(ICMPPortUnreachable),表示数据包到达目的地址。

如图,第一跳为10.8.160.1,第二跳为10.0.14.1,第三跳为10.0.4.41;每条记录输出3个延时结果,说明源地址每次默认发送三个数据包;在第6条记录只有2个延时结果,说明源地址只收到了2个ICMP超时通知消息;数据包从源地址经过15跳之后到达目的地址。

如图,源地址10.8.169.32向目的地址220.181.111.188发送ICMP请求回显(ICMPEchoRequest)数据包,每跳默认发送3个,TTL设置为1;数据包遇到路由器之后,被丢弃,返回Timetoliveexceeded超时通知,解析出路由器IP地址10.8.160.1。源地址再发数据包,设置TTL=

2,从而解析出第二跳路由10.0.14.1和10.0.14.5。同理,解析出第三跳路由10.0.4.41。与终端显示的信息相符。

从图中还可以看出,数据包从seq=142开始每次加1,tracert能够通过seq来唯一识别返回的包。

如图,seq=157的数据包没有得到路由器172.16.7.1的超时通知消息,因此第6跳只有两个延时结果,与终端显示的信息相符。

如图,TTL=15时,源地址收到了目的地址的ICMP回应答复(ICMPEchoReply),说明源地址经过了15跳到达目的地址,与终端显示信息相符。

年3月26日开始,因某些众所周知的原因,GitHub遭到其网站历史上最大规模DDoS攻击。瑞典网络安全公司Netresec通过查看数据包中的TTL值断定这是一起中间人攻击事件。在此过程中,他们借助了路由追踪程序traceroute/tracert的实现原理。首先建立一个正常的连接,确保数据包能够到达目标机器。然后依次发送TTL值为1,2,3…的HTTP请求。若数据包没有到达中间人设备,则不会出现HTTP响应;若数据包到达中间人设备,则会出现HTTP响应,然后只需在出现HTTP响应时,查看请求数据包设置初始TTL值即可。

安全人员根据下图发现中间人设备潜伏在11和12跳之间。Web请求中TTL值为11的时候数据包没有响应,而TTL值为12的时候,返回了正常响应。

Traceroute/tracert路由追踪程序是用来追踪数据包到达网络主机所经过的路由信息的重要工具,虽然路由追踪效果一致,但实现原理略有不同:前者借助UDP协议,后者借助ICMP协议。此外,利用TTL追踪攻击主机的位置,也为我们提供了新的思路。