Detecting transparent proxy servers with tracetcp

While recently remotely troubleshooting an email problem, I found messages being rejected due to a 452 insufficient system storage error. When I examined the email server I found no such storage issue existed, and eventually involved Microsoft (Exchange) to help diagnose the issue. After hours of work MS gave up. Eventually, I found that if telnet’d locally into the mail server I didn’t get the error, but did if I was connecting in from the net. After quizzing the client as to what’s plugged into what, regarding there infrastructure, The client explained that there previous vendor had left a mysterious white box connected between there network and the internet. Ah Ha, a Linux based firewall was setup in line and just happened to be performing transparent spam filtering, when the device ran out of hard drive space the error manifested.

After going though these steps I realize transparent filtering devices are becoming more and more common, and so searched and found a great tool to quickly detect and trace out TCP connections. Welcome to tracetcp From the author L.M.Witek:
tracetcp is a traceroute utility for WIN32 that uses TCP SYN packets rather
than ICMP/UDP packets that the usual implementations use, thus bypassing
gateways that block traditional traceroute packets.

In addition to providing the functionality of the standard traceroute
utility tracetcp allows a trace to be performed over any TCP port. This
allows the discovery of what ports a filewall blocks and also the presence
of any transparent proxies that have been put in place.

To trace out smtp, simply enter the following syntax: tracetcp post.somehost.com:smtp
Then complete the same trace using traceroute and compare the results.

C:Documents and Settings Desktoptracetcp-0.99.4beta>tracetcp mail.topsi
ght.net:smtp

Tracing route to 65.98.17.7 on port 25
Over a maximum of 30 hops.
1 2 ms 2 ms 2 ms
2 15 ms 14 ms 14 ms
3 11 ms 11 ms 11 ms 69.183.224.49 [dist1-vlan50.wlfrct.sbcglobal.net]
4 14 ms 12 ms 12 ms 69.183.224.2 [bb2-g1-0-0.wlfrct.sbcglobal.net]
5 84 ms 178 ms 105 ms 151.164.95.1 [ex2-p2-0.eqnwnj.sbcglobal.net]
6 17 ms 20 ms 18 ms 151.164.249.74 [asn1299-telia.eqnwnj.sbcglobal.net]
7 17 ms 17 ms 17 ms 213.248.83.106 [fortress-120799-nyk-b2.c.telia.net]
8 18 ms 18 ms 18 ms 208.116.63.254
9 Destination Reached in 16 ms. Connection established to 65.98.17.7
Trace Complete.




C:Documents and SettingsDesktoptracetcp-0.99.4beta>tracert mail.topsig
ht.net

Tracing route to topsight.net [65.98.17.7] over a maximum of 30 hops:

1 <1 ms <1 ms 1 ms
2 13 ms 12 ms 12 ms
3 10 ms 10 ms 10 ms dist1-vlan50.wlfrct.sbcglobal.net [69.183.224.49]
4 11 ms 10 ms 10 ms bb2-g1-0-0.wlfrct.sbcglobal.net [69.183.224.2]
5 14 ms 14 ms 14 ms ex2-p2-0.eqnwnj.sbcglobal.net [151.164.95.1]
6 14 ms 22 ms 15 ms asn1299-telia.eqnwnj.sbcglobal.net [151.164.249.74]
7 15 ms 15 ms 15 ms fortress-120799-nyk-b2.c.telia.net [213.248.83.106]
8 15 ms 15 ms 15 ms 208.116.63.254
9 24 ms 15 ms 14 ms 65.98.17.7

Trace complete.


As you can see in the above example both traces are identical. This means that there are no proxies between me and 65.98.17.7. However, if 65.98.17.7 is a NAT gateway this method will not detect a transparent proxy internal to the NAT if the trace is run externally. To detect A NAT device prepare to break out your protocol analyzer of choice and compare IP TTL values. Also, note that this technique will not detect ARP redirection attacks,

Note that if my TCP TRACE output looked like the following I would know a transparent proxy was in use:

C:Documents and Settings Desktoptracetcp-0.99.4beta>tracetcp mail.topsi
ght.net:smtp

Tracing route to 65.98.17.7 on port 25
Over a maximum of 30 hops.
1 2 ms 2 ms 2 ms
2 Destination Reached in 16 ms. Connection established to 65.98.17.7
Trace Complete.

For more information on TraceTCP see http://tracetcp.sourceforge.net/