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
Command-line Flags
| Chapter 13. Nmap Output Formats |
## Command-line Flags 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. ### Controlling Output Type 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 Output After 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 Output When 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 ### Enabling Packet Tracing 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. ### Resuming Aborted Scans 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.
Chapter 13. Nmap Output Formats |  | Interactive Output
| [ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]