Re: Improving nmap performance
Lamont Granquist <[email protected]> Fri, 30 Aug 2002 19:26:24 -0700 (PDT)
| Newsgroups | gmane.comp.security.nmap.general |
|---|---|
| Message-ID | <[email protected]> |
One thing to note is that on FreeBSD systems there's a sysctl called net.inet.icmp.icmplim which determines the number of closed-port RSTs that a box will give out per second, which is normally set to 200. When I try with the options that you give below I get the following spammed in the syslog of the target FreeBSD box: Aug 30 19:17:25 warez /kernel: Limiting closed port RST response from 852 to 200 packets per second I find that I can't get any higher than --max-parallelism 3 before the target box starts to complain. So, I haven't dug into the algorithm that NMAP uses on SYN scans recently, but it must still be doing retransmits and must be agressive enough about retransmitting that it eventually gets a RST or SYN back from all the ports because I'm still getting the correct results. The exact logic would be interesting... On Thu, 29 Aug 2002, Lance Spitzner wrote: > Not sure if this is commonly known, however I wanted to share > something I've learned with nmap. As part of my job, I often > do a great deal of scanning of firewalls, or scanning through > firewalls. This can be VERY TIME consuming, as you get no > response for each probe, a full scan (all 65000+ ports) of a > firewall used to average me 3200 seconds. While teaching > a class we were able to DRAMATCALLY reduce this for TCP > scans to average 840 seconds. Using the following command line > options > > --max_rtt_timeout 50 --max-parallelism 100 > > By reducing rtt_timeout to 50, we DRAMATICALLY reduced the > time for scanning, however, this is when the target is only > 2 hops away, you may experience dropped packets if there > are more hops. I can say this with a high degree with confidence, > as we had 8 different systems probe all 65000+ TCP ports, > all averaging around 840-850 seconds per scan. By changing > the rtt_timeout to 10, we got the time down to 350+, but > you are really pushing it. Increasing the number of parrallel > scans beyond 100 seemed to have no improvement. > > Unfortunatelyl, UDP still took MUCH LONGER, averaging > 2000-3000 seconds perscan :-0 > > Just thought I would share this tidbit, for those of you > who have waited to firewall scans :) > > > -- > Lance Spitzner > http://www.honeynet.org > > > > > -------------------------------------------------- > For help using this (nmap-hackers) mailing list, send a blank email to > [email protected] . List run by ezmlm-idx (www.ezmlm.org). > > -------------------------------------------------- For help using this (nmap-hackers) mailing list, send a blank email to [email protected] . List run by ezmlm-idx (www.ezmlm.org).