Nmap Development mailing list archives

Re: Nmap scans destoryes configuration on terminal servers(Serial to TCP converts - NIMs)


From: Brandon Enright <bmenrigh () ucsd edu>
Date: Sat, 4 Oct 2008 05:29:59 +0000

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

On Fri, 3 Oct 2008 21:02:11 -0700 or thereabouts "Ahsan Shahzad Mir"
<ahsanmir () gmail com> wrote:

Hi,


I think this is a fairly issue. I was running nmap scan using the
latest 4.76 release using the standard nmap  -A option to get the
network map of all the devices in a couple of my subnets. After
running the scan I realized that most of my embedded terminal
servers(serial to TCP/IP converters) which are connected to Alarm
panel and other devices have lost their original configuration. This
resulted in complete loss of signal from these panels. I realize that
the Network interface module manufactures are at fault at creating
faulty hardware but I thought I should warn people not running nmap
where they are terminal servers.



Best regards,

Ahsan


Ahsan,

This is shamefully common for many embedded networking devices.  Really
there are 3 aspects of a "nmap -A ..." scan that can cause devices to
hang.  In relative order of likelihood:

* Service version or script scanning (-sV or -sC)
* Operating system fingerprinting (-O)
* The actual port scan (-sS)

In the vast majority of the cases where a device crashes the culprit is
a poorly written service dieing when hit with the probes from a service
scan.  It is getting pretty rare that the OS fingerprinting kills the
device and even more rare that a SYN flood kills it.

The most common devices that we see crash when hit with a -A scan
include:

* Network printers
* Terminal servers
* NAS boxes (network-attached-storage)
* Mainframes (only when high-performance sockets are deployed)
* Network UPS/Power strips
* Some X11 servers
* Some configurations of Microsoft SQL Server 2000/2005
* Old IOS/JUNOS management/loopback interfaces

Most of the time the failure is just a permanent hanging of the
device.  For the networked power strips though, entire racks have been
known to power off when the device crashes.

Our organization takes the approach that if we can scan and crash it,
so can the bad guys.  Our solution is to use RFC1918 address space for
all sensitive devices like those above.  We're fond of the
172.16.0.0/12 space but depending on your environment, 10.* or other
space may be best.

If using different, isolated address space isn't an option for you, if
you replace "-A" with "-O" you probably won't crash any devices.  If
you really need to get the service fingerprints (we do) then you'll
need to maintain an exclude list that you can feed Nmap with the
"--excludefile" option.  I have to maintain a fairly extensive exclude
list for our organization.

Brandon


PS: --excludefile is the only non-hyphenated two-word option that Nmap
has.  It would be nice to see it changed to --exclude-file which is
much more natural for me and more consistent with the rest of Nmap.

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

iEYEARECAAYFAkjm/2sACgkQqaGPzAsl94LYDwCfan/c+Yk5w+o4QZyLzNStJY7R
/jAAoKFjQUBO+SZ4PbHADc+5ATGbDyp4
=l1rP
-----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: