Nmap Security Scanner
Ref Guide
Security Lists
Security Tools
Site News
Advertising
About/Contact
Credits
Sponsors
|

 |
Intro |
Reference Guide |
Book |
Install Guide |
Download |
Changelog |
Zenmap GUI |
Docs |
Bug Reports |
OS Detection |
Propaganda |
Related Projects |
In the Movies |
In the News |
|
 |
As with almost all other Nmap capabilities, output behavior is
controlled by command-line flags. These flags are grouped by category
and described in the following sections. The most fundamental output control is designating the format(s)
of output you would like. Nmap offers five types, as summarized in
the following list and fully described in later sections. Output formats supported by Nmap - Interactive output
This is the output that Nmap sends to the standard
output stream (stdout) by default. So it has no special
command-line option. Interactive mode caters to human users reading the results
directly and it is characterized by a table of interesting ports that
is shown in dozens of examples throughout this book. - Normal output (
-oN ) This is very similar to interactive output, and is
sent to the file you choose. It does differ from interactive output in
several ways, which derive from the expectation that this output will
be analyzed after the scan completes rather than interactively. So
interactive output includes messages (depending on
verbosity level specified with -v ) such as scan
completion time estimates and open port alerts. Normal output omits
those as unnecessary once the scan completes and the final interesting
ports table is printed. This output type prints the nmap command-line
used and execution time and date on its first line. - XML output (
-oX ) XML offers a stable format that is easily parsed by
software. Free XML parsers are available for all major computer
languages, including C/C++, Perl, Python, and Java. In almost all
cases that a non-trivial application interfaces with Nmap, XML is the preferred format. This chapter also discusses
how XML results can be transformed into other formats, such as
HTML reports and database tables. - Grepable output (
-oG ) This simple format is easy to manipulate on the
command line with simple Unix tools such as grep, awk,
cut, and diff. Each host is listed on one line, with the tab, slash,
and comma characters used to delimit output fields. While this can be
handy for quickly grokking results, the XML format is preferred for
more significant tasks as it is more stable and
contains more information. - sCRiPt KiDDi3 0utPU+ (
-oS ) This format is provided for the l33t haXXorZ!
While interactive output is the default and has no associated
command-line options, the other four format options use the same
syntax. They take one argument, which is the filename that results
should be stored in. Multiple formats may be specified, but each
format may only be specified once. For example, you may wish to save
normal output for your own review while saving XML of the same scan
for programmatic analysis. You might do this with the options
-oX myscan.xml -oN myscan.nmap . While this chapter
uses the simple names like myscan.xml for brevity,
more descriptive names are generally recommended. The names chosen
are a matter of personal preference, though I use long ones that
incorporate the scan date and a word or two describing the scan, placed
in a directory named after the company I'm scanning. As a
convenience, you may specify -oA
basename to store scan results in
normal, XML, and grepable formats at once. They are stored in
basename .nmap,
basename .xml, and
basename .gnmap, respectively. As with most
programs, you can prefix the filenames with a directory path, such as
~/nmaplogs/foocorp/ on Unix or
c:\hacking\sco on Windows. While these options save results to files, Nmap still prints
interactive output to stdout as usual. For example, the command
nmap -oX myscan.xml target prints XML to
myscan.xml and fills standard output with the same interactive results it would have printed if -oX
wasn't specified at all. You can change this by passing a hyphen
character as the argument to one of the format types. This causes
Nmap to deactivate interactive output, and instead print
results in the format you specified to the standard output stream. So the
command nmap -oX - target will send only XML output to
stdout. Serious errors may still be printed to the normal error
stream, stderr. When you specify a filename to an output format flag such as
-oN , that file is overwritten by default. If you
prefer to keep the existing content of the file and append the new
results, specify the --append-output option. All
output filenames specified in that Nmap execution will then be
appended to rather than clobbered. This doesn't work well for XML
(-oX ) scan data as the resultant file generally won't
parse properly until you fix it up by hand. Unlike some Nmap arguments, the space between the logfile option
flag (such as -oX ) and the filename or hyphen is
mandatory. If you omit the flags and give arguments such as
-oG- or -oXscan.xml , a backwards
compatibility feature of Nmap will cause the creation of
normal format output files named
G- and Xscan.xml
respectively. Controlling Verbosity of OutputAfter deciding which format(s) you wish results to be saved in, you
can decide how detailed those results should be. The first
-v option enables verbosity with a level of one.
Specify -v twice for a slightly greater effect.
Verbosity levels greater than two aren't useful. Most changes only
effect interactive output, and some also affect normal and script kiddie
output. The other output types are meant to be processed by machines,
so Nmap can give substantial detail by default in those formats
without fatiguing a human user. However, there are a few
changes in other modes where output size can be reduced substantially
by omitting some detail. For example, a comment line in the grepable
output that provides a list of all ports scanned is only printed in
verbose mode because it can be quite long. The following list
describes the major changes you get with at least one
-v option. - Scan completion time estimates
On scans that take more than a minute or two, you
will see occasional updates like this in interactive output mode:
SYN Stealth Scan Timing: About 30.01% done; ETC: 16:04 (0:01:09 remaining)
New updates are given if
the estimates change significantly. All port scanning techniques
except for idle scan and FTP bounce scan support completion time estimation, and so does
version scanning. - Open ports reported when discovered
When verbosity is enabled, open ports are printed in
interactive mode as
they are discovered. They are still
reported in the final interesting ports table as well. This allows
users to begin investigating open ports before Nmap even completes.
Open port alerts look like this:
Discovered open port 53/tcp on 205.217.153.62
- Additional warnings
Nmap always prints warnings about obvious mistakes and critical
problems. That standard is lowered when
verbosity is enabled, allowing more warnings to be printed. There
are dozens of these warnings, covering topics from targets experiencing excessive
drops or extraordinarily long latency, to ports which respond to probes in
unexpected ways. Rate limiting prevents these warnings from
flooding the screen. - Additional notes
Nmap prints many extra informational notes when in
verbose mode. For example, it prints out the time when each port
scan is started along with the number of hosts and ports scanned.
It later prints out a concluding line disclosing how long the scan
took and briefly summarizing the results. - Extra OS detection information
With verbosity, results of the TCP ISN and IP ID
sequence number predictability tests are shown. These are done as a
byproduct of OS detection. With verbosity greater than one, the
actual OS detection fingerprint is shown in more
cases. - Down hosts are printed in ping scan
During a ping scan with verbosity enabled, down hosts will be printed,
rather than just up ones.
- Birthday wishes
Nmap wishes itself a happy birthday when run in
verbose mode on September 1.
The changes that are usually only useful until Nmap finishes and
prints its report are only sent to interactive output mode. If you
send normal output to a file with -oN , that file
won't contain open port alerts or completion time estimates, though
they are still printed to stdout. The assumption is that you will
review the file when Nmap is done and don't want a lot of extra cruft,
while you might watch Nmap's execution progress on standard output and
care about runtime progress. If you really want everything printed to
stdout sent to a file, use the output stream redirection provided by
your shell (e.g. nmap -v scanme.nmap.org >
scanoutput.nmap). The dozens of small changes contingent on verbosity (mostly
extra messages) are too numerous to cover here. They are also always
subject to change. An effective way to see them all is to unpack the
latest Nmap tarball and grep for them with a command such as
grep -A1 o.verbose *.cc. Representative excerpts
from the output are shown in Example 13.2, “Greping for verbosity conditionals” Example 13.2. Greping for verbosity conditionals idle_scan.cc: if (o.debugging || o.verbose) {
idle_scan.cc- log_write(LOG_STDOUT, "Initiating Idlescan against %s\n",
target->NameIP());
--
nmap.cc: if (o.verbose)
nmap.cc- output_ports_to_machine_parseable_output(ports, o.TCPScan(),
o.udpscan, o.ipprotscan);
--
nmap_rpc.cc: if (o.debugging || o.verbose)
nmap_rpc.cc- gh_perror("recvfrom in get_rpc_results");
--
osscan.cc: if (o.verbose && openport != (unsigned long) -1)
osscan.cc- log_write(LOG_STDOUT, "For OSScan assuming port %d is open, %d ..."
--
output.cc: if (o.verbose)
output.cc- log_write(LOG_NORMAL|LOG_SKID|LOG_STDOUT,
"IP ID Sequence Generation: %s\n",...
The following two examples put all of this together.
Example 13.3, “Interactive output without verbosity enabled” shows the output of a
normal scan without the -v option. Example 13.3. Interactive output without verbosity enabled # nmap -T4 -A -p- scanme.nmap.org
Starting nmap ( http://nmap.org )
Interesting ports on scanme.nmap.org (205.217.153.62):
(The 65530 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
25/tcp open smtp qmail smtpd
53/tcp open domain ISC BIND 9.2.1
80/tcp open http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_07-dev)
113/tcp closed auth
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20, Linux 2.4.18 - 2.4.20
Uptime 4.945 days (since Fri Nov 12 15:34:34 2004)
Nmap finished: 1 IP address (1 host up) scanned in 684.774 seconds
Example 13.4, “Interactive output with verbosity enabled” is the output of the
same scan with verbosity enabled. Features such as the extra OS
identification data, completion time estimates, open port alerts, and
extra informational messages are easily identified in the latter output.
This extra info is often helpful during interactive scanning, so I
always specify -v when scanning a single machine unless
I have a good reason not to. Example 13.4. Interactive output with verbosity enabled # nmap -v -T4 -A -p- scanme.nmap.org
Starting nmap ( http://nmap.org )
Initiating SYN Stealth Scan against scanme.nmap.org
(205.217.153.62) [65535 ports] at 3:22
Discovered open port 22/tcp on 205.217.153.62
Discovered open port 53/tcp on 205.217.153.62
Discovered open port 80/tcp on 205.217.153.62
Discovered open port 25/tcp on 205.217.153.62
SYN Stealth Scan Timing: About 4.58% done; ETC: 3:33 (0:10:24 remaining)
The SYN Stealth Scan took 679.55s to scan 65535 total ports.
Initiating service scan against 4 services on scanme.nmap.org (205.217.153.62)
The service scan took 5.10s to scan 4 services on 1 host.
For OSScan assuming port 22 is open, 113 is closed, and neither are firewalled
Host scanme.nmap.org (205.217.153.62) appears to be up ... good.
Interesting ports on scanme.nmap.org (205.217.153.62):
(The 65530 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.1p1 (protocol 1.99)
25/tcp open smtp qmail smtpd
53/tcp open domain ISC BIND 9.2.1
80/tcp open http Apache httpd 2.0.39 ((Unix) mod_perl/1.99_07-dev)
113/tcp closed auth
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20, Linux 2.4.18 - 2.4.20
Uptime 4.916 days (since Fri Nov 12 15:34:34 2004)
TCP Sequence Prediction: Class=random positive increments
Difficulty=3048990 (Good luck!)
IP ID Sequence Generation: All zeros
Nmap finished: 1 IP address (1 host up) scanned in 687.967 seconds
Enabling Debugging OutputWhen even verbose mode doesn't provide sufficient data for you,
debugging is available to flood you with much more! As with the
verbosity option (-v ), debugging is enabled with a
command-line flag (-d ) and the debug level can be
increased by specifying it multiple times. Alternatively, you can set
a debug level by giving an argument to -d . For
example, -d9 sets level nine. That is the highest
effective level and will produce thousands of lines unless you run a
very simple scan with very few ports and targets. Debugging output is useful when a bug is suspected in Nmap,
or if you are simply confused as to what Nmap is doing and why. As this
feature is mostly intended for developers, debug lines aren't always
self-explanatory. If you don't understand a line, your only recourses
are to ignore it, look it up in the source code, or request help from
the development list (nmap-dev). Some lines are self explanatory, but
messages become more obscure as the debug level is
increased. Example 13.5, “Some representative debugging lines”
shows a few different debugging lines that resulted from a
-d5 scan of Scanme. Example 13.5. Some representative debugging lines Timeout vals: srtt: 30256 rttvar: 30256 to: 151280 delta 15699
==> srtt: 32218 rttvar: 26616 to: 138682
RCVD (1.0710s) TCP 205.217.153.62:113 > 63.205.186.56:34538 RA ttl=241 id=0
ack=1188628258
**TIMING STATS**: IP, probes active/freshportsleft/outstanding/retranwait,
cwnd/ccthresh/delay, timeout/srtt/rttvar/
Groupstats (1/1 incomplete): 10/*/*/*/* 15.00/50/* 128805/49393/19853
205.217.153.62: 10/65515/15/5/0 15.00/50/0 125924/41340/21146
Discovered filtered port 38281/tcp on 205.217.153.62
Packet capture filter (device ppp0): dst host [ip] and
(icmp or (tcp and src host 205.217.153.62))
The avg TCP TS HZ is: 100.624257
No full example is given here because debug logs are so long.
A scan against Scanme used 14 lines of text without verbosity
(Example 13.3, “Interactive output without verbosity enabled”), and 28 with it
(Example 13.4, “Interactive output with verbosity enabled”). The same
scan with -d instead of -v took 74
lines. With -d2 it ballooned to 65,768 lines, and
-d5 output 242,650 lines! The debug option
implicitly enables verbosity, so there is no need to specify them
both. Determining the best output level for a certain debug task is a
matter of trial and error. I try a low level first to understand what
is going on, then increase it as necessary. As I learn more, I may
be able to better isolate the problem or question. I then try to
simplify the command in order to offset some increased verbiage of the
higher debug level. Just as grep can be useful to identify the changes and levels
associated with verbosity, it also helps with investigating debug
output. I recommend running this command from the
nmap-VERSION directory in the Nmap source
tarball:
grep -A1 o.debugging *.cc
The --packet-trace option causes Nmap to print a
summary of every packet it sends and receives. This can be extremely
useful for debugging or understanding Nmap's behavior, as examples
throughout this book demonstrate. Example 13.6, “Using --packet-trace to detail a ping scan of Scanme” shows a simple ping scan of
Scanme with packet tracing enabled. Example 13.6. Using --packet-trace to detail a ping scan of Scanme # nmap --packet-trace -sP scanme.nmap.org
Starting nmap 3.77 ( http://nmap.org ) at 2004-11-18 15:59 PST
SENT (0.0110s) ICMP 63.205.186.56 > 205.217.153.62 echo request (type=8/code=0)
ttl=47 id=12401 iplen=28
SENT (0.0130s) TCP 63.205.186.56:45425 > 205.217.153.62:80 A ttl=39 id=22911
iplen=40 seq=2336084894 win=4096 ack=826135454
RCVD (0.0420s) ICMP 205.217.153.62 > 63.205.186.56 echo reply (type=0/code=0)
ttl=50 id=56265 iplen=28
Host scanme.nmap.org (205.217.153.62) appears to be up.
Nmap finished: 1 IP address (1 host up) scanned in 0.171 seconds
This Nmap execution shows three extra lines caused by packet
tracing (each have been wrapped for readability). Each line contains
several fields. The first is whether a packet is sent or received by
Nmap, as abbreviated to SENT and
RCVD . The next field is a time counter, providing
the elapsed time since Nmap started. The time is in seconds, and in
this case Nmap only required a tiny fraction of one. The next field
is the protocol: TCP, UDP, or ICMP. Next comes the source and
destination IP addresses, separated with a directional arrow.
For TCP or UDP packets, each IP is followed by a colon and the source
or destination port number. The remainder of each line is protocol specific. As you can
see, ICMP provides a human-readable type if available (echo
request in this case) followed by the ICMP type and code
values. The ICMP packet logs end with the IP TTL, ID, and packet length
field. TCP packets use a slightly different format after the
destination IP and port number. First comes a list of characters
representing the set TCP flags. The flag characters are
SFRPUEC , which stand for SYN, FIN, RST, PSH, URG,
ECE, and CWR, respectively. The latter two flags are part of TCP
explicit congestion notification, described in RFC 3168 Because packet tracing can lead to thousands of output lines, it
helps to limit scan intensity to the minimum that still serves your
purpose. A scan of a single port on a single machine won't bury you
in data, while the output of a --packet-trace scan of
a whole network can be overwhelming. Packet tracing is automatically
enabled when the debug level (-d ) is at least three. Sometimes --packet-trace provides specialized
data that Nmap never shows otherwise. For example, Example 13.6, “Using --packet-trace to detail a ping scan of Scanme” shows ICMP and TCP ping
packets sent to the target host. The target responds to the ICMP echo
request, which can be valuable information that Nmap doesn't otherwise
show. It is possible that the target host replied to the TCP packet
as well—Nmap stops listening once it receives one response to a
ping scan since that is all it takes to determine that a host is
online. Some extensive Nmap runs take a very long time—on the order
of days. Such scans don't always run to completion. Restrictions may
prevent Nmap from being run during working hours, the network could go
down, the machine Nmap is running on might suffer a planned or
unplanned reboot, or Nmap itself could crash. The administrator running Nmap
could cancel it for any other reason as well, by pressing
ctrl-C. Restarting the whole scan from the beginning
may be undesirable. Fortunately, if normal (-oN ) or
grepable (-oG ) logs were kept, the user can ask Nmap
to resume scanning with the target it was working on when execution
ceased. Simply specify the --resume option and pass
the normal/grepable output file as its argument. No other arguments
are permitted, as Nmap parses the output file to use the same ones
specified previously. Simply call Nmap as nmap --resume
logfilename . Nmap will append
new results to the data files specified in the previous execution. Resumption does not
support the XML output format because combining the two runs into one valid
XML file would be difficult. |
|