tracert-traceroute原理

一、路由追蹤程序traceroute/tracert

Traceroute是Linux和Mac OS等系統默認提供的路由追蹤小程序，Tracert是Windows系統默認提供的路由追蹤小程序。二者的功能相同，都能探測數據包從源地址到目的地址經過的路由器的IP地址。Traceroute/Tracert的實現都借助了TTL：通過向目的地址發送一系列的探測包，設置探測包的TTL初始值分別為1,2,3…，根據返回的超時通知（ICMP Time Exceeded Message）得到源地址與目的地址之間的每一跳路由信息。雖然兩者輸出結果一致，但在實現原理上還有著顯著的差別。

二、Traceroute實現原理

1. 從源地址發出一個UDP探測包到目的地址，并將TTL設置為1；

2. 到達路由器時，將TTL減1；

3. 當TTL變為0時，包被丟棄，路由器向源地址發回一個ICMP超時通知（ICMP Time Exceeded Message），內含發送IP包的源地址，IP包的所有內容及路由器的IP地址；

4. 當源地址收到該ICMP包時，顯示這一跳路由信息；

5. 重復1～5，并每次設置TTL加1；

6. 直至目標地址收到探測數據包，并返回端口不可達通知（ICMP Port Unreachable）；

7. 當源地址收到ICMP Port Unreachable包時停止traceroute。

注：

1. Linux和Mac OS等系統使用UDP包進行探測，目標端口號默認為33434，每次探測目標端口號加1。Traceroute故意使用了一個大于 30000 的目標端口號，以保證目標地址收到數據包后能夠返回一個“端口不可達”的 ICMP 報文，于是源地址就可將端口不可達報文當作跟蹤結束的標志。

2.Traceroute每跳默認發送3個探測包（發包的數量可通過-q進行設置），探測包的返回會受到網絡情況的影響。如果防火墻封掉了ICMP的返回信息，那么相應的延時位置會以*顯示。如果某臺網關阻塞或者某臺DNS出現問題，那么相應行的延時會變長?？梢约?n 參數來避免DNS解析，以IP格式輸出數據。

3.每個探測包都有唯一的標識號，使得Traceroute能夠識別返回的包。UDP數據包使用遞增的目標端口號進行標識。

三、Tracert實現原理

1. 從源地址發出一個ICMP請求回顯（ICMP Echo Request）數據包到目的地址，并將TTL設置為1；

2. 到達路由器時，將TTL減1；

3. 當TTL變為0時，包被丟棄，路由器向源地址發回一個ICMP超時通知（ICMP Time Exceeded Message），內含發送IP包的源地址，IP包的所有內容及路由器的IP地址；

4. 當源地址收到該ICMP包時，顯示這一跳路由信息；

5. 重復1～5，并每次設置TTL加1；

6. 直至目標地址收到探測數據包，并返回ICMP回應答復（ICMPEcho Reply）；

7. 當源地址收到ICMP Echo Reply包時停止tracert。

注：

1.Windows系統使用ICMP請求回顯（ICMP Echo Request）數據包進行探測，源地址以目的地址返回的ICMP回應答復（ICMP Echo Reply）作為跟蹤結束標志。

2.Traceroute每跳默認發送3個探測包。在未能到達路由器或未返回ICMP超時通知的情況下，相應的延時位置會以*顯示。

3.每個探測包都有唯一的標識號，ICMP數據包使用seq進行標識。

四、Wireshark抓包解析

本次實驗通過追蹤本機到達www.baidu.com所經過的路由信息，并使用Wireshark抓取數據包進行簡要分析來驗證traceroute和tracert的實現原理。

1.Linux/ Mac OS——traceroute

（1）Mac OS
traceroute www.baidu.com。

如圖，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；數據包遇到路由器之后，被丟棄，返回Time tolive exceeded超時通知，解析出路由器IP地址10.203.4.225。源地址再發數據包，設置TTL=2，從而解析出第二跳路由10.2.30.1。同理，解析出第三跳路由10.2.1.1。與終端顯示的信息相符。

從圖中還可以看出，數據包目標端口號從33435開始并且每次加1，traceroute能夠通過UDP數據包遞增的目標端口號來唯一識別返回的包。

如圖，第11跳的61.51.113.202路由只返回了一個ICMP超時通知，與終端顯示的信息相符。
如圖，TTL=34時，ICMP數據包中Type=3(Destination unreachable)，Code=3(Port unreachable)，說明目的地址向源地址發送了端口不可達通知（ICMP Port Unreachable），表示數據包到達目的地址。

（2）Linux

traceroute www.baidu.com。

這里寫圖片描述

Linux系統下的抓包解析與Mac OS類似。

1. Windows——tracert

tracert www.baidu.com。

如圖，第一跳為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請求回顯（ICMP Echo Request）數據包，每跳默認發送3個，TTL設置為1；數據包遇到路由器之后，被丟棄，返回Time tolive exceeded超時通知，解析出路由器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跳只有兩個延時結果，與終端顯示的信息相符。

五、The Great Cannon案例

2015年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追蹤攻擊主機的位置，也為我們提供了新的思路。

參考資料

[1] http://www.cnblogs.com/peida/archive/2013/03/07/2947326.html

[2] http://www.dearda.com/index.php/archives/1361

[3] https://translate.google.com/translatehl=zh-CN&sl=en&u=https://technet.microsoft.com/en-us/library/cc940128.aspx&prev=search

[4] http://www.freebuf.com/news/topnews/63148.html

[5]https://blog.gesha.net/archives/499/

轉自FreeBuf.COM
http://www.freebuf.com/articles/network/118221.html