bugtraq - Re: [Full-disclosure] 0trace - traceroute on established connections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0701070152270.22436@dione>
Date: Sun, 7 Jan 2007 01:58:51 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ne.ids.pl>
To: bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: [Full-disclosure] 0trace - traceroute on established connections

On Sun, 7 Jan 2007, Michal Zalewski wrote:

> [ Of course, I might be wrong, but Google seems to agree with my
>   assessment. A related use of this idea is 'firewalk' by Schiffman and
>   Goldsmith, a tool to probe firewall ACLs; another utility called
>   'tcptraceroute' by Michael C. Toren implements TCP SYN probes, but since
>   the tool does not ride an existing connection, it is less likely to
>   succeed (sometimes a handshake must be completed with the NAT device
>   before any traffic is forwarded). ]

Erik Kamerling pointed off-the-list that everybody's favourite Dan
Kaminsky (www.doxpara.com) did some research on that subject, too; his
'paratrace' followed a similar principle, but relied on the party
correcting out-of-sync retransmissions. I found this approach to give poor
results in today's networks with overzealous commercial packet filters,
and hence, my tool implements an invasive approach where the current
session is trashed with in-sync data to solicit a high response rate.

Still, a credit is due!

Cheers,
/mz