Tracing behind the firewall

A new tool, 0trace, that can sometimes peek through a firewall and provide information about the hosts and addresses living behind it was recently released. The tool itself is in a rough, proof-of-concept form, but it can provide interesting results that are likely unexpected by the network administrator. A bit of a look at how 0trace accomplishes this feat requires a bit of firewall background as well.

Many firewalls use Network Address Translation (NAT) to multiplex multiple internal computers over one external, routable, IP address. When an internal host makes a connection to the outside world, the NAT device rewrites the addresses in the packets so that the external host believes it is talking to the firewall itself rather than the actual host (which is typically in the private, unroutable IP space). In order to do that, the NAT device records information about the connection: the IP addresses for the internal and external hosts as well as port information. It is this established connection table that 0trace exploits in order to do its work.

The basic scheme is much the same as traceroute in that 0trace sends packets with increasing time-to-live (TTL) values and listens to the ICMP "time exceeded" responses to determine the hosts that the packet has traversed. The difference is that 0trace uses an established connection to piggyback its probes on. Because many NAT implementations do not closely examine packets that are associated with an established connection, those responses, even from internal hosts, are forwarded along.

Users of traceroute are familiar with the '*' character that gets printed when there is no response from one of the hops; tracing a route these days typically ends in a series of hops without a response resulting in several rows of '* * *'. These are often systems that are behind firewalls which filter out the probe packets that traceroute sends because they are not associated with a connection that it knows about. The example in the announcement shows 0trace output from a scan of www.ebay.com with several internal IP addresses past the point where the traceroute output stops.

In order to run 0trace, one must first establish a connection with the host of interest. Using telnet to port 80 is one way to go about that; once the connection is established, the 0trace shell script is run. That script sets up a tcpdump to grab the traffic to and from the supplied IP address and then waits. The user must generate some traffic at this point and typing 'GET / HTTP/1.0' (followed by one return) is a good way to do that. 0trace analyzes the TCP packet dump to retrieve the sequence and ack numbers from the conversation; the shell script then passes those off to the 0trace C program (sendprobe). Using proper sequence/ack numbers from the established connection further disguises the 0trace traffic as a legitimate part of the conversation.

This technique is not new and the author, Michal Zalewski, credits a number of other people in the announcement and ensuing thread, but this is likely the first public implementation. The implementation is very dependent on the exact format of tcpdump output and is rather fragile because of that, but it is an interesting proof-of-concept. Zalewski invites interested people to improve upon it. Using it against hosts without their permission might be considered illegal in some jurisdictions; one should exercise care before using it. It does show a weakness in current NAT implementations that will likely need to be addressed.