can the TTL increase through the network path?

[sl33p]

Hi folks,

Many of you know how important is the analysis and planning of the targeted environment before the attempt of a successful penetration test.

I got the idea, and I am trying to draw the network design in order to visualize things better. Many tools can be used to do that, I used hping3 as it comes with BT4, others include tcptraceroute, firewalk-5.0 (discontinued by developers...), etc.

What in fact is done by the program (hping3) is TCP/IP packet injection (with the SYN bit enabled) hop-by-hop until it reaches the final host (destination).

By sniffing the traffic, I could determine the TTL of the various responding hosts within the path until my packet "got there".

As far as I know the default behavior of a network would be to decrement the TTL of a device as long as I go deeper on the network (meaning that I am getting closer the targetet IP). Like, for example, in a network with 3 devices (routers) before my targetet IP it would be something like this:

123.123.123.122 TTL 255 (my gateway)
123.123.123.133 TTL 254
123.123.123.144 TTL 253
177.177.177.177 TTL 124 (target IP)

Demonstrating that the host is Windows based (TTL starts at 128) and is placed 4 hops from me.
What I know by the notice though, is that sometimes the TTL increases. Likewise:

123.123.123.122 TTL 255 (my gateway)
123.123.123.133 TTL 250
123.123.123.144 TTL 251
177.177.177.177 TTL 124 (target IP)

This is confusing, because I can't know for sure the network structure (if they are placed aside or below/above each other).

Can someone here enlighten this topic?
Thanks in advance!
sl33p

[imported_cybrsnpr]

What I know by the notice though, is that sometimes the TTL increases.
sl33p

Two guesses:

1. There is a routing loop between those 2 hops.
2. Maybe hping increments the TTL for each hop and that particular node didn't respond to the first packet, so hping incremented by one automatically.

As I said, these are just guesses...very curious indeed!

regards,

cybrsnpr

[sl33p]

Thanks for your attention.

1. What would be a routing loop? How could I certify this behavior?
2. As far as I understood, what hping does: it sends a SYN-TCP packet with a TTL of 1 to obligate the respondant (the next hop) to send a packet back with the ICMP type 11 (Time-to-live exceeded) data encapsulated in the content. So, you look into the TTL of the TCP packet (IP layer), not the TTL of the ICMP message (because it will always be 1).

Additionally, I know that they're configurable (www[dot]map[dot]meteoswiss[dot]ch[slash]map-doc[slash]ftp-probleme.htm), but honestly I have never found a device with TTL modified by a system administrator.

HTH

[streaker69]

I'm not so sure your theory is correct on that after doing some experimenting here.

From my desk I ping a switch that's across a T1 and then through one switch, I get a TTL of 62.

If I ping one device that's connected to that switch, I get a TTL of 126 and another device I get a TTL of 28. Both of those device are on the same switch, and technically the same distance from me, but are just different kinds of devices.

Also, pinging a router across one of my VPN links, I get a TTL of 63, but pinging a device that's connected on the other side of that router, I get a TTL of 62, but pinging another device connected to that router, I get a TTL of 126.

[PeppersGhost]

Two different questions here sleep. Yes normal routing behavior is to decrement TTL each hop and if TTL hits 0 the packet is discarded. However, the ICMP (i.e. tracert, hping etc) protocol progressively increments the TTL field (2, 3, 4 so on) for each sequence of messages. This provides the trace with the address of each hop as packets move towards the destination.

[lupin]

Two different questions here sleep. Yes normal routing behavior is to decrement TTL each hop and if TTL hits 0 the packet is discarded. However, the ICMP (i.e. tracert, hping etc) protocol progressively increments the TTL field (2, 3, 4 so on) for each sequence of messages. This provides the trace with the address of each hop as packets move towards the destination.

Actually, stricly speaking, it's a router that decrements the TTL value in an IP packet that it forwards. Could a router be configured to increment a TTL value instead of decrementing it? Sure it could, although configuring a router to bahave that way, would be difficult, unusual and likely to cause problems.

In addition, a tool that uses ICMP like hping or tracert to perform a traceroute will create IP packets that have incrementing TTL values. The ICMP protocol doesn't have anything to do with this - embedded protocols other than ICMP can and are used to perform a traceroute (Unix traceroute usses UDP packets for example). The thing that makes a traceroute work is the steadily incrementing TTL value whcih sits in the IP Header of a packet, and the embedded protocol (TCP/UDP/ICMP) is only of secondary interest in the process.

And for the OP, a packet normaliser could change the TTL on packets coming into a network...

[PeppersGhost]

Two different questions here sleep. Yes normal routing behavior is to decrement TTL each hop and if TTL hits 0 the packet is discarded. However, the ICMP (i.e. tracert, hping etc) protocol progressively increments the TTL field (2, 3, 4 so on) for each sequence of messages. This provides the trace with the address of each hop as packets move towards the destination.

Actually, stricly speaking, it's a router that decrements the TTL value in an IP packet that it forwards. Could a router be configured to increment a TTL value instead of decrementing it? Sure it could, although configuring a router to bahave that way, would be difficult, unusual and likely to cause problems.

In addition, a tool that uses ICMP like hping or tracert to perform a traceroute will create IP packets that have incrementing TTL values. The ICMP protocol doesn't have anything to do with this - embedded protocols other than ICMP can and are used to perform a traceroute (Unix traceroute usses UDP packets for example). The thing that makes a traceroute work is the steadily incrementing TTL value whcih sits in the IP Header of a packet, and the embedded protocol (TCP/UDP/ICMP) is only of secondary interest in the process.

And for the OP, a packet normaliser could change the TTL on packets coming into a network...

Oh, I stand corrected lupin. Good eye. It is the tool that increments the TTL not the ICMP protocol. However, it is tracert + ICMP Time Exceeded Message that allows tracert to function they way it does. So ICMP does have something to do with it. The first sequence of messages sent from tracert will have a TTL of 1. This causes the TTL to timeout the packet at the first router. The router then responds with the ICMP Time Exceeded Message. Tracert now has the address of the first hop. Tracert then progressively increments the TTL field (2, 3, 4, and so on) for each sequence of ICMP Time Exceeded Messages received. This provides the trace with the address of each hop as packets move towards the destination.

As well sir, IP decrements the TTL field to prevent the possibility of a packet from traversing the network endlessly. Lupin sir, I will look learnedly onto the TCP/UDP/ICMP portion of your lesson with the fire heart of a raging beast.

After sending my host confirmation I had anticipated a Time Exceeded message until I received your route redirection so I concede to you sir, and now transmit my source quench as I simply do not have enough buffer space to continue receiving incoming packets.

[lupin]

However, it is tracert + ICMP Time Exceeded Message that allows tracert to function they way it does. So ICMP does have something to do with it.
...
Tracert then progressively increments the TTL field (2, 3, 4, and so on) for each sequence of ICMP Time Exceeded Messages received.

ICMP has something to do with the response yes, in that ICMP Time Exceeded in Transit Error datagrams are sent by routers and used by traceroute to determine individual nodes in the path a packet takes. However, the ICMP protocol has nothing to do with the creation of the packets that have the incrementing TTL values. The TTL value, after all, is actually located in the IP Header, so if you wanted to ascribe this behavior to a protocol, the IP protocol would be a more accurate choice.

The sending process doesn't need to wait for an ICMP error message in response in order to increment the TTL value either. Otherwise the traceroute program would get stuck when any one particular router did not respond with such an ICMP error message (because of packet filtering for example).

Lupin sir, I will look learnedly onto the TCP/UDP/ICMP portion of your lesson with the fire heart of a raging beast.

Glad you liked it, and even though I do like being called sir, it is perfectly permissible to keep things informal here.