路由跟踪命令行Tracert更牛X工具X-FireWalk v3.0

阅读本文前，作者已假定你完全了解Tracert的相关实现原理，并对ICMP TTL TIME-EXCEEDED报文返回 的内容和结构以及产生该报文的原因有清晰的认识。如果你还未了解这方面的原理知识，请先Google之。 如果你有足够的耐心，请认真阅读完本文。相信对你肯定有所帮助。 一、基本介绍 X-FireWalk v3.0 *********************************************************** ACL Scanner|Super Tracerter For Windows E-mail : crackersoftware@163.com Code By Xtiger 2005.5 HomePage: http://www.xdoors.net All For Free Live Dream... *********************************************************** [Usage :] x-firewalk.exe <ip|hostname through GetWay> [option] [Options:] -n not Don't Tracert Route before ACL Scan -N not Don't ACL Scan After Tracert Router -t tcp Tracert the Route By TCP. Default By ICMP (2K/2003) -u udp Tracert the Route By UDP. Default By ICMP -i:interface Tracert Over No.x NetWork Interface. Default No.0 Nic -w:wait Tracert Wait timeout milliseconds for each reply. -h:hop Tracert Maximum number of hops to search for target. -l:ttl Set TTL Of ACL Scan. Must Use With "-n". Default TTL=2 -o:port1-port2 ACL Scan between port1 2 port2. Default 0-65535 -p:protocol ACL Scan Protocol (TCP or UDP). Default TCP+UDP x-firewalk是一款基于RAW SOCKET，利用ICMP TTL TIME-EXCEEDED包特性使用ICMP\UDP\TCP 协议进行tracert和端口ACL扫描的综合性网络小工具。可以在WIN2K/XP/2003 OS平台上运行。 由于XP SP2对系统的RAW SOCKET进行了修改和限制，将无法使用其中tracert功能中的TCP部分。 二、使用介绍 1.Tracert部分 1.1 我们在使用系统自带的tracert.exe的时候，经常发现，很多的站点无法Tracert,如下所示(拷贝CMD的输出)： (当然跟各自所在的网络也有关系,同样是电信的网络,限制的情况也是不同的) Microsoft Windows 2000 [Version 5.00.2195] (C) 版权所有 1985-2000 Microsoft Corp. c:\winnt\system32>tracert www.163.net Tracing route to www.163.net [202.108.252.146] over a maximum of 30 hops: 1 * * * Request timed out. 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. 5 * * * Request timed out. 6 * * * Request timed out. 7 * * * Request timed out. 8 * * * Request timed out. 9 * * * Request timed out. 10 * * * Request timed out. 11 * * * Request timed out. 12 * * * Request timed out. 13 * ..... 这里的原因是因为现在Internet上很多的路由节点出于某些原因，过滤了ICMP type=8 code=0(也就是PING的请求包)。 使得系统自带的基于这个这个协议工作的tracert.exe无法正常工作，而一路返回"request time out". 1.2 所以，如果我们想继续tracert,必须弃用ICMP协议作为探测协议，而改用其他协议。以下是x-firewalk 改用UDP协议后对www.163.net的tracert输出结果: Microsoft Windows 2000 [Version 5.00.2195] (C) 版权所有 1985-2000 Microsoft Corp. e:\myprogram\vc\firewalk\Release>x-firewalk.exe www.163.net -u -N Tracing route to www.163.net [202.108.252.146] by UDP over No.0 netWork interface with ip [10.11.11.177] over a maximum of 32 hops, timeout in 3000 milliseconds: 1 * * * Request Timed Out 2 <10 ms <10 ms <10 ms 61.154.14.254 [福建省福州市 电信] 3 <10 ms <10 ms <10 ms 202.109.204.181 [福建省福州市 CZ88.NET] 4 <10 ms * 16 ms 202.109.204.6 [福建省福州市 CZ88.NET] 5 31 ms 15 ms 32 ms 202.97.41.209 [中国电信 骨干网] 6 15 ms 47 ms 31 ms 202.97.35.25 [ CZ88.NET ] 7 32 ms 31 ms 31 ms 202.97.46.38 [中国电信 骨干网] 8 156 ms 157 ms 156 ms 219.158.32.1 [北京市 网通] 9 250 ms 250 ms 250 ms 219.158.13.9 [北京市 网通] 10 266 ms 250 ms 250 ms 202.96.12.162 [北京市 CHINANET-BJ] 11 265 ms 250 ms 250 ms 202.106.193.150 [北京市 路由器] 12 250 ms * 250 ms 202.106.193.114 [北京市 路由器] 13 266 ms 250 ms 250 ms 61.148.3.30 [北京市 网通] 14 * 250 ms 250 ms 202.106.48.129 [北京市 网通] 15 250 ms * 250 ms 202.106.48.6 [北京市 网通] 16 265 ms 250 ms * 202.108.252.146 [北京市 网通] 17 250 ms 250 ms 266 ms 202.108.252.146 [北京市 网通] Trace complete. 这样，通过改用UDP协议作为探测协议，我们成功地Tracert出了到www.163.net的路由情况。 1.3 但是，我们还有可能遭遇即使使用UDP协议，也无法完成Tracert的情况，如下所示: Microsoft Windows 2000 [Version 5.00.2195] (C) 版权所有 1985-2000 Microsoft Corp. e:\myprogram\vc\firewalk\Release>x-firewalk.exe www.163.com -u Tracing route to www.163.com [202.108.9.16] by UDP over No.0 netWork interface with ip [10.11.11.177] over a maximum of 32 hops, timeout in 3000 milliseconds: 1 * * * Request Timed Out 2 <10 ms <10 ms <10 ms 61.154.14.254 [福建省福州市 电信] 3 <10 ms <10 ms <10 ms 202.109.204.181 [福建省福州市 CZ88.NET] 4 <10 ms * * 202.109.204.6 [福建省福州市 CZ88.NET] 5 16 ms 47 ms 31 ms 202.97.41.209 [中国电信 骨干网] 6 31 ms 16 ms 31 ms 202.97.35.25 [ CZ88.NET ] 7 31 ms 31 ms 32 ms 202.97.46.58 [中国电信 骨干网] 8 172 ms 171 ms 157 ms 219.158.32.93 [北京市 网通] 9 265 ms 266 ms 250 ms 219.158.13.9 [北京市 网通] 10 266 ms 250 ms 250 ms 202.96.12.154 [北京市 CHINANET-BJ] 11 250 ms 250 ms 250 ms 202.106.193.38 [北京市 路由器] 12 * 234 ms 250 ms 202.106.193.166 [北京市 路由器] 13 266 ms 250 ms 250 ms 61.148.3.234 [北京市 网通] 14 * * * Request Timed Out 15 * * * Request Timed Out 16 * * * Request Timed Out 17 * * * Request Timed Out 18 * * * Request Timed Out 19 * * ..... 这里的原因有两种，第一种，从第14跳路由开始，设备过滤了UDP协议，或只允许某些特定的UDP包通过， 使得Tracert失败。第二种，即使最后的UDP包达到了目标主机，但是产生的ICMP TYPE=3 CODE=3的端口不可到达 ICMP报文在返回时，被路上的某个设备过滤。所以和使用ICMP作为探测协议一样，UDP一样存在由于被过滤某些 特定报文而无法tracert的情况。 1.4 所以，我们还有第三种选择，使用TCP作为探测协议。而使用这种协议作为探测协议，很明显，可以有效地克服 上面使用UDP协议时候所可能遭遇的情况。(第一，因为目标肯定是个WEB服务器，各个节点几乎不可能过滤目标 端口为80的TCP包。第二，最终到达目标主机的TCP包返回的也是TCP包而不是ICMP包，被过滤的可能性几乎为0)。 如下所示： Microsoft Windows 2000 [Version 5.00.2195] (C) 版权所有 1985-2000 Microsoft Corp. e:\myprogram\vc\firewalk\Release>x-firewalk.exe www.163.com -t -N Tracing route to www.163.com [202.108.9.16] by TCP over No.0 netWork interface with ip [10.11.11.177] over a maximum of 32 hops, timeout in 3000 milliseconds: 1 * * * Request Timed Out 2 <10 ms <10 ms <10 ms 61.154.14.254 [福建省福州市 电信] 3 16 ms <10 ms <10 ms 202.109.204.181 [福建省福州市 CZ88.NET] 4 <10 ms * <10 ms 202.109.204.6 [福建省福州市 CZ88.NET] 5 32 ms 15 ms 16 ms 202.97.41.209 [中国电信 骨干网] 6 16 ms 31 ms 32 ms 202.97.35.25 [ CZ88.NET ] 7 31 ms 31 ms 31 ms 202.97.46.58 [中国电信 骨干网] 8 157 ms 140 ms 156 ms 219.158.32.93 [北京市 网通] 9 250 ms 266 ms * 219.158.13.9 [北京市 网通] 10 266 ms 250 ms 250 ms 202.96.12.154 [北京市 CHINANET-BJ] 11 250 ms 250 ms 250 ms 202.106.193.38 [北京市 路由器] 12 * 25