TraceRoute

Traceroute is often used for network troubleshooting. By showing a list of routers traversed, it allows the user to identify the path taken to reach a particular destination on the network. This can help identify routing problems that may block or slow access to a web site.In the early days of the Internet such detailed information about the path a packet took was considered acceptable and convenient. However, hackers have exploited this helpful tool in order to acquire sensitive information about a company’s network architecture. By using the traceroute command, a hacker or several hackers can quickly map a company’s network architecture and use that information to launch attacks.

In general traceroute and ping have the lowest priority of all packets. E-mail, web browsing, ftp, etc. data take precedence over traceroute data.

For example if a router is passing secure web data to a customer and another customer starts to ping that router. The router will put a ‘hold’ on the ping packets until it is ready. Because of situations like this, most traceroute programs send 3 different requests. Since one of the requests may be put on ‘hold’ due to higher priority data being sent, the program tests the path 3 times.

Over the past several years network devices have been electronically attacked via the use of ICMP. These attacks have proved to be very effective in the past, and in some situations they still are. Network device (routers, switches, etc) vendors have taken steps to lessen the impact of these attacks destined to their devices. They have done this by limiting the number of ping and traceroute messages received/processed per unit of time. In any given service providing network, multiple devices send/receive ping and traceroute messages on a perpetual basis. Add to this, the number of user/gamer/student/entrepreneurs who continuously run traceroute programs like ping plotter, and the ping and traceroute limits to the devices will be reached very quickly.

How to read traceroute data:

 

Let us do a traceroute to a site we know responds to ICMP packets.

Tracing route to cnn.com [64.236.16.20] over a maximum of 30 hops:

 

1 57 ms 28 ms 50 ms ip68-100-1-97.dc.dc.cox.net

2 341 ms 74 ms 156 ms ip68-100-0-1.dc.dc.cox.net [68.100.0.1]

3 28 ms 207 ms 52 ms mrfddsrj01gex070004.rd.dc.cox.net

4 * ms 274 ms 235 ms mrfdbbrj01-ge020.rd.dc.cox.net

5 73 ms 12 ms 84 ms mrfdbbrj02-ge030.rd.dc.cox.net

6 107 ms 38 ms 47 ms ashbbrj02-so000.r2.as.cox.net

7 35 ms 39 ms 54 ms ashbbbrj01-ae0.0.r2.as.cox.net

8 100 ms 38 ms 51 ms pop1-ash-S0-3-2.atdn.net

9 65 ms 40 ms 20 ms bb1-ash-P0-0.atdn.net [66.185.144.192]

10 40 ms 37 ms 51 ms bb2-vie-P11-0.atdn.net [66.185.152.101]

11 36 ms 35 ms 64 ms bb2-atm-P3-0.atdn.net [66.185.152.33]

12 51 ms 70 ms 45 ms bb2 [66.185.152.3]

 

Looking at this traceroute, one can see that roundtrip times to the site are very good (12 51 ms 70 ms 45

ms bb2 [66.185.152.3]) However looking at #4, one may determine that there is a problem at that device when there is not. When an actual problem occurs with a device that causes latency, that latency is carried on through the other hops.

If the router at #4 was causing latency to the connection at www.cnn.com, one would see increasing times at hop #5, #6, #7 and so on. Since all packets have to traverse the router at #4, any latency created by that device would carry on to the end of the traceroute.

Vendors sometimes limit the amount of ICMP packets that their equipment will respond to. This can produce confusing results. When reading a traceroute, look for latency (high return times) to carry though to the final destination.

 

Here is an example of a traceroute when there is a problem inside a network:

 

1 31 ms 27 ms 28 ms core1-loopback-0.Brisbane.netspace.net.au [203.17.101.6]

2 33 ms 30 ms 28 ms AS7496.brisbane.pipenetworks.com [218.100.0.20]

3 228 ms 329 ms 228 ms fa1-0-6.xr2.wic.server-web.com [203.147.255.118]

4 215 ms 232 ms 228 ms gi2-0.xr2.bne.server-web.com [203.147.255.237]

5 233 ms 229 ms 233 ms core.mls1.bne.server-web.com [203.147.255.246]

6 232 ms 232 ms 233 ms bne606d.server-web.com [202.139.232.71]

As one can see, between hop #2 and #3, the time jumps from 33 ms to 228 ms and the latency continues through to its final destination at #6.