NAME
paratrace − Parasitic Traceroute via Established TCP Flows & IPID Hopcount
SYNOPSIS
paratrace [-b bandwidth] [options] host|network
PACKAGE
Paketto Keiretsu 1.0
DESCRIPTION
Paratrace traces the path between a client and a server, much like "traceroute", but with a major twist: Rather than iterate the TTLs of UDP, ICMP, or even TCP SYN packets, paratrace attaches itself to an existing, stateful-firewall-approved TCP flow, statelessly releasing as many TCP Keepalive messages as the software estimates the remote host is hop-distant. The resultant ICMP Time Exceeded replies are analyzed, with their original hopcount "tattooed" in the IPID field copied into the returned packets by so many helpful routers. Through this process, paratrace can trace a route without modulating a single byte of TCP/Layer 4, and thus delivers fully valid (if occasionally redundant) segments at Layer 4 -- segments generated by another process entirely.
OPTIONS
-s [hopfuzz]
"Overshoot" target host by a number of hops equal to the hopfuzz. paratrace passively estimates the number of hops away that a given target is, based on the incoming ACK/PSH|ACK’s TTL’s deviation from a clean factor of 64. This is, at *best*, a rough estimate, so we set the number of hops larger to make sure we get all the way there. (The scan is stateless, so we can’t just send more packets when we don’t get all we wanted.) Setting this value to -1 may offer some degree of stealth.
-t [number of seconds]
Set maximum number of seconds that may pass before listening process gives up on receiving any more responses. This timer is reset with every good response, whether the port is up or down.
-b [bandwidth][b][k][m][g]
Limit the amount of bandwidth that scanrand may use for its outgoing requests. -b 100k would limit said bandwidth to 100kbyte/s. Note, since outgoing SYN frames constitute only 64 bytes on the wire, very little bandwidth can go very, very far. The bandwidth value of 0 -- set by default -- corresponds to no bandwidth limitation.
|
-n |
Specify network, instead of host, to attach a parasitic trace to. This has the caveat of requiring an IP address, rather than a single DNS name, but in return CIDR notation(1.2.3.0/24) lets users specify pretty decent host ranges they’re interested in. | ||
|
-N |
Use Reverse-DNS to determine a DNS host name that matches the source of a detected packet. | ||
|
-NN |
Use Reverse-DNS to determine a DNS host name that matches the intended destination of a given packet. | ||
|
-v |
Verbosity Level 1: Mark the sending of packets. | ||
|
-vv |
Verbosity Level 2: Output all interpreted TCP and IP headers. |
ADDRESSING
-d <interface>
Use this Layer 2 Device for all traffic.
-i <source ip>
Use this Layer 3 Source IP for all traffic.
BUGS
Again, it is very easy to scan faster than the network can accept packets. No code exists to dynamically reduce scan speed. Furthermore, we can only capture absolute latency from beginning of scan, rather than latency of a given response to its received packets. There is a fix in progress for this. Also, bandwidth calculation presently doesn’t take into account the time necessary to actually send a given packet. This will be fixed.
AUTHOR
This work has been done by Dan Kaminsky of DoxPara Research, who may be reached at dan [AT] doxpara.com.