Re: [patch] traceroute release

["Eddie Bell" <ejlbell () gmail com>]

hey,

Unfortunately I don't think there is an easy way to perform traceroute
with connect(). It could probably be achieved with divert sockets but
would be messy, require root access/kernel support and I don't even
know if they exist on windows. Maybe in the future I will try, but for
now it looks like you are stuck, sorry.

- eddie

On 05/09/06, Ionreflex <ionreflex () gmail com> wrote:
> Hi everyone,
>
> It's a little late but I believe I have to give some feedback about this
> since I was pretty enthousiast about the traceroute feature...
>
> In my case, the one I tried to explain on my post on the 7 of August 2006,
> the only way my scan from nmap will be trap by the VPN agent is with a
> Connect() scan, which is incompatible with the traceroute feature, every
> other type of scan will go straight through my default gateway...
>
> P.S. : first time i tried using this list, I created a new thread instead of
> replying to the original one; if someone could tell me what i did wrong,
> paleez do so to my email directly! Tanks!
>
>
>
> Ion
>
> 2006/8/28, Eddie Bell <ejlbell () gmail com>:
> > hi all,
> >
> > Here is the last patch from my summer of code. It is a parallel
> > traceroute patch, activated with --traceroute. It was mainly developed
> > on linux so any windows testing would be appreciated.   Bugs reports
> > or feature ideas are welcome
> >
> > o The patch for 4.20ALPHA4 is attached
> > o Source distribution can be downloaded here
> > http://eddiebell.co.uk/nmap-4.20ALPHA4-traceroute.tar.gz
> > o Windows binary distribution can be downloaded here
> > http://eddiebell.co.uk/nmap-4.20ALPHA4-traceroute-win.zip
> >
> > For anyone interested in how it works, ill past the information
> > included in Traceroute.cc below
> >
> > thanks
> > - eddie
> ***************************************************************************************************
> > * A multi-protocol parallel traceroute implementation for nmap.
> > * For more information on how traceroutes work:
> > * http://en.wikipedia.org/wiki/Traceroute
> > *
> > * Nmaps traceroute takes in a list of scanned targets and determines a
> valid
> > * responsive port to trace to based on the scan results, scan protocol and
> > * various pieces of protocol data.
> > *
> > * It first sends a probe to the target port. From the reply traceroute is
> able
> > * to infer how many hops away the target is. Nmap starts the trace by
> sending
> > * a packet with a TTL equal to that of the hop distance guess. If it gets
> an
> > * ICMP_TTL_EXCCEDED message back it know the hop distance guess was under
> so
> > * nmap will continue sending probes with incremental TTLs until it
> receives a
> > * reply from the target host.
> > *
> > * Once a reply from the host is received nmap sets the TTL to once below
> the
> > * hop guess and continues to send probes with decremental TTLs until it
> reaches
> > * TTL 0. Then we have a complete trace to the target. If nmap does not get
> a
> > * hop distance probe reply, the trace TTL starts at one and is incremented
> > * until it hits the target host.
> > *
> > * Forwards/Backwards tracing example
> > *  hop guess:20
> > *  send:20  --> ICMP_TTL_EXCCEDED
> > *  send:21  --> ICMP_TTL_EXCCEDED
> > *  send:22  --> Reply from host
> > *  send:19  --> ICMP_TTL_EXCCEDED
> > *  ....
> > *  send:1   --> ICMP_TTL_EXECCEDED
> > *
> > * The forward/backwards tracing method seems a little convoluted at first
> but
> > * there is a reason for it. The first host traced in a Target group is
> > * designated as the reference trace. All other traces
> > * (once they have reached their destination host)  are compared against
> the
> > * reference trace. If a match is found the trace is ended prematurely and
> the
> > * remaining hops are assumed to be the same as the reference trace. This
> > * normally only happens in the lower TTls, which rarely change. On average
> nmap
> > * sends 5 less packets per host. If nmap is tracing related hosts
> > * (EG. 1.2.3.0/24) it will send a lot less packets. Depending on the
> network
> > * topology it may only have to send a single packet to each host.
> > *
> > * Forwards/Backwards tracing saves bandwidth, speeds up the scan and stops
> local
> > * routers from rate limiting ICMP_TTL_EXCCEDED messages
> > *
> > * Traceroute employs a dynamic timing model similar to nmaps main
> > scanning function
> > * but a little more light weight. It keeps track of sent, received and
> dropped
> > * packet, then adjusts timing parameters accordingly. The parameters
> > are; number of
> > * retransmissions, delay between each sent packet and the amount of time
> to wait
> > * for a reply. This are initialised based on the timing level (-T0 to -T5)
> > *
> > * The output from each trace is consolidated to save space, XML
> > logging and debug
> > * mode ignore consolidation. There are two types of consolidation timeout
> and
> > * reference trace.
> > *
> > * Timed out
> > *  1 ...      Hop 1 timed out
> > *  1 ... 6    Hop 1 to 6 timed out
> > *
> > * Reference trace
> > *  1 --       Hop 1 has been taken from the reference trace
> > *  1 --> 6    Hop 1 to 6 have been taken from the reference trace
> > *
> > * Traceroute also optimises performance by using DNS caching
> (nmap_dns.cc).
> > * Each host name resolved is stored in a cache and each time it is used a
> > * cache hit variable is incremented. When the cache is full, entries with
> > * the lowest cache hit counter are evicted. This algorithm is called
> > * "least frequently used with ageing". Dns name resolution is slow
> > * (not because of nmap) so caching improves traceroute times especially
> > * because many of the host names will reoccur frequently.
> > *
> > * Traceroute does not work with connect scans or idle scans and has
> trouble
> > * with ICMP_TIMESTAMP and ICMP_ADDRESSMASK scans because so many host
> filter
> > * them out. The quickest seems to be SYN scan.
> > *
> > * Bugs and Future Features:
> > *  o The code, currently, only works with ipv4.
> > *  o Send both UDP and TCP hop distance probes no matter what the
> > *    scan protocol

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org