
TCP Traceroute - Anon84
http://www.catonmat.net/blog/tcp-traceroute/
======
majke
I'm not sure about `tcptraceroute` but `traceroute -T` seems to be using SYN
packets with tweaked TTL value [1].

There is an even more interesting technique - injecting packets with modified
TTL into a currently running and valid TCP/IP connection. This often can be
used to detect network setup behind NAT on the server side. I think the most
famous attempt was 0trace by Michal Zalewski [2] but there are many
implementations. Oh boy, one day I even created an Nmap script to do this [3],
those were the days :)

[1] <http://linux.die.net/man/8/traceroute>

[2] <http://seclists.org/fulldisclosure/2007/Jan/145>

[3] <http://seclists.org/nmap-dev/2007/q3/186>

~~~
X-Istence
And that is why you should scrub all incoming packets and make sure that they
don't have a TTL that is too low ...

PF's scrub reassemble tcp for example will make sure that the TTL can't be
lowered in an already existing connection ...

[1] <http://www.openbsd.gr/faq/pf/scrub.html>

~~~
majke
Alternatively - watch out what ICMP errors are outgoing from your servers.
(But don't block all ICMP or you'll screw up MTU discovery [1])

If you're worried about exposing your internal setup you also need to filter
packets with unusual IP flags such as "Record Route" [2] or "Internet
Timestamp" [3]. Fortunately scrub should notice that.

[1] <http://en.wikipedia.org/wiki/Path_MTU_Discovery>

[2] <http://tools.ietf.org/html/rfc791#page-18>

[3] <http://tools.ietf.org/html/rfc791#page-22>

If you have a source NAT on your servers, it's likely that an attacker can
easily detect that, no matter ICMP / TTL / IP options setting. Running p0f on
established connections will show your setup, for example:

<http://seclists.org/nmap-dev/2007/q1/175>

~~~
X-Istence
It becomes much harder to identify NAT when you also scrub out going packets,
and change the packet IP identification field with a random-id.

Other things that help as well is to not load balance the TCP/IP connection,
but rather terminate on the first machine, then pass the connection through
using something like varnish/haproxy.

------
mct
Hi. Author of the original tcptraceroute here.

I first wrote tcptraceroute is 2001, while I was working for a large Mid-
Atlantic NSP. I'd routinely see customers (and our NOC staff) reporting that
traceroutes to many popular sites (such as ebay.com, microsoft.com, etc) were
broken, and wondering if their connectivity was somehow defective. I would
have to explain (again) how traceroute worked, and how the probe packets it
uses are now (sadly) routinely firewalled, thus breaking our diagnostic tools.

At one point, the idea struck me that there was no reason we couldn't use any
type of packet as a probe packet for traceroute -- including packets that
firewalls found permissible. After a night or two hacking with libnet and
libpcap I had a working implementation. Suddenly being able to traceroute
through those firewalls and see the internal network of those large networks
felt magical, like having X-Ray vision. :-) Over time, I added other features
that provided even greater visibility -- such as the ability to detect when
some NAT/load-balancers aren't doing as good a job as they could be, and thus
revealing the internal IP address you're being NAT'd to. (Have a peek at
<http://michael.toren.net/code/tcptraceroute/examples.txt> for some example
output.)

I haven't done a great job of investing time into tcptraceroute over the past
few years. The code is still functional and hasn't suffered from any bitrot,
but the last "beta" release was "1.5beta7", back in 2006. There's no reason it
shouldn't have been released as "1.6", I just never got around to officially
"releasing" it. There are also a bunch of additional features I've
contemplated over the years that I'd really like to add. This thread has
definitely invigorated me to put more energy into the project soon, which I'm
grateful for. :-)

Tangentially, one of the annoying things about "traceroute" programs in
general is that the name is very overloaded, with many unrelated projects over
the years calling themselves "traceroute". Further complicating things, a
brand new project called "traceroute" was started a few years ago with the
stated goal of only supporting Linux, and wishing to be the one, true
traceroute in all Linux distributions. That project also implemented the
ability to use TCP probe packets, which is awesome. I'm glad to see that there
are other implementations out there. But sadly, they're also distributing a
shell script called "tcptraceroute" that invokes their traceroute program with
the flag to set the probe type to TCP. In Debian, if you have the "traceroute"
package installed but not the "tcptraceroute" package, typing "tcptraceroute"
will invoke their traceroute program. If you instead have both the
"traceroute" and "tcptraceroute" packages installed, typing "tcptraceroute"
will invoke my traceroute program. As the two programs differ in other ways,
this can be really annoying, and lead to the type of confusion that can be
seen elsewhere in this thread. I've also received a number of messages from
people asking for help with "tcptraceroute", only to have us both later figure
out that they're really running the other "tcptraceroute" program, which is
very frustrating for both of us.

I'm not sure what the best course of action is. I strongly believe in, and
advocate, open source. I want other people to be able to look at my code,
learn from it, borrow useful parts, and distribute changes. And yet, I really
don't want someone distributing a program that has the same proper noun I
chose years earlier for my own project. This is something I've thought about
off and on over the years as I consider releasing (and naming) other open
source projects, but don't yet have a good answer. I suppose one solution is
to utilize trademark law, but that's something I have very mixed feelings
about.

This turned into a much longer post than I intended :-), but if anyone has any
thoughts, I'd love to hear them! My contact information can be found in my
profile.

Thanks!

------
dfc
I am not sure how new this functionality is. Based off the changelog
tcptraceroute has been a shell wrapper since 2007.

    
    
        2007-07-19  Dmitry Butskoy  <Dmitry@Butskoy.name> - 2.0.6
          
            *  Add tcptraceroute(8) shell wrapper
    
        2007-07-16  Dmitry Butskoy  <Dmitry@Butskoy.name> - 2.0.5
        
            *  New implementation of tcp method ("-T"), using
               half-open technique. The old implementation module
               renamed to "tcpconn" ("-M tcpconn").

~~~
pkrumins
Ah sorry, I should have said relatively new functionality. Also I should have
mentioned that there are different traceroute implementations. I'll update my
post.

Edit: updated the post.

~~~
dfc
I think route9's firewalk did this back when I had dial up.

~~~
pkrumins
Yeah. Well, I actually wanted to write about tcptraceroute program originally,
but then discovered that traceroute on one of my systems had the -T flag. So I
thought, wow, traceroute now can use the tcp protocol. That's why I wrote "was
added recently" because I hadn't seen the -T flag before. It turns out that
that system had the <http://traceroute.sourceforge.net/>, while my other
system had the ftp://ftp.ee.lbl.gov/traceroute-1.4a12.tar.gz, which doesn't
have -T.

------
muppetman
"Was added just recently" - not sure about being added to the traceroute
program, but I've been using tcptraceroute for years.

It is very handy.

~~~
pkrumins
I updated the post. It wasn't really added just recently. Here's why I said
that: <http://news.ycombinator.com/item?id=5276983>

------
tptacek
Hasn't Windows tracert always used TCP?

~~~
jburnat
No, the difference is that the Windows version defaults to ICMP, while the
Linux one to UDP.

