Tracing the Traceroute: A White Paper by Ankit Fadia email@example.com
Date of Release: 24th January 2002
Traceroute is definitely a very exciting tool or utility. It should indeed be a part of every hacker’s toolkit as it can be used to gain some very important information regarding the target system’s configuration and its network configuration. In this white paper, we will not only understand the workings and intricacies of this kewl utility, but we will also explore all its possible uses and resourcefulness.
Traceroute was originally developed with the intention of providing a debugging tool, which could be used to pinpoint the exact system or computer on a network (Internet or a Local Network), which was causing the problem experienced. Whenever there was a problem in the data transit or whenever there was a network problem, then the traceroute tool provided the network administrator with an option, which could be used to pinpoint the exact system in the network that was the root of the problem. In other words, the traceroute tool could be used to trace the path of the entire network or a part of the entire network and in this process pinpoint the exact system that was causing the problem experienced.
However, the bottom line remained that the traceroute tool could indeed be used to trace the path taken by a packet from the source system to the destination system, over the Internet.
Whenever a particular chunk of data is to sent from the source system to the destination system, then the data packets sent are first routed through a number of routers (on way to the destination system and if there are any routers in between.) and only then do the data packets arrive at the destination system. The typical path taken by data packets sent by the source to the destination has been depicted by the below figure:
Source System---------à Router of the Source Network----------à Router of the Source Network’s ISP-------à Router of the Destination’s ISP-------à Router of the Destination Network-----à Destination System.
Whenever data travels over the Internet, then it is not necessary that the data packets in question, would automatically take the shortest path possible from the source to the destination system. More often than not, data packets sent across a network end up taking a much longer route than what the shortest route is. This means that most of the times data packets sent across a network end up taking more time for the data transit to be completed, than what it should actually be taking. This brings us to a widely known feature of the Internet:
“It is not necessary for all data packets sent from the same source system to the same destination system across a network, to take the same exact route every single time.”
Thus the traceroute tool can be used in order to trace the route taken by data packets from the source system to the destination system. Traceroute displays all the routers through which data packets pass on way to the destination system from the source system. Thus, in effect, we come to know the exact path taken by the data packets in the data transit.
“Traceroute can be used to depict the exact path taken by data packets from the source system to the destination system. However, the path displayed by Traceroute for two data packets sent from the same source system to the same destination system in two different sessions may or may not vary.”
The below example exhibits a simple traceroute to a remote host, displaying all the routers on way to the destination system:
Tracing route to 202.*.2.241over a maximum of 30 hops:
1 146 ms 138 ms 126 ms 188.8.131.52
2 146 ms 137 ms 127 ms 184.108.40.206
3 126 ms 133 ms 129 ms 220.127.116.11
4 130 ms 122 ms 128 ms 18.104.22.168
5 134 ms 139 ms 132 ms 22.214.171.124
6 140 ms 125 ms 128 ms 126.96.36.199
7 220 ms 146 ms 137 ms delhi-stm1.Bbone.vsnl.net.in [202.*.2.241]
The Internet Control Message Protocol or the ICMP protocol is that protocol of the TCP/IP suite, which handles or is used for diagnosing networking problems and reporting error messages. Whenever an error occurs during the data transit then the ICMP protocol jumps in and does the job of reporting and displaying the error that occurred. Thus, the main function of the ICMP protocol is to communicate the error messages to the host and the client systems.
“The ICMP Protocol reports and displays all errors that took place in the data transfer.”
The Traceroute tool can be considered to be a part of the ICMP protocol as it makes use of mainly this protocol. The reason why traceroute is able to display the path between the source and destination system is by making use of the ICMP protocol and the error messages that it displays.
The format of a typical ICMP error message, is as follows:
| | | |
| 8-Bit Type | 8-bit Code | Checksum Value |
| | | |
|_____________ |____________________ |______________________________|
| (Contents depending upon Error that occurred.) |
The ‘Type’ and ‘Code’ fields are the fields, which stand for the type of error message that has occurred. These fields contain a particular value, which tells the client and the host systems as to what error has occurred.
The two error messages that Traceroute mainly makes use of are as follows:
“If a system receives a data packet whose TTL field has a value of 0 or 1, then it sends the Time Exceeded error message to the client, who sent the data packet to it.”
“If a client tries to establish a connection with the host on a closed port, then the host replies with a Port Unreachable error message, sent to the client.”
It is with the use of these two ICMP error messages that the Traceroute tool is able to display or trace the exact path from the source system to the destination system. Before we move onto the exact explanation of the working of the traceroute tool, let us learn as to what TTL or Time to Live is?
The Time To Live or the TTL value of a data packet is an 8-bit field, which determines the maximum number of routers through which that particular data packet can pass through. In other words, the TTL value decides the maximum number of routers through which the data packet can pass, before it must be discarded. The TTL value is to a data packet, what the value of maximum age is to a human. The TTL value depicts the maximum number of routers through which it can pass, before it is declared ‘dead’ and is dropped.
The TTL value of a packet is set by the source system each time a new data packet is sent by it. The value of the TTL field set by the source system varies from system to system depending upon the operating system running on it. Each router receiving a data packet is expected to decrement the TTL value of that particular packet by 1. This means that if the initial TTL value set by the source system is 64 and if this particular packet passes through 2 routers, then its final TTL value will become 62.
Each time a router receives a data packet, it checks to see what the TTL value of that particular packet is. According to the TTL value of the received packet, the following two cases can take place:
1. If the TTL value of the received packet is greater than 1, then the router decrements this TTL value by 1 and forwards the data packet to the next router.
2. If the TTL value of the received packet is either 0 or 1, then the router discards the data packets and sends back a “Time Exceeded” ICMP error message to the source system, which originally had sent the data packet.
“If the TTL value of the received data packet is greater than 1, then the router decrements the TTL value by 1 and forwards the data packet to the next router. However, if the TTL value of the received data packet is either 0 or 1, then the router discards the packet and sends back a Time Exceeded ICMP error message to the source system.”
The original reason behind the introduction of the TTL value was to ensure that the data packets sent across networks, do not end up in infinite loops, which may occur due to unfinished transactions or when the client or server shuts disconnects from the network without following the proper steps required to close all the open connections. However, today the same concept of TTL values is being widely used in the form of the Traceroute command in order to trace paths between source and destination systems on the Internet.
The first step in the traceroute command is that it creates a packet with a TTL value of 1 and sends it to the destination system (to which the path is to be traced). The first router on way to the destination system from the source system (on which the command was executed) will discard the data packet, as the TTL value of this received data packer is 1. In addition, this first router will also send back a “Time Exceeded” error message to the source system. Since this Time Exceeded error message received by the source system, has its source IP Address as that of the first router, as a result the traceroute tool (running on the source system) will come to know this IP Address of the first router. In this way, the traceroute command comes to know the Address of the first router on the path to the destination system and displays it on the screen.
Similarly, in the next step, traceroute sends a data packet with a TTL value of 2 to the destination system. The first router receiving this data packet will decrement the TTL value of the packet by 1 to 1 and then it would forward the packet to the second router on path to the destination system. This second router would in turn, discard this packet and send back a “Time Exceeded” error message to the source system. Hence, revealing its IP Address. Please note that the second router discards this packet, as the TTL value of this packet is 1.
This process of sending packets with increasing TTL values is carried out, until the data packet has a TTL value high enough to make sure that it reaches the destination system.
Following the above method, Traceroute is able to trace the entire path from the source system to the destination system and also in the process gather the hostnames and IP Addresses of all routers on the path. Until now traceroute has made use of only the first (Time Exceeded) of the two ICMP error messages that we discussed earlier.
When the TTL value is high enough for the data packet to reach the destination system, then by the time the destination system receives the data packet, its TTL value would have been decremented to 1. However, even though the destination system will receive a data packet having a TTL value of 1, it will not discard the packet. This is because the destination (i.e. the system to which the path was to be traced) has been reached. Since the destination system does not discard the data packet that it receives, it means that the destination system does not generate a Time Exceeded error message. As a result, since no “Time Exceeded” error message is generated, the source system does not have any way by which it can ensure that the destination system has been reached.
Thus, in order to deduce that the destination system has indeed been reached, the traceroute command makes use of the “Port Unreachable” error message.
We have already seen in the previous sections that the host generates the “Port Unreachable” error message, when a client is trying to establish a connection with it on a closed port. Traceroute sends UDP (User Datagram Protocol) packets to the destination system on extremely high ports. These high port numbers are chosen in such a manner, that the traceroute tool is sure that there is no service running on these high ports. In effect, the traceroute tool is actually trying to establish a connection on a closed port. Since the destination system receives UDP packets addressed to high “closed” ports, it thus replies with the “Port Unreachable” ICMP error message.
The source system thus can identify that the destination system has been reached, as it would receive a “Port Unreachable” error message from it.
“In the Traceroute tool, if the source system receives a Time Exceeded error message, then a router must have generated it. However, if the source system receives a Port Unreachable error message, then the destination system must have generated it”
The actual working of the traceroute command can be summarized in the following steps:
1. The Traceroute tool sends UDP packets to the destination system on a high port number chosen such that there is no service running on it. Since the chosen port to which the UDP packet have been sent is closed, as a result the destination system replies with a “Port Unreachable” ICMP error message. In this manner, the source system gets to know the Destination system’s identity.
2. Traceroute then performs the process of sending data packets with increasing TTL values to the destination system, starting with the initial TTL value of 0. This process reveals the identity of all the routers on the path from the source to the destination system.
3. Traceroute just has to differentiate between the two ICMP error messages that it engineered and received and it will be able to trace the path from the source system to the destination system. The fact that the routers generate a different error message as compared to the destination system is used to differentiate between the two.
“Each router that handles an IP datagram is required to decrement the datagram’s TTL value by one or by the number of seconds it holds it. As almost all routers do not hold a datagram longer that 1 second, the TTL value has thus essentially become a hop counter, giving the number of routers through which the datagram has passed.”
The following is an example of the typical results displayed by a traceroute command executed on a Windows system:
Tracing route to yahoo.com [188.8.131.52] over a maximum of 30 hops:
1 308 ms 142 ms 127 ms 184.108.40.206
2 140 ms 135 ms * 220.127.116.11
3 213 ms 134 ms 132 ms 18.104.22.168
4 134 ms 130 ms 129 ms 22.214.171.124
5 122 ms 135 ms 131 ms 126.96.36.199
6 141 ms 137 ms 121 ms 188.8.131.52
7 143 ms 170 ms 154 ms vsb-delhi-stm1.Bbone.vsnl.net.in [184.108.40.206]
8 565 ms 589 ms 568 ms if-7-0.bb8.NewYork.Teleglobe.net [220.127.116.11]
9 596 ms 584 ms 600 ms if-3-0.core2.NewYork.teleglobe.net [18.104.22.168]
10 * * * Request timed out.
11 703 ms 701 ms 719 ms if-3-0.core2.PaloAlto.Teleglobe.net [22.214.171.124]
12 694 ms 683 ms 681 ms if-6-1.core1.PaloAlto.Teleglobe.net [126.96.36.199]
13 656 ms 677 ms 700 ms ix-5-0.core1.PaloAlto.Teleglobe.net [188.8.131.52]
14 667 ms 673 ms 673 ms ge-1-3-0.msr1.pao.yahoo.com [184.108.40.206]
15 653 ms 673 ms 673 ms vl20.bas1.snv.yahoo.com [220.127.116.11]
16 666 ms 676 ms 674 ms yahoo.com [18.104.22.168]
Besides being used to identify the system causing the problem in the data transit, traceroute is also used for several different purposes:
If one observes the above example closely, then one would find that Traceroute also displays the hostnames of all routers on way to the destination system and also the hostname of the destination system. Hostnames are nothing but the human understandable representations of IP Addresses. They besides containing the address of a system also may or may not store within themselves, some important information on the geographical location of that particular system.
In our example we see that the ninth hostname displayed by traceroute is:
This hostname clearly indicates that that particular router is situated in New York, USA.
Similarly, one should also watch out for hostnames ending in country codes.
xyz.jp would mean that that particular system is situated in Japan.
For a complete Country Code Reference List, kindly visit: http://hackingtruths.box.sk/cc.txt
Thus, we can say that Traceroute in some cases can actually be used to pinpoint the exact location of a system on the globe. In most cases, Traceroute is indeed able to locate the city and country in which a particular system is located. Visual Traceroute is specifically widely used for tracing the geographical location of a system on the Internet.
Using the traceroute command, one can find out the manner in which a particular network is structured, the class to which it belongs and in general, to get related information on topography of a remote network. Getting more information on the network topography of the target network can be used to determine a list of possible weak points, which could be exploited.
Using the traceroute tool, one can also detect the presence of a firewall installed on the target system’s network. If you execute traceroute and find the ‘*’ (asterix) sign as an entry in the output, then it means that the traceroute attempt has timed out. However, if you repeat the same traceroute procedure to the target system several times at different times of the day and still receive the same output with the ‘*’, then it probably means that a firewall has been installed on the target system. The asterix signs are being displayed as the firewall installed on the target system’s network is filtering out your traceroute attempts and as a result, the target system does not reply to your requests and thus a time out is “artificially created” by the firewall.
The above concept can be summarized in the following steps:
1. Your traceroute program sends packets to the target system, however the firewall installed on the target system’s network intercepts these packets, making sure that the target system does not receive them.
2. Since the target system does not receive the Traceroute data packets, as a result it does not reply with the ICMP error message, as it is normally supposed to. Thus, your system does not receive any response.
3. After the passage of some amount of time, if still no response is received, then the connection gets timed out, due to “artificial” conditions created due to the filtering done by the firewall. As a result, asterix are displayed in the output.
A typical output, which shows the presence of a firewall installed on the target system, is as below-:
Tracing route to target.com [207.x.197.100] over a maximum of 30 hops:
1 140 ms 126 ms 128 ms 22.214.171.124
2 137 ms 125 ms 138 ms 126.96.36.199
3 125 ms 136 ms 169 ms 188.8.131.52
4 137 ms 139 ms 130 ms 184.108.40.206
5 138 ms 119 ms 130 ms 220.127.116.11
6 168 ms 157 ms 161 ms vsb-delhi-stm1.Bbone.vsnl.net.in [18.104.22.168]
7 345 ms 377 ms 359 ms if-4-0.bb7.NewYork.Teleglobe.net [22.214.171.124]
8 351 ms * 407 ms if-3-2.core2.NewYork.Teleglobe.net [207.45.220.09]
9 445 ms 450 ms 425 ms if-8-0.core1.Seattle.Teleglobe.net [126.96.36.199]
10 432 ms 436 ms 437 ms if-8-0-0.bb1.Seattle.Teleglobe.net [188.8.131.52]
11 766 ms 740 ms 668 ms iuscmdistc1206-p-7-0.msft.net [184.108.40.206]
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
In the above output, we see that after hop number 11, no results are shown. The same procedure of traceroute is repeated several times, however, still we receive the same result. This probably means that a firewall is installed after router number 11 and it is filtering out all traceroute attempts.
4. Remote OS Detection using Traceroute
Traceroute used along with a packet sniffer can be used to detect the name and version of the operating system running on the target system.
We have already learnt that the TTL value of a data packet is an 8-bit value, set by the system, which originally created and sent that particular data packet. Every operating system has a certain default TTL value associated with it. Every operating system assigns this default TTL value to all outgoing data packets. This in effect means that the initial TTL values of all data packets originating at the same operating system will be same.
This means that if there are two different systems, each running Windows 95, then all packets sent by either of these two systems (running the same operating system) will actually have the same initial TTL value. Hence, different operating systems assign different TTL values to all outgoing packets, while all systems running the same operating system will attach the same TTL value to all outgoing data packets.
“Initial TTL values of all data packets originating at the same OS but different systems will be same. However, TTL values of all data packets originating at the same system (where two OS’s are running) but sent using different Operating systems will have different initial TTL values.”
The below is a complete reference list of operating systems and their respective initial, default TTL values:
OS VERSION PLATFORM TTL
Windows 9x/NT Intel 32
Windows 9x/NT Intel 128
Windows 2000 Intel 128
DigitalUnix 4.0 Alpha 60
Unisys x Mainframe 64
Linux 2.2.x Intel 64
FTX(UNIX) 3.3 STRATUS 64
SCO R5 Compaq 64
Netware 4.11 Intel 128
AIX 4.3.x IBM/RS6000 60
AIX 4.2.x IBM/RS6000 60
Cisco 11.2 7507 60
Cisco 12.0 2514 255
IRIX 6.x SGI 60
FreeBSD 3.x Intel 64
OpenBSD 2.x Intel 64
Solaris 8 Intel/Sparc 64
Solaris 2.x Intel/Sparc 255
Before we move onto the step-by-step guide to OS Detection with the help of TTL values and traceroute, there are certain rules, which one must remember:
a.) All packets sent by a particular operating system will have the same initial TTL value, which will decrement, each time that particular packet passes through a router.
b.) TTL values are stored in the TTL field, which is a part of the IP Header of a data packet. ICMP error messages are nothing but error messages encapsulated within an IP Datagram. These IP datagrams have the TTL field as one of its fields. This means that an ICMP error message too will have an IP Header with it and in effect all ICMP error message too will have a TTL value associated with them.
Thus, one can easily determine the OS running on the remote system by following the below steps-:
a.) Determine the number of hops (routers) between your system and the target system
The first step to perform is to determine the number of hops between your system and the target system. In other words, one must determine the number of routers on path to the target system from your system i.e. number of routers between your system and the target system. This can easily be done, by using the traceroute command.
Tracing route to target.com [203.x.y.224] over a maximum of 30 hops:
1 308 ms 142 ms 127 ms 220.127.116.11
2 140 ms 135 ms * 18.104.22.168
3 213 ms 134 ms 132 ms 22.214.171.124
4 134 ms 130 ms 129 ms 126.96.36.199
5 122 ms 135 ms 131 ms 188.8.131.52
6 141 ms 137 ms 121 ms 203.x.y.224
In the above example, we see that the target system was reached in 6 steps. This means that there are 5 routers separating your system and the target system. In other words, if data is sent from your system to the target system or if data is sent from the target system to your system, then as there are 5 routers through which the data must pass, as a result the TTL value of the data packets will be decremented by 5 in the data transit.
In other words, if the initial TTL value of the data packet were set to 128 by the target system, then when your system receives that particular data packet, then its TTL value would already have been reduced to 123. (As it passes through 5 routers in the data transit.)
“The number of routers in between your system and the target system, tells you as to by how much the initial TTL value set by either system will be reduced in the data transit between the two systems.”
In our example, we have already seen that since there are 5 routers in between our system and the target system, thus the TTL value is reduced by 5 in the data transit, between the two systems.
b.) Determine the final TTL value of a data packet sent by the target system to your system
When the target system sends a data packet to your system, then it sets the initial TTL value of the data packet to a default value (according to the earlier chart.). Each router on the path from the target system to your system reduces this initial TTL value by 1 and forwards the data packet to the next router. Finally, when your system receives that particular data packet, then the TTL value of the data packet at that time is less than the initial TTL value that it was given by the target system, as the routers had already reduced the TTL value.
Hence, the TTL value of a data packet when your system receives it (final TTL value) is much lesser than the initial TTL value that the same data packet was given by the target system. This difference in the TTL values of the data packet is due to the fact that each router in the path, reduce the TTL value of the data packet by one.
“The initial TTL value is the TTL value set by the target system, while the final TTL value is the TTL value which the same data packet has, when it reaches your system. The initial TTL value is always greater than the final TTL value.”
The final TTL value of a data packet sent by the target system can easily be determined by sending any arbitrary data to the target system. The response generated by the target system, due to this arbitrary packet can then be found out, by logging all incoming data packets, on your system, using a packet sniffing software.
In our example, we run the packet-sniffing tool in the background, while we simply do a traceroute on the target system. This packet-sniffing tool must be configured to monitor and log all incoming data packets.
When we traceroute the target system (or send any other arbitrary data to the target system) then we generate a response from the target system. Since we use traceroute in our example, the target system generates an ICMP error message, which is nothing but an error message encapsulated within an IP Datagram. Hence, since the packet sniffing software is monitoring and logging all incoming data packets, it is thus also able to log the incoming ICMP error message.
Once we have logged the response generated by the target system we can easily determine the reduced or final TTL value of the packet containing this response.
For our example, let us assume the final TTL value to be 27. We already know that the number of routers between our system and the target system is 5.Thus in other words the TTL value of a data packet sent by the target system to our system, is reduced by 5.
Initial TTL value of a data packet= Final TTL value of the packet + Number of routers in the path
As a result, in our example, hence the initial TTL value becomes 27+5=32.
c.) Comparing the Deduced Initial TTL value to the default TTL values chart
In the previous step, we have deduced the initial TTL value set by the target system, to be 32. If we compare this initial TTL value, to the chart, then we know that the target system is probably running either Windows NT or Windows 9x.
Hence, by following the above 3 steps in which we make use of traceroute, TTL values and packet sniffers, we can thus, get a very good idea regarding the type of Operating system running on the target system. The process of OS Detection discussed above, can be summarized in the following steps:
1. Determine the number of hops away, the target system lies. This can be done using the traceroute tool.
2. Send any arbitrary data to the target system, in order to generate a response. This response is logged using a packet-sniffing tool running on your system. Using the sniffed data, determine the final TTL value of the target system.
3. Use the relation: Initial TTL value= Final TTL value + Number of hops away it is located, to determine the target system’s initial TTL value.
4. Finally, compare the initial TTL value determine in Step 3 with the chart and get the OS running on the target system.
Example for Remote OS Detection using this method
Following the above 4 steps method, let us take an example, to determine the operating system running on the target system.
1. In the first step, we traceroute the target system to determine the number of hops away the target system lies. This is done in the using the simple traceroute tool:
Tracing route to target.net.in [202.x.2.241] over a maximum of 30 hops:
1 130 ms 121 ms 133 ms 184.108.40.206
2 132 ms 128 ms 120 ms 220.127.116.11
3 123 ms 126 ms 125 ms 18.104.22.168
4 193 ms 137 ms 128 ms 22.214.171.124
5 128 ms 133 ms 127 ms 126.96.36.199
6 204 ms 141 ms 154 ms target..net.in [202.x.2.241]
Here we see that the target system (i.e. target.net.in) is 5 hops away from our system. In other words, there are 5 routers between our system and the target system.
2. In the second step, using a packet sniffing software, we find that each time we send a
Data packet to the target system, it replies with a response whose TTL value is always 250.
3. Using the relation discussed earlier, we find that the initial TTL value of all data
Packets sent by the target system, to our system is 250+5=255.
4. Comparing this initial TTL value to the chart, we find that the operating system
Running on the target system is probably Solaris. (We remove Cisco from the list of probabilities by other remote OS detection methods, like banner grabbing, command manipulation, passive and active fingerprinting, ICMP scanning etc.)
Shortcomings and Countermeasures to OS Detection
This type of remote OS Detection method may not be accurate every single time. This method, however, most of the times does remain fairly accurate.
One simple countermeasure that one could apply to prevent OS detection through prediction of initial TTL value of your system is by changing the default TTL value that your operating system assigns to all outgoing packets.
“Traceroute can be used to detect firewalls, remote OS detection, getting information on network topography, tracing a system geographically and to detect infinite loops routing errors in networks etc.”
There are several variations or breeds of the very popular Traceroute tool. The most common and popular forms of the traceroute utility are as follows:
1. Text Based Traceroute Tools
Almost every operating system ships with its own text based traceroute tool. Such text based traceroute tools display the path from the source system to the destination system, in the form of a normal text based result page. Such traceroute tools are probably the most commonly available and most commonly used. They are quite effective too.
Pros and Cons
+Ships with almost all operating systems
+Free to use
+Classic example of the traceroute tool
-Not as visually appealing as other breeds
This breed of the traceroute tool is in my opinion probably the easiest to use, best and most effective breed. It maps the path from the location of the source system to that of the destination system on a world map and is very accurate in this respect. It not only displays the exact geographical location of the systems, but also mentions the IP Addresses of all systems and their organization names. Visual Traceroute’s latest version also has a new feature, which claims to trace the location of email spammers and analyze and detect network problems.
Pros and Cons
+Maps the path on a world map
+Visually Attractive and Easy to use
+Displays names of organization owning the servers
-Not Free to Use
Pros and Cons
+Free to Use
+Displays tons of information about routers and destination system
+Effective and displays even advanced information
-Lacks a bit on the Usability side
Download URL: http://www.hlembke.de/prod/3dtraceroute/
Features: Maps the path to a remote system on a world map and displays the hostname, name and other important information about all routers and even the destination system.
Download URL: http://www.visualware.com/visualroute/index.html
No matter what tool one might use to Trace the path to the target system, one is always exposing ones identity to the target system. Each time you traceroute a remote system, you are actually putting your IP Address or putting your identity at risk and are putting behind your traces (read: IP Address) on the target system’s log files.
This means that the system administrator of the target system does actually come to know your identity and he might also be able to trace you. Thus, arises the need of a technique of Anonymous Tracerouting.
When you normally traceroute a remote system, using any normal technique, then since a direct connection has been established between your system and the remote system, thus your identity gets revealed to the remote system. However, on the other hand, if there were a way by which one could perform a traceroute on a target system via an indirect connection, then one’s identity would be protected.
There are several websites, which provide free online traceroute tools. It is such free online traceroute tools, which provide a method of anonymous Tracerouting. All that one has to do to perform anonymous Tracerouting, is following the below steps:
a.) Go to the online traceroute tool and use it to perform a traceroute to the target system. Since only the online tool establishes a direct connection with the target system, thus your identity is protected and only the identity of the online tool’s server is revealed. This step just traces the path from the online tool’s server to the target system.
b.) In the second step, one has to use a normal traceroute tool to trace the path from our system to the online tool’s server.
c.) Finally, if we combine the results obtained by both the above steps, then we would get a complete traceroute result from our system to the target system.
Since in the above steps, we established a direct connection only with the online tool’s server, thus our identity is revealed only to this server and not to the target system.
Another method, by which one can perform anonymous Tracerouting, is to register at a shell account provider and then use this shell account to traceroute the target system. However, most shell account service providers are very particular about maintaining logs, which again might reveal your activity on their server.
Detecting Traceroute Attempts on your System
You can detect that an attacker is performing a traceroute on your system, if you see the following symptoms:
1. If you observe port scans on very high UDP ports. This symptom means that the attacker has performed a traceroute on your system. However, it could also mean a simply port scan. Either way, it signifies the fact that your system is being scanned.
2. If the packet-monitoring tool installed in your network, picks up several outgoing TTL-exceeding messages, then it is yet another sign that someone is doing a traceroute on your system.
3. If in these log files, you also observer an outgoing ICMP port unreachable error message, then it means that since a traceroute was done on your system and as the target system i.e. your system, was reached, it responded with this error message.
You can also find our more information on the attacker (if he performs a traceroute on your system) by simply studying the sniffer log files. If you observer the TTL values, then we can easily figure out the following information on the attacker by making use of OS detection techniques discussed earlier in this white paper:
1. The Operating System running on the attacker’s target system.
2. Number of hops away, the attacker is from you.
1. Traceroute can easily be used to find how exactly a particular network is organized and to determine the potential entry points. This means that using the traceroute command is one of the first things that a hacker would do on his quest to getting root on a system. It is also widely being used to determine the geographical position of a particular system and to detect the presence of a firewall. Besides this there are several other purposes for which the traceroute command has started being used. This has created increased need to detect and filter out Traceroute requests at either the router level or the system level.
If you wish to log all Traceroute requests, then using any of the commercial Firewalls will do. Certain advanced firewalls not only detect traceroute requests and log them but also send fake responses. Alternatively you could use any of the various third party freeware utilities for this purpose.
Tdetect is one such utility, which detects and logs all ICMP and UDP traceroute packets with a TTL value equal to 1. There is yet another, more interesting, utility named RotoRouter which not only detects and logs all such request but also sends fake responses.
You can easily get any of these utilities at any of the below sites:
The recommended method to prevent your network from responding to traceroute requests is to configure your routers to not respond to any packet having a TTL value of 1. (or 0). This can easily be done by adding the below access list:
access-list 101 deny ip any any 11 0 ! ttl-exceeded
What this basically does is that it configures the router to not respond with a TTL Exceeded message to a traceroute request packet. One could also use the following ACL as a traceroute countermeasure:
access-list 101 deny icmp any any 11 0
On this note, we come to the end of the white paper on traceroute.