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 "Application-Level Tools" for other examples.) Port scanning is one of the tools described in "Host Configurations" that can also be used here. To do the tests described in "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.
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.
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
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.
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: Windows4 / 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: Windows4 / 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 tutorial server, Meridian Data Network tutorial 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.