More on traceroute with TCP.

[Darren Reed <darrenr () reed wattle id au>]

It occurred to me last night whilst trying to get some sleep that
there's an even more sneaky way to do traceroute'ing with TCP, so
good (in theory anyway :) that it'll make it through any packet
filtering firewall, with or without NAT (unless countermeasures
are specifically undertaken).

If you can get John Smith from sucker.com to connect to your WWW
site evil.com, then at least from the outgoing connection request,
his firewall should be (somehow) waiting for the relevant response.
It seems, therefore, not unreasonable to do a traceroute with the
SYN-ACK which is actually valid.  Everyone is used to delays on the
"World Wide Wait" these days so it shouldn't arouse any suspicions.
In fact, there's no reason to use SYN-ACK, you could wait until the
connection is established and just pluck out the correct ACK/SEQ
values from the TCP information at evil.com.  Since this is abusing
a currently open TCP connection, it should also make it through
any NAT that was setup.  The same sort of traceroute technique
could be used with UDP (even easier in some respects).

The first method for defense is to block ICMP packets going out.
There are few reasons why you'd want to allow just any type of
ICMP packet back out through your firewall, valid connection or
not.  It seems our favourite router-in-software (or firewall as
they call it) vendor has a not-so-secure default here as well.

The second way to combat this is to attempt to intelligently filter
response based on the TTL value in the incoming packet.  For example,
if you know that the greatest distance from the firewall to any host
is, say, 5 hops, then any packet coming in from the big bad Internet
with a TTL less than 5 should immeadiately be suspect (it's not likely
to reach it's intended destination anyway).

The third way to combat this problem is to make good use of proxies
and not expose any of your internal systems to direct packet flow from
the Internet.

Darren