6.3. Device Identification
At times it can be helpful to
identify the operating system used on a remote machine. For example,
you may need to identify systems vulnerable to some recently
disclosed security hole. Or if you are faced with a duplicate IP
address, identifying the type of machine is usually the best first
step in locating it. Using
arp to discover the
type of hardware may be all that you will need to do. If you have
identified the interface as a Cisco interface and you have only a
half dozen Cisco devices on your network, you should be able to
easily find the one with the duplicate address. If, on the other
hand, you can identify it only as one of several hundred PCs,
you'll want more information. Knowing the operating system on
the computer may narrow your search.
The obvious, simple strategies are usually the best place to start,
since these are less likely to offend anyone. Ideally, you will have
collected additional information as you set systems up, so all
you'll need to do is consult your database, DHCP records, or
DNS files or, perhaps, give the user a call. But if your records are
incomplete, you'll need to probe the device.
Begin by using
telnet to connect to the device to check for
useful banners. Often login banners are changed or suppressed, so
don't restrict yourself to just the Telnet port. Here is an
example of trying the SMTP port (25):
bsd1# telnet 172.16.2.233 25
Trying 172.16.2.233...
Connected to 172.16.2.233.
Escape character is '^]'.
220 sol1. ESMTP Sendmail 8.9.1b+Sun/8.9.1; Fri, 2 Jun 2000 09:02:45 -0400 (EDT)
quit
221 sol1. closing connection
Connection closed by foreign host.
This simple test tells us
the host is
sol1, and it is using a Sun port of
sendmail. The most likely ports to try are FTP
(21), Telnet (23), SNMP (25), HTTP (80), POP2 (109), POP3 (110), and
NTTP (119), but, depending on the systems, others may be informative
as well.
Often, you don't even have to get the syntax correct to get
useful information. Here is an example of an ill-formed GET request
(the REQUEST_URI is omitted) sent using
telnet:
bsd1# telnet 172.16.2.230 80
Trying 172.16.2.230...
Connected to 172.16.2.230.
Escape character is '^]'.
GET HTTP/1.0
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/4.0
...
Additional output has been omitted, but the system has been
identified in the last line shown. (See
Chapter 10, "Application-Level Tools"
for other examples.)
Port scanning is one of the
tools described in
Chapter 2, "Host Configurations" that can also be used
here. To do the tests described in
Chapter 2, "Host Configurations", you
need change only the host address. The interpretation of the results
is the same. The only thing you need worry about is the possibility
that some of the services you are testing may be blocked by a
firewall. Of course, the presence or absence of a service may provide
insight into the role of the device. An obvious example is an open
HTTP port. If it is open, you are looking at a web server (or,
possibly, a machine misconfigured as a web server) and can probably
get more information by using your web browser on the site.
When these obvious tests fail, as they often will, you'll need
a more sophisticated approach such as stack fingerprinting.
6.3.1. Stack Fingerprinting
The standards that describe
TCP/IP stack implementations are incomplete in the sense that they
sometimes do not address how the stack should respond in some
degenerate or pathological situations. For example, there may be no
predefined way for dealing with a packet with contradictory flags or
with a meaningless sequence of inconsistent packets. Since these
situations should not normally arise, implementers are free to
respond in whatever manner they see fit. Different implementations
respond in different ways.
There are also optional features that
stack implementers may or may not choose to implement. The presence
or absence of such support is another useful clue to the identity of
a system. Even when behavior is well defined, some TCP/IP stacks do
not fully conform to standards. Usually, the differences are minor
inconsistencies that have no real impact on performance or
interoperability. For example, if an isolated FIN packet is sent to
an open port, the system should ignore the packet. Microsoft Windows,
among others, will send a RESET instead of ignoring the packet. This
doesn't create any problems for either of the devices involved,
but it can be used to distinguish systems.
Collectively, these different
behaviors can be exploited to identify which operating system (OS) is
being used on a remote system. A carefully chosen set of packets is
sent and the responses are examined. It is necessary only to compare
the responses seen against a set of known behaviors to deduce the
remote system. This technique is known as
stack
fingerprinting or
OS fingerprinting.
A fingerprinting program will be
successful only if it has a set of anomalies or, to mix metaphors, a
signature that distinguishes the device of
interest from other devices. Since devices change and new devices are
introduced, it is not uncommon for a stack fingerprinting program not
to know the signature for some devices. Ideally, the program will
have a separate signature file or database so that it can be easily
updated. From the user's perspective, it may also be helpful to
have more than one program since each may be able to identify devices
unknown to the other. Consequently, both
queso
and the stack fingerprinting option for
nmap are
described here.
It should also be noted that
passive fingerprinting is possible. With passive
fingerprinting, the idea is to examine the initialization packets
that come into your machine. Of course, this will only identify
systems that try to contact you, but this can be a help in some
circumstances, particularly with respect to security. In some ways,
this approach is more reliable. When a remote machine sends the first
packet, it must fill in all the fields in the headers. When you probe
a remote machine, many of the fields in the headers in the reply
packet will have been copied directly from your probe packets. If you
are interested in this approach, you might want to look at
siphon or
p0f.
WARNING:
When using stack
fingerprinting, whether active or passive, you must realize that you
are fingerprinting the machine you are actually communicating with.
Normally, that is exactly what you want. But if there is a proxy
server between your machine and the target, you will fingerprint the
proxy server, not the intended target.
6.3.2. queso
A number of programs do stack
fingerprinting. One simple program that works well is
queso. Its sole function is stack
fingerprinting. The syntax is straightforward:
bsd1# queso 172.16.2.230
172.16.2.230:80 * Windoze 95/98/NT
By default,
queso
probes the HTTP port (80). If that port is not in use,
queso will tell you to try another port:
bsd1# queso 172.16.2.1
172.16.2.1:80 *- Not Listen, try another port
You
can do this with the
-p option. In this example,
the Telnet port is being checked:
bsd1# queso -p23 172.16.2.1
172.16.2.1:23 * Cisco 11.2(10a), HP/3000 DTC, BayStack Switch
This is not a definitive answer, but it has certainly narrowed down
the field.
You can call
queso with multiple addresses by simply putting
all the addresses on the command line. You can also use subnet masks,
as shown in the following:
bsd1# queso -p23 172.16.2.232/29
172.16.2.233:23 * Solaris 2.x
172.16.2.234:23 * Linux 2.1.xx
172.16.2.235:23 *- Not Listen, try another port
172.16.2.236:23 * Dead Host, Firewalled Port or Unassigned IP
172.16.2.237:23 * Dead Host, Firewalled Port or Unassigned IP
172.16.2.238:23 * Dead Host, Firewalled Port or Unassigned IP
Notice from this example that mask selection doesn't have to
fall on a class boundary.
queso maintains a separate configuration file.
If it doesn't recognize a system, it will prompt you to update
this file:
bsd1# queso -p23 205.153.60.1
205.153.60.1:23 *- Unknown OS, pleez update /usr/local/etc/queso.conf
You can update this file with the
-w option.
queso can
identify a hundred or so different systems. It is not a particularly
fast program but gives acceptable results. It can take several
seconds to scan each machine on the same subnet. If you invoke
queso without any argument, it will provide a
brief summary of its options.
6.3.3. nmap Revisited
You can also do stack fingerprinting with
nmap by using the
-O
option:
bsd1# nmap -O 172.16.2.230
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
WARNING: OS didn't match until the 2 try
Interesting ports on (172.16.2.230):
Port State Protocol Service
21 open tcp ftp
80 open tcp http
135 open tcp loc-srv
139 open tcp netbios-ssn
443 open tcp https
1032 open tcp iad3
6666 open tcp irc-serv
7007 open tcp afs3-bos
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=0 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds
You can suppress most of the port information by specifying a
particular port. For example:
bsd1# nmap -p80 -O 172.16.2.230
Starting nmap V. 2.12 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on (172.16.2.230):
Port State Protocol Service
80 open tcp http
TCP Sequence Prediction: Class=trivial time dependency
Difficulty=0 (Trivial joke)
Remote operating system guess: Windows NT4 / Win95 / Win98
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
You will probably want to do this if you are scanning a range of
machines to save time. However, if you don't restrict
nmap to a single port, you are more likely to
get a useful answer.
Results can be vague at times. This is what
nmap
returned on one device:
...
Remote OS guesses: Cisco Catalyst 1900 switch or Netopia 655-U/POTS ISDN Router,
Datavoice TxPORT PRISM 3000 T1 CSU/DSU 6.22/2.06, MultiTech CommPlete Controlle
r, IBM MVS TCP/IP stack V. 3.2, APC MasterSwitch Network Power Controller, AXIS
or Meridian Data Network CD-ROM server, Meridian Data Network CD-ROM Server (V4.
20 Nov 26 1997), WorldGroup BBS (MajorBBS) w/TCP/IP
The correct answer is none of the above. A system that may not be
recognized by
nmap may be recognized by
queso or vice versa.
 |  |  |
| 6.2. Device Discovery |  | 6.4. Scripts |
