Nmap Development mailing list archives

Re: Nmap & Stateful Firewalls


From: Brandon Enright <bmenrigh () ucsd edu>
Date: Fri, 16 Jan 2009 22:37:10 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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


Ron,

Here are a few thoughts about this topic and stateful firewalls in
general:

Ideally you should never use Nmap through a stateful firewall.  I've
never come across a stateful firewall that could reasonably handle full
network scans with Nmap.

Also, if Nmap scanning breaks your firewall to the point that services
aren't reliably offered than you've set yourself up to be DoS'd by
anyone on the Internet.

Now obviously if you are asking this question you don't have a choice
about scanning through a stateful firewall.  Unfortunately there is so
much variety in how stateful firewalls work that there isn't going to
be a recipe for success across the whole vendorscape.

One such stateful firewall that I'm familiar with tries to keep
connection state for 4 hours.  Suppose it has a 10 million session
tracking limit.  Assuming each SYN Nmap sends to a new target host:port
pair is a new session, you can send at about 700 packets per second and
stay at the 4 hour session tracking limit.

Now, if you can cause those SYN sessions to go away faster you
shouldn't need to worry about a state tracking limit.  Most stateful
firewalls will tear down a tracked session if they see a valid RST for
that session.  This means than any "closed" port you scan should tear
down that session.  Any "filtered" port is a session that won't ever be
torn down.  If you are using Nmap from a non-firewalled box then the
host OS should respond with a RST to the SYN+ACK of any "open" port you
scan.  Clearly scanning "filtered" ports is the primary source of
zombie sessions.  If you can eliminate the number of down hosts and
filtered ports you scan you should really help reduce wasted sessions.

Finally, some stateful firewalls really take session tracking to the
extreme.  For example, a Cisco Firewall Service Module (FWSM) requires
all traffic to be either establishing a new session, part of an
existing session, or related to an existing session.  That means even
with a rule like "allow any any" right at the top of a firewall context
will block lots of Nmap packets.  One of Nmap's default pings is to
send ACK packets (-PA).  All stray ACK packets are dropped even with
what appears to be a firewall exception.  This makes almost all scans
other than SYN scans (-PS and -sS) useless.  Of course this also harms
OS fingerprinting (-O) because some probes may be dropped.

So in short, I think you need to play with how you use Nmap and how you
have your stateful firewalls setup to find the "best" combination
config adjustment and scanning adjustment to make Nmap work in your
environment.

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAklxDBwACgkQqaGPzAsl94IRdQCeMYfrXCU+a1HearOTwiO/b1PC
DkoAn0vuUn/LAiI1VhaHdwH9tXcXzXI1
=2WqM
-----END PGP SIGNATURE-----

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


Current thread: