Nmap Development mailing list archives

Nmap & Stateful Firewalls


From: "Ron Dembo" <rdembo () gmail com>
Date: Fri, 16 Jan 2009 15:20:49 -0500

Hello.

Short story:  I was wondering if there's a way to hard limit the connections
that a Nmap scan makes so that it won't completely fill a stateful
firewall.  I've read the Nmap man page and documentation and none of the
performance options I see given there will guarantee that Nmap will only
open up a max of X number of connections at any given time.  I've tried
timeouts, delays between packets, etc to no avail.  Does anyone have any
suggestions?

Long story:  I have Nagios monitoring over 100+ hosts and I wrote a perl
script to compare what services are being monitored by Nagios and what ports
Nmap finds open on those hosts.  Any services not being monitored, new or
old, are emailed to me in a report.  Nagios and nmap are running on the same
machine  and have to pass through an OpenBSD machine running PF.  If the
Nmap scans fill the table, it creates a denial of service for Nagios as it
can't make connections to check on services.  As I'm checking all ports on
these hosts, I need to run the scans in parallel in order to cut down on the
amount of time they take.  (I'd like this script to run every week.)  I've
played with the performance options, and while I have seen improvement, I'd
like to cron this thing and know that no matter what happens with the
network or the scans, Nagios will always have entries it can use.  (False
pages suck.)  Jacking up the state limit won't solve the problem, it will
just make it less likely; same thing with reducing the number of hosts
scanned in parallel.   Any connection manipulation at the firewall will be
blind and will likely greatly decrease the accuracy of the scans and/or
interfere with Nagios.  If anyone has any suggestions, I'd be grateful to
hear them.   Thanks.

Regards,

Ron Dembo

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: