Nmap Development mailing list archives
Re: [patch] traceroute release
From: Ionreflex <ionreflex () gmail com>
Date: Tue, 5 Sep 2006 14:47:19 -0400
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<http://seclists.org/nmap-dev/2006/q3/0187.html>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
Current thread:
- [patch] traceroute release Eddie Bell (Aug 28)
- Re: [patch] traceroute release Ionreflex (Sep 05)
- Re: [patch] traceroute release Eddie Bell (Sep 06)
- Re: [patch] traceroute release Ionreflex (Sep 05)