Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Nmap Hackers: Re: Improving nmap performance

Re: Improving nmap performance

From: Lamont Granquist <lamont_at_scriptkiddie.org>
Date: Fri, 30 Aug 2002 19:26:24 -0700 (PDT)

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
> nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
>
>

--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to
nmap-hackers-help_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Aug 31 2002

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]