116
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 dont 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 HTTP1.0 HTTP1.1 400 Bad Request
Server: Microsoft-IIS4.0 ...
Additional output has been omitted, but the system has been identified in the last line shown. See Chapter 10
for other examples. Port scanning is one of the tools described in
Chapter 2 that can also be used here. To do the tests
described in Chapter 2
, 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, youll need a more sophisticated approach such as stack fingerprinting.
6.3.1 Stack Fingerprinting
The standards that describe TCPIP 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 TCPIP 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 doesnt
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
117
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 users 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
