System slowdown with multiple nmaps

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!
TIA.

Mike

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

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)

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...

"Mr. Boy" <mrboy77@gmail.com> wrote in news:1121469077.843978.229280
@g44g2000cwa.googlegroups.com:

> 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 ?

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

> 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

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
closed).

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

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

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

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

Cheers,

Mike