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

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

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

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.

If you scrub packets where the TTL changes, what happens to a connection where the route changes and the TTL has a valid reason for changing?

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").

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.

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

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.

"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.

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

Hasn't Windows tracert always used TCP?

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

I use nping for this. If you're not aware of it, it installs with nmap.

nping --traceroute --tcp -p80 target.com

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!