Overview of Port Scanners

Port scanners, simply enough, poll a set of TCP or UDP ports to see if an application answers back. If it receives a response, this means there is some application listening on that port number. There are a possible 65,535 TCP ports, and the same number of ports are available for the UDP protocol. Port scanners can be configured to scan all possible ports, or just the commonly used ones (those below 1,024), to look for servers. A good reason to do a complete scan of all possible ports is that network-aware Trojan horses and other nasty software often run on uncommon ports high up in the range in order to avoid detection. Also, some vendors don't stick as closely to the standards as they should and put server applications on high port numbers. A full scan will cover all the possible places that applications can be hiding, although this takes more time and eats up a little more bandwidth.

Port scanners come in many different flavors, from very complex with lots of different features to those with minimal functionality. In fact, you can perform the functions of a port scanner yourself manually. You can use Telnet to do this, one port at a time. Simply connect to an IP address and add the port number like this:


telnet 192.168.0.1:80

This command uses Telnet to connect to the machine. The number after the colon (on some implementations of Telnet you just leave a space between the IP address and the port number) tells Telnet to use port 80 to connect instead of the standard Telnet port of 22. Rather than the normal Telnet prompt you get on the defaultTelnet port, you'll connect to the Web server if one is running on that machine. When you press Enter you will get the first response from a Web server to a browser. You'll see the HTTP header information, which is normally processed by your browser and hidden from view. It will look something like the output shown in Listing 4.1.

Listing 4.1. HTTP Response to a TCP connection


GET / HTTP



HTTP/1.1 400 Bad Request

Date: Mon, 15 Mar 2004 17:13:16 GMT

Server: Apache/1.3.20 Sun Cobalt (Unix) Chili!Soft-ASP/3.6.2 mod_ssl/2.8.4 OpenSSL/0.9.6b

 PHP/4.1.2 mod_auth_pam_external/0.1 FrontPage/4.0.4.3 mod_perl/1.25

Connection: close

Content-Type: text/html; charset=iso-8859-1



<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<HTML><HEAD>

<TITLE>400 Bad Request</TITLE>

</HEAD><BODY>

<H1>Bad Request</H1><P>

Your browser sent a request that this server could not understand

Request header field is missing colon separator.<P>

<PRE>

/PRE>

<P>

</BODY></HTML>

You can do this with any open port, but you won't always get anything intelligible back. Basically this is what port scanners do: they attempt to establish a connection and look for a response.

Some port scanners also try to identify the operating system on the other end. They do this by performing what is called TCP fingerprinting. Although TCP/IP is a standard for network communications, every vendor implements it slightly differently. These differences, although they don't normally interfere with communications, show up in the response they give to any stimulus such as a ping or an attempted TCP connection. Thus, the digital signature of a ping response from a Windows system looks different from the response from a Linux system. There are even differences between versions of operating systems. See Listing 4.2 for an example of the TCP fingerprint for Windows ME, 2000, and XP.

Listing 4.2. Windows TCP Fingerprints


# Windows Millennium Edition v4.90.300

# Windows 2000 Professional (x86)

# Windows Me or Windows 2000 RC1 through final release

# Microsoft Windows 2000 Advanced Server

# Windows XP professional version 2002 on PC Intel processor

# Windows XP Build 2600

# Windows 2000 with SP2 and long fat pipe (RFC 1323)

# Windows 2K 5.00.2195 Service Pack 2 and latest hotfixes

# XP Professional 5.1 (build 2600).. all patches up to June 20, 2004

# Fingerprint Windows XP Pro with all current updates to May 2002

Fingerprint Windows Millennium Edition (Me), Win 2000, or WinXP

TSeq(Class=RI%gcd=<6%SI=<23726&>49C%IPID=I%TS=0)

T1(DF=Y%W=5B4|14F0|16D0|2EE0|402E|B5C9|B580|C000|D304|FC00|FD20|FD

  68|FFFF%ACK=S++%Flags=AS%Ops=NNT|MNWNNT)

T2(Resp=Y|N%DF=N%W=0%ACK=S%Flags=AR%Ops=)

T3(Resp=Y%DF=Y%W=5B4|14F0|16D0|2EE0|B5C9|B580|C000|402E|D304|FC00|

  FD20|FD68|FFFF%ACK=S++%Flags=AS%Ops=MNWNNT)

T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(DF=N%W=0%ACK=O%Flags=R%Ops=)

T7(DF=N%W=0%ACK=S++%Flags=AR%Ops=)

PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E|F%UCK=E|F%ULEN=134%

  DAT=E)

What looks like unintelligible gibberish at the bottom is the unique settings that Windows uses when it connects via TCP. By comparing the TCP response received from a machine to a database of known TCP fingerprints, you can make a reasonable guess at the operating system on the other end.

This method isn't perfect. Sometimes the port scanner program gets it wrong because some operating system vendors cannibalize or reuse parts of other systems (UNIX systems in particular) when building a TCP stack. This causes the port scanner to think it is the OS they borrowed the TCP stack from. Also, there are odd operating systems like switches, printers, and network appliances that may not be in the signature database.

If people are scanning your network with less than honorable intentions in mind, this provides them with valuable information. Knowing the operating system and version can be a good starting point for figuring out what angles and exploits to try. This is a very good reason to regularly scan your network to see what ports are showing open on your systems. Then you can go through and close up unnecessary ports and lock down those that must stay open.

< Day Day Up >