System slowdown with multiple nmaps

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi all,

I've a bizarre problem (well... at least it was unexpected).
We need to run multiple instances of nmap on small network ranges, and we
found that after having 5 or 6 at the same time the system starts to
slowdown a lot. With 25-30 it kind of unusable.
The servers used are quite new Xeon based boxes (2+GHz), with SCSI disk and
plenty of RAM.
I tried to Google some information to help with the problem, but I only
found a lot of references on how to optimize 1 or 2 nmaps for big network
scans, that's exactly the opposite as my case.
The typical long-lasting scan is something like:

nmap -sT -P0 -p1-65535 -O {target network}

Any ideas and suggestions are welcome!


Re: System slowdown with multiple nmaps

Quoted text here. Click to load it

Id think that -T switch could ease up the load on your machine. The man
page says following:

-T <Paranoid|Sneaky|Polite|Normal|Aggressive|Insane>

These  are  canned timing policies for conveniently expressing your
priorities to Nmap.  Paranoid mode scans very slowly in the hopes of
avoiding detection by IDS systems.  It serializes all scans (no parallel
 scanning)  and  generally  waits  at least  5  minutes  between
sending  packets.   Sneaky is similar, except it only waits 15 seconds
between sending packets. Polite is meant to ease load on the network and
reduce the chances of crashing machines.   It  serializes  the  probes
and waits  at  least  0.4 seconds between them.

So, if you have multiple scans, without the -t switch, all the scans are
run in parallel thus having multiple threads running and if you have
multiple nmaps running scans you have X*Y amount of threads (where X is
amount of nmap processes and Y the number of threads executed in parallel).

So, the best bet would be running the scans with -T Polite (or -T2)

Re: System slowdown with multiple nmaps

i agree with Jani about your Nmap Timings, and also you should refine
your scans, or define what exactly you are looking for. How come you
want to know OS with IP finger prints scanning the whole ports range ?

other thing change that -p 1-65535 for a: -p- (dash p dash), this
instructs nmap to scan the whole thing,... if you want  to know which
OS is there try to scan a well known serviceable port

if you want to know which OS is there also use -sV (which tells which
version is running on the port).

Explain a little better your ideas to help you improve that search...

See ya...

Re: System slowdown with multiple nmaps

Quoted text here. Click to load it

Thanks both for the suggestion on the timings. I left a couple nmaps
running with -T2, will check the results next week.

Quoted text here. Click to load it

There is no "well known serviceable port". What we scan is different each
time, and this is one of the reasons to scan all ports.
Doing the -O there is just a way to ensure we get the open/closed port
pair, IF there're any (it can be that all 65535 ports are filtered or
Quoted text here. Click to load it

We'll implement that on a reduced scan (-sV -F).
Probably -O will go along -F as well, instead of at the complete scan.
Quoted text here. Click to load it

Sorry for not being more specific before. Hope it's a bit more clear now.

BTW... it seems that the slowdown problem was caused by a bizarre combo
of circumstances we are solving now. For a start, a former ipchains
firewall was converted to iptables, that's STATEFUL, so ip_conntrack was
trying to create 1 entry for each nmap probe ;-P



Site Timeline