Sometimes the best way to understand something is to see it in
action. This section includes examples of
Nmap used in (mostly) fictional yet
typical circumstances. Nmap newbies
should not expect to understand everything at once. This is simply a
broad overview of features that are described in depth in later
chapters. The “recipes” included throughout this book demonstrate many other common Nmap tasks for security auditors and network administrators.
Felix dutifully arrives at work on December 15th, although he
does not expect many structured tasks. The small San Francisco
penetration-testing firm he works for has been quiet lately due
to impending holidays. Felix spends business hours pursuing
his latest hobby of building powerful Wi-Fi antennas for wireless
assessments and war driving exploration. Nevertheless, Felix is
hoping for more business. Hacking has been his hobby and fascination
since a childhood spent learning everything he could about networking,
security, Unix, and phone systems. Occasionally his curiosity took
him too far, and Felix was almost swept up in the 1990 Operation
Sundevil prosecutions. Fortunately Felix emerged from adolescence
without a criminal record, while retaining his expert knowledge of
security weaknesses. As a professional, he is able to perform the
same types of network intrusions as before, but with the added benefit
of contractual immunity from prosecution and even a paycheck! Rather
than keeping his creative exploits secret, he can brag
about them to client management when presenting his reports. So Felix
was not disappointed when his boss interrupted his antenna soldering
to announce that the sales department finally closed a pen-testing
deal with the Avatar Online gaming company.
Avatar Online (AO) is a small company working to create the next
generation of massive multi-player online role-playing games
(MMORPGs). Their product, inspired by the Metaverse envisioned in
Neil Stevenson's Snow Crash, is fascinating but
still highly confidential. After witnessing the high-profile leak of Valve Software's upcoming game source code, AO quickly
hired the security consultants. Felix's task is to initiate an external (from outside
the firewall) vulnerability assessment while his partners work
on physical security, source code auditing, social engineering, and so
forth. Felix is permitted to exploit any vulnerabilities found.
The first step in a vulnerability assessment is network
discovery. This reconnaissance stage determines what IP address
ranges the target is using, what hosts are available, what services
those hosts are offering, general network topology details, and what
firewall/filtering policies are in effect.
Determining the IP ranges to scan would normally be an elaborate
process involving ARIN (or another geographical registry) lookups, DNS
queries and zone transfer attempts, various web sleuthing techniques,
and more. But in this case, Avatar Online explicitly specified what
networks they want tested: the corporate network on
6.209.24.0/24 and their production/DMZ systems residing on
6.207.0.0/22. Felix checks the ARIN IP allocation records anyway and
confirms that these IP ranges belong to AO[]. Felix subconsciously
decodes the CIDR notation[] and recognizes this as 1,280 IP addresses.
No problem.
Being the careful type, Felix first starts out with what is
known as an Nmap list scan (-sL
option). This
feature simply enumerates every IP address in the given target
netblock(s) and does a reverse-DNS lookup (unless -n
was specified) on each. One reason to do this first is stealth. The
names of the hosts can hint at potential vulnerabilities and allow for
a better understanding of the target network, all without raising alarm
bells[]. Felix is doing this for another reason—to
double-check that the IP ranges are correct. The systems
administrator who provided the IPs might have made a mistake, and
scanning the wrong company would be a disaster. The contract signed
with Avatar Online may act as a get-out-of-jail-free card for
penetrating their networks, but will not help if Felix accidentally
roots another company's server! The command he uses and an excerpt of
the results are shown in Example 1.1, “Nmap list scan against Avatar Online IP addresses”
Example 1.1. Nmap list scan against Avatar Online IP addresses
felix> nmap -sL 6.209.24.0/24 6.207.0.0/22
Starting nmap ( http://nmap.org )
Host 6.209.24.0 not scanned
Host fw.corp.avataronline.com (6.209.24.1) not scanned
Host dev2.corp.avataronline.com (6.209.24.2) not scanned
Host 6.209.24.3 not scanned
Host 6.209.24.4 not scanned
Host 6.209.24.5 not scanned
...
Host dhcp-21.corp.avataronline.com (6.209.24.21) not scanned
Host dhcp-22.corp.avataronline.com (6.209.24.22) not scanned
Host dhcp-23.corp.avataronline.com (6.209.24.23) not scanned
Host dhcp-24.corp.avataronline.com (6.209.24.24) not scanned
Host dhcp-25.corp.avataronline.com (6.209.24.25) not scanned
Host dhcp-26.corp.avataronline.com (6.209.24.26) not scanned
...
Host 6.207.0.0 not scanned
Host gw.avataronline.com (6.207.0.1) not scanned
Host ns1.avataronline.com (6.207.0.2) not scanned
Host ns2.avataronline.com (6.207.0.3) not scanned
Host ftp.avataronline.com (6.207.0.4) not scanned
Host 6.207.0.5 not scanned
Host 6.207.0.6 not scanned
Host www.avataronline.com (6.207.0.7) not scanned
Host 6.207.0.8 not scanned
...
Host cluster-c120.avataronline.com (6.207.2.120) not scanned
Host cluster-c121.avataronline.com (6.207.2.121) not scanned
Host cluster-c122.avataronline.com (6.207.2.122) not scanned
Host cluster-c123.avataronline.com (6.207.2.123) not scanned
Host cluster-c124.avataronline.com (6.207.2.124) not scanned
...
Host 6.207.3.253 not scanned
Host 6.207.3.254 not scanned
Host 6.207.3.255 not scanned
Nmap finished: 1280 IP addresses scanned in 331 seconds
felix>
Reading over the results, Felix finds that all of the machines
with reverse-DNS entries resolve to Avatar Online. No other
businesses seem to share the IP space. Moreover, these results
give Felix a rough idea of how many machines are in use and a good
idea of what many are used for. He is now ready to get a bit more
intrusive and try a port scan. He uses Nmap features that try to
determine the application and version number of each service listening
on the network. He also requests that Nmap try to guess the
remote operating system via a series of low-level TCP/IP probes known
as OS fingerprinting.
This sort of scan is not at
all stealthy, but that does not concern Felix. He is interested
in whether the administrators of AO even notice these blatant scans. After a
bit of consideration, Felix settles on the following command:
nmap -sS -p- -PS22,80,113,33334 -PA80,113,21000 -PU19000 -PE -A -T4 -oA avatartcpscan-121503 6.209.24.0/24 6.207.0.0/22
These options are described in later chapters, but here is a
quick summary of them.
-sS
Enables the efficient TCP port scanning technique
known as SYN scan. Felix would have added a U at the end if he also
wanted to do a UDP scan, but he is saving that for later. SYN scan is
the default scan type, but stating it explicitly does not
hurt.
-p-
Requests that Nmap scan every port
from 1-65535. The default is to scan only ports 1 through 1024, plus about 600
others explicitly mentioned in the nmap-services
database. This option format is simply a short cut for -p1-65535
. He
could have specified -p0-65535
if he wanted to scan the rather
illegitimate port zero as well. The -p
option has a
very flexible syntax, even allowing the specification of a differing
set of UDP and TCP ports.
-PS22,80,113,33334 -PA80,113,21000 -PU19000 -PE
These are all ping types used in
combination to determine whether a host is really available and avoid
wasting a lot of time scanning IP addresses that are not in use. This
particular incantation sends a TCP SYN packet to ports 22, 80, 113,
and 33334; a TCP ACK packet to ports 80, 113, and 21000; a UDP packet
to port 19000; and a normal ICMP echo request packet. If Nmap
receives a response from the target host itself to any of these
probes, it considers the host to be up and available for scanning.
This is more extensive than the Nmap default, which simply sends an
echo request and an ACK packet to port 80. In a pen-testing situation,
you often want to scan every host even if they do not seem to be up.
After all, they could just be heavily filtered in such a way that the
probes you selected are ignored but some other obscure port may be
available. To scan every IP whether it shows an available host or
not, specify the -PN
option instead of all of the above.
Felix starts such a scan in the background, though it may take a day
to complete.
-A
This shortcut option turns on Advanced and Aggressive features such as OS and service
detection. At the time of this writing it is equivalent to
-sV
-O
--traceroute
(version detection, remote OS detection, and traceroute), though more features may
be added to -A
later.
-T4
Adjusts timing to the aggressive
level (#4 of 5).
This is the same as specifying -T aggressive
, but is easier to type and spell. In general, the -T4
option is recommended if the connection between you and the target networks are faster than modem dialups.
-oA avatartcpscan-121503
Outputs results in every format (normal, XML, grepable) to files named avatartcpscan-121503.extension
where the extensions are .nmap, .xml, and .gnmap respectively. All of the output formats include the start date and time, but Felix likes to note the date explicitly in the filename. Normal output and errors are still sent to stdout[] as well.
6.209.24.0/24 6.207.0.0/22
These are the Avatar Online netblocks discussed above.
They are given in CIDR notation, but Nmap allows them to be specified
in many other formats. For example, 6.209.24.0/24
could instead be specified as 6.209.24.0-255
.
Since such a comprehensive scan against more than a thousand IP addresses
could take a while, Felix simply starts it executing and resumes work
on his Yagi antenna. A couple hours later he notices that it has
finished and takes a peek at the results. Example 1.2, “Nmap results against an AO firewall” shows one of the machines discovered.
Example 1.2. Nmap results against an AO firewall
Interesting ports on fw.corp.avataronline.com (6.209.24.1):
(The 65530 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.7.1p2 (protocol 1.99)
53/tcp open domain ISC BIND 9.2.1
110/tcp open pop3 Courier pop3d
113/tcp closed auth
143/tcp open imap Courier Imap 1.6.X - 1.7.X
3128/tcp open http-proxy Squid webproxy 2.2.STABLE5
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.5.20
Uptime 3.134 days
To the trained eye, this conveys substantial information about
AO's security posture. Felix first notes the reverse DNS
name—this machine is apparently meant to be a firewall for their
corporate network. The next line is important, but all too often
ignored. It states that the vast majority of the ports on this
machine are in the filtered
state. This means that Nmap is unable
to reach the port because it is blocked by firewall rules. The fact
that all ports except for a few chosen ones are in this state is a
sign of security competence. Deny-by-default is a security mantra for
good reasons—it means that even if someone accidentally left SunRPC
(port 111) open on this machine, the firewall rules would prevent
attackers from communicating with it.
Felix then looks at every port line in turn. The first port is
Secure Shell (OpenSSH). Version 3.7.1p2 is recent. The
administrators probably upgraded it because of the potentially
exploitable buffer management bugs affecting earlier versions. This
is another hint that the administrators know what they are doing. A
truly paranoid sysadmin would only allow SSH connections from certain
trusted IP addresses, but one can argue for open access in case the
administrator needs emergency access while far from home. Security
often involves trade-offs, and this one may be justifiable. Felix
makes a note to try his brute force password cracker and especially
his private timing-based SSH user enumeration tool against the
server.
Felix is not so charitable about port 53. It is running ISC
bind, which has a long history of remotely exploitable security holes.
Visit the BIND security page
for further details. BIND 9.2.1 even has a potentially exploitable
buffer overflow, although the default build is not vulnerable. Felix
checks and finds that this server is not vulnerable to the libbind
issue, but that is beside the point. This server almost certainly
should not be running an externally-accessible nameserver. A firewall
should only run the bare essentials to minimize the risk of a
disastrous compromise. Besides, this server is not authoritative for
any domains—the real nameservers are on the production network. An
administrator probably only meant for clients within the firewall to
contact this nameserver, but he did not bother locking it down to only
the internal interface. Felix will later try to gather important
information from this unnecessary server using zone transfer requests
and intrusive queries. He may attempt cache poisoning as well. By
spoofing the IP of windowsupdate.microsoft.com
or
another important download server, Felix may be able to trick
unsuspecting internal client users into running a trojan-horse program
that provides him with full network access behind the firewall.
The next two open ports are 110 (pop3) and 143 (imap). Note
that 113 (auth) between them is closed
instead of open
. Pop3 and imap are mail retrieval
services which, like Named, have no legitimate place on this server.
They are also a security risk in that they generally transfer the mail
and (even worse) authentication credentials unencrypted. Users
should probably VPN in and check their mail from an internal server.
These ports could also be wrapped in SSL encryption. Nmap would have
then listed the services as ssl/pop3
and ssl/imap
. Felix will try
his user enumeration and password guessing attacks on these services,
which will probably be much more effective than against SSH.
The final open port is a Squid proxy. This is another service
that may have been intended for internal client use and should not be
accessible from the outside (and particularly not on the firewall).
Felix's initially positive opinion of the AO security administrators
drops further. Felix will test whether he can abuse this proxy to
connect to other sites on the Internet. Spammers and malicious
hackers often use proxies in this way to hide their tracks. Even more
critical, Felix will try to proxy his way into the
internal network. This common attack is how
Adrian Lamo
broke into the New York Times internal network in 2002. Lamo was
caught after he called reporters to brag about his exploits against
the NY Times and other companies in detail
The following lines disclose that this is a Linux box, which is
valuable information when attempting exploitation. The low 3-day
uptime was detected during OS fingerprinting by sending several probes
for the TCP timestamp option value and extrapolating the line back to
zero.
Felix then examines the Nmap output for another machine, as
shown in Example 1.3, “Another interesting AO machine”
Example 1.3. Another interesting AO machine
Interesting ports on dhcp-23.corp.avataronline.com (6.209.24.23):
(The 65526 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
1002/tcp open windows-icfw?
1025/tcp open msrpc Microsoft Windows msrpc
16552/tcp open unknown
Device type: general purpose
Running: Microsoft Windows NT/2K/XP
OS details: Microsoft Windows XP Professional RC1+ through final release
Felix smiles when he spies this Windows XP box on the Network.
Thanks to a recent spate of MS RPC vulnerabilities, those machines are
often trivial to compromise. The second line shows that the default
state is closed
, meaning the firewall does not have
the same deny-by-default policy for this machine as for itself.
Instead they tried to specifically block the Windows ports they
consider dangerous on 135-139. This filter is woefully inadequate, as
MS exports MS RPC functionality on many other ports in Windows XP.
TCP ports 445 and 1025 are two examples on this scan. While Nmap
failed to recognize 16552, Felix has seen this pattern enough to know
that it is probably the MS Messenger Service. If AO had been using
deny-by-default filtering, port 16552 would not be accessible in the
first place. Looking through the results page, Felix sees several
other Windows machines on this DHCP network. Felix cannot wait to try
his favorite DCOM RPC exploit against them. It was written by HD
Moore and is available at http://www.metasploit.com/tools/dcom.c If that fails, there
are a couple newer MS RPC vulnerabilities he will try.
Felix continues poring over the results for vulnerabilities he
can leverage to compromise the network. On the production network, he
sees that gw.avataronline.com
is a Cisco router that also acts as a
rudimentary firewall for the systems. They fall into the trap of only
blocking privileged ports (those under 1024), which leaves a bunch
of vulnerable SunRPC and other services accessible on that network.
The machines with names like clust-*
each have dozens of ports open
that Nmap does not recognize. They are probably custom daemons
running the AO game engine. www.avataronline.com
is a Linux box with an open Apache server on the
http and https ports. Unfortunately, it is linked with an exploitable
version of the OpenSSL library. Oops! Before the sun sets, Felix has
gained privileged access to hosts on both the corporate and production
networks.
As Felix has demonstrated, Nmap is frequently used by
security auditors and network administrators to help locate
vulnerabilities on client/corporate networks. Subsequent chapters
describe the techniques used by Felix, as well as many other Nmap
features, in much greater detail.
Trinity is in quite a pickle! Having discovered that the world
we take for granted is really a virtual “Matrix” run by machine
overlords, Trinity decides to fight back and free the human race from
this mental slavery. Making matters worse, her underground colony of
freed humans (Zion) is under attack by 250,000 powerful alien
sentinels. Her only hope involves deactivating the emergency power
system for 27 city blocks in less than 5 minutes. The previous team
died trying. In life's bleakest moments when all hope seems to be
lost, what should you turn to? Nmap, of course! But not quite yet.
She first must defeat the perimeter security, which on
many networks involves firewalls and intrusion detection systems
(IDS). She is well aware of advanced techniques for circumventing
these devices (covered later in this book). Unfortunately, the
emergency power system administrators knew better than to connect such a
critical system to the Internet, even indirectly. No amount of source
routing or IP ID spoofed scanning will help Trinity overcome this “air
gap” security. Thinking fast, she devises a clever plan that involves jumping her
motorcycle off the rooftop of a nearby building, landing on the power
station guard post, and then beating up all of the security guards.
This advanced technique is not covered in any physical security
manual, but proved highly effective. This demonstrates how clever hackers research and devise their own attacks, rather than always utilizing the script-kiddie approach of canned exploits.
Trinity fights her way to the computer room and sits down at a
terminal. She quickly determines that the network is using the
10.0.0.0/8 private network (RFC 1918). A ping to the network
address generates responses from dozens of machines. An Nmap ping
scan would have provided a more comprehensive list of available
machines, but using the broadcast technique saved precious seconds.
Then she whips out Nmap[]. The terminal has version 2.54BETA25
installed. This version is ancient (2001) and less efficient than
newer releases, but Trinity had no time to install a better version
from the future. This job will not take long anyway. She runs the
command nmap -v -sS -O 10.2.1.3. This executes a TCP SYN scan
and OS detection against 10.2.1.3 and provides verbose output. The
host appears to be a security disaster—AIX 3.2 with well over a
dozen ports open. Unfortunately, this is not the machine she needs to
compromise. So she runs the same command against 10.2.2.2. This time
the target OS is unrecognized (she should have upgraded Nmap!) and
only has port 22 open. This is the Secure Shell encrypted
administration service. As any sexy PVC-clad hacker goddess knows,
many SSH servers around that time (2001) had an exploitable
vulnerability in the CRC32 compensation attack detector. Trinity
whips out an all-assembly-code exploit and utilizes it to change the root password of the
target box to Z10N0101
. Trinity uses much more secure passwords
under normal circumstances. She logs in as root and issues a command
to disable the emergency backup power system for 27 city blocks,
finishing just in time! Here are some shots of the action—squint
just right and you should be able to read the text.
In addition, a terminal-view
video showing the whole hack is available on the Internet. At least it will
be until the MPAA finds out and sends sentinels or lawyers after the webmasters.
This story differs from the previous ones in that it is actually
true. Written by frequent Nmap user and contributor MadHat, it
describes how he enhanced and customized Nmap for daily use in a large
enterprise. In true open source spirit, he has released these valuable
scripts on
his Web site IP addresses have been changed to protect the
corporate identity. The remainder of this section is in his own words.
After spending the past couple of decades learning computers and working
my way up from tech support through sysadmin and into my dream job of
Information Security Officer for a major Internet company, I found
myself with a problem. I was handed the sole responsibility of
security monitoring for our entire IP space. This was almost 50,000
hosts worldwide when I started several years ago, and it has doubled
since then.
Scanning all of these machines for potential vulnerabilities as
part of monthly or quarterly assessments would be tough enough, but
management wanted it done daily. Attackers will not wait a week or
month to exploit a newly exposed vulnerability, so I cannot wait that
long either.
Looking around for tools, I quickly chose Nmap as my port
scanner. It is widely considered to be the best scanner, and I had already
been using it for years to troubleshoot networks and test security.
Next I needed software to aggregate Nmap output and print
differences between runs. I considered several existing tools, such
as James Levine's (now defunct) NDiff, and HD Moore's
Nlog While
these are great tools, they did not monitor changes in the way I
desired. I had to know whenever a router or firewall access control list
was misconfigured or a host was publicly sharing inappropriate
content. I also worried about the scalability of these other solutions,
so I decided to tackle the problem myself.
The first issue to come up was speed. Our networks are located
worldwide, yet I was provided with only a single U.S.-based host to do
the scanning. In many cases, firewalls between the sites slowed the
scanning down significantly. Scanning all 100,000 hosts took over 30
hours, which is unacceptable for a daily scan. So I wrote a script
called nmap-wrapper which runs dozens of
Nmap processes in parallel, reducing the scan time to fifteen hours,
even including OS detection.
The next problem was dealing with so much data. A SQL
database seemed like the best approach for scalability and data-mining
reasons, but I had to abandon that idea due to time pressures. A
future version may add this support. Instead, I used a flat file to
store the results of each class C address range for each day. The
most powerful and extensible way to parse and store this information was
the Nmap XML format, but I chose the “grepable” (-oG
option)
format because it is so easy to parse from simple scripts. Per-host
timestamps are also stored for reporting purposes. These have proven
quite helpful when administrators try to blame machine or service
crashes on the scanner. They cannot credibly claim a service crash at 7:12AM
when I have proof that the scan ran at 9:45AM.
The describe process produces copious data, with no convenient
access method. The standard Unix diff tool is not
smart enough to report only the changes I care about, so I wrote a
Perl script named nmap-diff to provide
daily change reports. A typical output report is shown in Example 1.4, “Nmap-diff typical output”
Example 1.4. Nmap-diff typical output
> nmap-diff.pl -c3
5 IPs showed changes
10.12.4.8 (ftp-box.foocompany.biz)
21/tcp open ftp
80/tcp open http
443/tcp open https
1027/tcp open IIS
+ 1029/tcp open ms-lsa
38292/tcp open landesk-cba
OS: Microsoft Windows Millennium Edition (Me)
Windows 2000 Professional or Advanced Server
or Windows XP
10.16.234.3 (media.foocompany.biz)
80/tcp open http
+ 554/tcp open rtsp
+ 7070/tcp open realserver
192.168.10.186 (testbox.foocompany.biz)
+ 8082/tcp open blackice-alerts
OS: Linux Kernel 2.4.0 - 2.5.20
172.24.12.58 (mtafoocompany.biz)
+ 25/tcp open smtp
OS: FreeBSD 4.3 - 4.4PRERELEASE
172.23.76.22 (media2.foocorp.biz)
80/tcp open http
1027/tcp open IIS
+ 1040/tcp open netsaint
1755/tcp open wms
3372/tcp open msdtc
6666/tcp open irc-serv
7007/tcp open afs3-bos
OS: Microsoft Windows Millennium Edition (Me)
Windows 2000 Professional or Advanced Server
or Windows XP
Management and staff were impressed when I demonstrated this new system
at an internal company security symposium. But instead of allowing me
to rest on my laurels, they began asking for new features. They
wanted counts of mail and web servers, growth estimates, and more.
This data was all available from the scans, but was difficult to
access. So I created yet another Perl script,
nmap-report, which made querying the data
much easier. It takes specifications such as open
ports or operating systems and finds all the systems that matched on a
given day.
One problem with this approach to security monitoring is that
employees do not always place services on their IANA-registered
official ports. For example, they might put a web server on port 22
(SSH) or vice versa. Just as I was debating how to address this
problem, Nmap came out with an advanced service and version detection
system (see Chapter 7, Service and Application Version Detection). nmap-report now
has a rescan feature that uses version scanning to report the
true services rather than guessing based on port number. I hope to
further integrate version detection in future versions. Example 1.5, “Nmap-report execution” shows nmap-report
listing FTP servers.
Example 1.5. Nmap-report execution
> nmap-report -p21 -rV
[...]
172.21.199.76 (ftp1.foocorp.biz)
21/tcp open ssl|ftp Serv-U ftpd 4.0
192.168.12.56 (ftp2.foocorp.biz)
21/tcp open ftp NcFTPd
192.168.13.130 (dropbox.foocorp.biz)
21/tcp open ftp WU-FTPD 6.00LS
While being far from perfect, these scripts have proven themselves
quite valuable at monitoring large networks for security-impacting changes.
Since Nmap itself is open source, it only seemed fair to release my
scripts to the public as well. I have made them freely available at
http://www.unspecific.com/nmap