Re: Advice on Fastest NMAP Scan
From: Ghaith Nasrawi (libero_at_aucegypt.edu)
To: Fyodor <email@example.com> Date: Fri, 29 Oct 2004 02:44:13 +0000
when I try nmap scanning within Nessus, it just take ages to finish the
initial scanning process. I think nessus developers should make of the
new modifications to nmap in order to speed up the whole process of
assessing vuln. targets.
On Tue, 2004-10-26 at 23:05, Fyodor wrote:
> On Tue, Oct 26, 2004 at 09:58:50AM -0500, Mogren, Jack L. wrote:
> > Here's what I've come up with so far.
> > nmap -O -T4 -PE -F --osscan_limit -oX /home/security/test.xml -iL /home/security/ip_addresses.txt
> > Any comments or suggestions?
> First off, make sure that you are using Nmap 3.75. Nmap 3.70 included
> a complete port scan engine rewrite for better performance (among
> other advantages) and then 3.75 tweaked it to be even better. You can
> obtain Nmap 3.75 from http://www.insecure.org/nmap .
> Since you know your network, you may be able to help Nmap by setting a
> maximum retransmission timeout. Are you scanning over multiple
> continents, or just a local network? If you can assume that responses
> won't take more than 100ms, add --max_rtt_timeout 100 for a big speed
> boost. Also, use a large host group such as --min_hostgroup 128 so
> that many hosts are scanned in parallel. Play with the numbers a bit
> to figure out what works best on your particular network. You could
> also consider a custom nmap-services file with just a couple hundred
> of the most common TCP ports. Even the -F option still scans more
> than 1200 ports by default.
> I would be interested to hear how it goes. If you find that it is too
> slow for your needs, let me know. I am working on a performance
> chapter of my upcoming O'Reilly Nmap book, so I have studied several
> such large network situations. A class B and several class C's
> shouldn't be any problem at all for regular scanning. Your "entire
> private address space" make take a while, depending on your setup.
> Scanning 10.0.0.0/8 is 16 million IPs, so don't expect it to complete
> during lunch. Some of the tools that claim incredibly speeds don't
> even handle retransmissions or other reliability requirements.
> I hope this helps,