The inner workings of OS detection are quite complex, but it is
one of the easiest features to use. Simply add -O
to
your scan options. You may want to also increase the verbosity with
-v
for even more OS-related details. This is shown
in Example 8.1, “OS Detection with Verbosity (-O
-v
)”
Example 8.1. OS Detection with Verbosity (-O
-v
)
# nmap -O -v scanme.nmap.org
Starting Nmap ( http://nmap.org )
Interesting ports on scanme.nmap.org (205.217.153.62):
(The 1667 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
70/tcp closed gopher
80/tcp open http
113/tcp closed auth
Device type: general purpose
Running: Linux 2.4.X|2.5.X|2.6.X
OS details: Linux 2.4.7 - 2.6.11, Linux 2.6.0 - 2.6.11
Uptime 24.247 days (since Wed Feb 22 11:39:20 2006)
Network Distance: 10 hops
TCP Sequence Prediction: Class=random positive increments
Difficulty=2662996 (Good luck!)
IP ID Sequence Generation: All zeros
Nmap finished: 1 IP address (1 host up) scanned in 22.572 seconds
Raw packets sent: 3360 (148.612KB) | Rcvd: 25 (1264B)
Including the -O -v
options caused Nmap to generate the following six extra line items:
- Device type
All fingerprints are classified with one or more
high-level device types, such as router
,
printer
, firewall
, or (as in
this case) general purpose
. These are further
described in the section called “Device and OS classification (Class
lines)” Several device
types may be shown, in which case they will be separated with the
pipe symbol as in “Device Type:
router|firewall
”.
- Running
This field is also related to the OS
classification scheme described in the section called “Device and OS classification (Class
lines)” It shows the OS Family (Linux
in this
case) and OS generation if available. In this case, Nmap isn't
sure whether the kernel is of the 2.4, 2.5, or 2.6 generation and
so it writes all three separated by a pipe character
(2.4.X|2.5.X|2.6.X
). If there are multiple OS
families, they are separated by commas (e.g. OpenBSD 3.X,
NetBSD 3.X|4.X
).
If Nmap finds too many OS families to print concisely, it
will omit this line. When there are no perfect matches, Nmap
changes the field to “Running (JUST GUESSING)” and
adds an accuracy percentage (100% is a perfect match) in
parentheses after each candidate family name. If no fingerprints
are close matches, the line is omitted.
- OS details
This line gives the detailed description for each
fingerprint that matches. While the Device
type
and Running
lines are from
predefined enumerated lists that are easy to parse by a computer,
the OS details line contains free-form data which
is useful to a human reading the report. This can include more
exact version numbers, device models, and architectures specific
to a given fingerprint. In this example, two fingerprints matched
(“Linux 2.4.7 - 2.6.11” and “Linux 2.6.0 -
2.6.11”) and so they are comma separated. When there are
no perfect matches but some close guesses, the field is renamed
Aggressive OS guesses
and fingerprints are
shown followed by a percentage match in
parentheses.
- Uptime
As part OS detection, Nmap receives several
SYN/ACK TCP packets in a row and checks the headers for a
timestamp option. Many operating systems use a simple counter for
this which starts at zero at boot time then increments at a
constant rate such as twice per second. By looking at several
responses, Nmap can determine the current values and rate of
increase. Simple linear extrapolation determines boot time. The
timestamp algorithm is used for OS detection too (see the section called “TCP timestamp option algorithm (TS
)”) since the incrementation rate on
different systems varies from 2Hz to 1,000Hz. While the uptime
value itself isn't part of OS detection, it can be valuable and so
is printed when available. Nmap omits the line if the target
gives zeros or no timestamp options in its SYN/ACK packets, or if
it does not reply at all. The line is also omitted if Nmap cannot
discern the timestamp increment rate or it seems suspicious (like
a 30-year uptime).
- Network distance
A side effect of one of the OS detection tests
allows Nmap to compute how many routers are between it and a
target host. The distance is zero when you are scanning
localhost, and one for a machine on the same network segment. Each
additional router on the path adds one to the hop count. Nmap
omits this line when it isn't able to compute this value (no reply
to the relevant probe).
- TCP Sequence Prediction
Systems with poor TCP initial sequence
number generation are vulnerable to
blind TCP spoofing attacks. In other words, you can make a full
connection to those systems and send (but not receive) data while
spoofing a different IP address. The target's logs will show the
spoofed IP, and you can take advantage of any trust relationship
between them. This attack was all the rage in the mid-nineties
when people commonly used rlogin to allow logins to their account
without any password from trusted IP addresses. Kevin Mitnick is
alleged to have used this attack to break into Tsutomu Shimomura's
computers in December 1994.
The good news is that hardly anyone uses rlogin
anymore, and many operating systems have been fixed to use
unpredictable initial sequence numbers as proposed by RFC 1948 For
these reasons, this line is only printed in verbose mode. Sadly,
many vendors still ship
vulnerable operating systems and devices
Even the fixed ones often vary in implementation, which leaves
them valuable for OS detection purposes. The class describes the
ISN generation algorithm used by the target, and difficulty is a
rough estimate of how hard the system makes blind IP spoofing (0
is the easiest). The parenthesized comment is based on the
difficulty index and ranges from trivial joke
to easy
, medium
,
formidable
, worthy
challenge
, and finally good luck!
Further details about ISN tests are provided in the section called “TCP ISN greatest common denominator (GCD
)”
While the rlogin family is mostly a relic of the past, clever
attackers can still find effective uses for blind TCP spoofing. For
example, it allows for spoofed http requests. You don't see the
results, but just the URL (POST or GET request) can have dramatic
side effects. The spoofing allows attackers to hide their identity,
frame someone else, or exploit IP address restrictions.
- IP ID sequence generation
Many systems unwittingly give away sensitive
information about their traffic levels based on how they generate
the lowly 16-bit ID field in IP packets. This can be abused to
spoof a port scan against other systems and for other mischievous
purposes discussed
in our idle scanning paper
This field describes the ID generation algorithm that Nmap was able to discern.
More information on how it classifies them is available in the section called “TCP IP ID sequence generation algorithm
(TI
)” Note that many systems use a different
IP ID space for each host they communicate with. In that case,
they may appear vulnerable (such as showing the Incremental
class) while still being secure against attacks such as the idle
scan. For this reason, and because the issue is rarely critical,
the IP ID sequence generation line is only printed in verbose mode.
If Nmap does not receive sufficient responses during OS detection,
it will omit the whole line. The best way to test whether a host
is vulnerable to being an idle scan zombie is to test it with
-sI
.
While TCP fingerprinting is a powerful method for OS detection,
interrogating open ports for clues is another effective approach.
Some applications, such as Microsoft IIS, only run on a single platform (thus
giving it away), while many other apps divulge their platform in
overly verbose banner messages. Adding the -sV
option enables Nmap version detection, which is trained to look for
these clues (among others). In Example 8.2, “Using version scan to detect the OS”,
Nmap catches the platform details from an FTP server.
Example 8.2. Using version scan to detect the OS
# nmap -sV -O -v 129.128.X.XX
Starting Nmap ( http://nmap.org )
Interesting ports on [hostname] (129.128.X.XX):
(The 1225 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
21/tcp open ftp HP-UX 10.x ftpd 4.1
22/tcp open ssh OpenSSH 3.7.1p1 (protocol 1.99)
111/tcp open rpc
445/tcp filtered microsoft-ds
1526/tcp open oracle-tns Oracle TNS Listener
32775/tcp open rpc
No exact OS matches for host
TCP Sequence Prediction: Class=truly random
Difficulty=9999999 (Good luck!)
IP ID Sequence Generation: Incremental
Service Info: OS: HP-UX
In this example, the line “No exact OS
matches for host
” means that TCP/IP
fingerprinting failed to find an exact match. Fortunately, the
Service Info
field a few lines down discloses that
the OS is HP-UX. If several operating systems were detected (which
can happen with NAT gateway boxes that redirect ports to several
different machines), the field would be OSs
and the values would be
comma separated. The Service Info
line can also
contain hostnames and device types found during the version scan. The
focus of this
article
is on TCP/IP fingerprinting though, since version
detection was covered in Chapter 7, Service and Application Version Detection
With two effective OS detection methods available, which one
should you use? The best answer is usually both. In some cases, such
as a proxy firewall forwarding to an application on another host, the answers may
legitimately differ. TCP/IP fingerprinting will identify the proxy
while version scanning will generally detect the server running the
proxied application. Even when no proxying or port forwarding is
involved, using both techniques is beneficial. If they come out the
same, that makes the results more credible. If they come out wildly
different, investigate further to determine what is going on before
relying on either. Since OS and version detection go together so
well, Nmap has a special -A
option to enable them
both.
OS detection is far more effective if at least one open
and one closed TCP port are found. Set the --osscan-limit
option and Nmap will not even try OS detection against hosts which do
not meet this criteria. This can save substantial time, particularly
on -PN
scans against many hosts. You still need to enable OS
detection with -O
(or -A
) for this
to have any effect.
Another OS detection option is
--osscan-guess
. When Nmap is unable to detect a
perfect OS match, it sometimes offers up near-matches as
possibilities. The match has to be very close for Nmap to do this by
default. If you specify this option (or the equivalent
--fuzzy
option), Nmap will guess more aggressively.
Nmap still tells you when an imperfect match is printed and
display its confidence level (percentage) for each guess.
When Nmap performs OS detection against a target and fails to
find a perfect match, it usually repeats the attempt. By default,
Nmap tries five times if conditions are favorable for OS fingerprint
submission, and twice when conditions aren't so good. The
--max-os-tries
option lets you change this maximum
number of OS detection tries. Lowering it (usually to 1) speeds Nmap
up, though you miss out on retries which could potentially identify
the OS. Alternatively, a high value may be set to allow even more
retries when conditions are favorable. This is rarely done, except to
generate better fingerprints for submission and integration into the
Nmap OS database.
Like just about every other part of Nmap, results ultimately come from the target machine itself. While rare, systems are occasionally configured to confuse or mislead Nmap. Several programs have even been developed specifically to
trick Nmap OS detection
Your best bet is to use numerous reconnaissance methods to explore a network, and don't trust any one of them.
TCP/IP fingerprinting requires collecting hundreds of details
about the target's IP stack. The most commonly useful results, such as uptime
and TTL information, are printed to Nmap output whenever they are
obtained. Slightly less pertinent information, such as IP ID sequence
generation and TCP sequence prediction difficulty, is only printed in
verbose mode. But if you want all of the IP stack details that Nmap
collected, you can find it in a compact form called a
subject fingerprint. Nmap sometimes prints this
(for user submission purposes) when it doesn't recognize a host. You
can also force Nmap to print it (in normal, interactive, and XML
formats) by enabling debugging with (-d
). Then read the section called “Understanding an Nmap Fingerprint” to interpret it.