Tracing behind the firewall [LWN.net]

Tracing behind the firewall

Posted Jan 11, 2007 11:44 UTC (Thu) by jannic (subscriber, #5821)
Parent article: Tracing behind the firewall

There is, however, a very simple defense against this attack: Just configure your firewall to drop (or or answer with TTL exceeded) any packet with a too low TTL field. The minimal TTL value allowed should be bigger than the largest number of hops behind the firewall. That way, it'll look like all hosts behind your NAT have the same number of hops, and you don't get any information about the individual steps from outside.

Something like "iptables -I FORWARD -m ttl --ttl-lt 4 -j DROP" should to the job. Unfortunately, there is no --reject-with icmp-ttl-exceeded, AFAIK.

Tracing behind the firewall

Posted Jan 20, 2007 11:37 UTC (Sat) by jengelh (subscriber, #33263) [Link]

But -m ttl --ttl-lt 4 might match valid connections. What if, for whatever reason, it takes 61 routers to get through to www.ebay.com? Then this happens: your internal box sends TCP SYN with a hoplimit/ttl of 64, but the return TCP-ACK cannot pass your firewall because the return path already decreased the ttl too much. Boom, website hangs. It does not need the value pairs 61/64. Anything n-3/n does work, given that n is the default ttl for the OS or connection.

Tracing behind the firewall

Posted Jan 20, 2007 11:47 UTC (Sat) by jengelh (subscriber, #33263) [Link]

...and it's not uncommon for really strange things to happen on the Internet wrt. TTLs. Check this:

$ traceroute -n 82.83.11.215
traceroute to 82.83.11.215 (82.83.11.215), 30 hops max, 40 byte packets
 1  134.76.22.1
 2  134.76.23.254
 3  188.1.46.213
 4  188.1.18.62
 5  188.1.145.126
 6  188.1.56.22
 7  145.254.16.17
 8  145.254.18.62
 9  145.254.11.226
10  82.83.11.215

$ ping -c1 {all_addresses} | grep ttl
64 bytes from 134.76.22.1:    icmp_seq=1 ttl=126 time=1.31 ms
64 bytes from 134.76.23.254:  icmp_seq=1 ttl=254 time=1.58 ms
64 bytes from 188.1.46.213:   icmp_seq=1 ttl=253 time=2.12 ms
64 bytes from 188.1.18.62:    icmp_seq=1 ttl=252 time=3.70 ms
64 bytes from 188.1.145.126:  icmp_seq=1 ttl=251 time=17.4 ms
64 bytes from 188.1.56.22:    icmp_seq=1 ttl=250 time=16.4 ms
64 bytes from 145.254.16.17:  icmp_seq=1 ttl=249 time=16.6 ms
64 bytes from 145.254.18.62:  icmp_seq=1 ttl=248 time=21.4 ms
64 bytes from 145.254.11.226: icmp_seq=1 ttl=247 time=21.8 ms
64 bytes from 82.83.11.215:   icmp_seq=1 ttl=56 time=27.0 ms

So I would not be wondering if someone advertently decreased or increased the TTL, leading to either be inadvertently blocked by your iptables rule (because some router just decreased it), or inadvertently being not blocked by your rule (some router increased it), respectively. (The route from me->82.83.11.215 was stable (the same) on repeated traceroute runs.)