DETERMINING WHICH SERVICES ARE RUNNING OR LISTENING

Thus far we have identified systems that are alive by using either ICMP or TCP ping sweeps and have gathered selected ICMP information. Now we are ready to begin portscanning each system.

Port Scanning

Popularity:	10
Simplicity:	9
Impact:	9
Risk Rating:	9

Port scanning is the process of connecting to TCP and UDP ports on the target system to determine what services are running or are in a LISTENING state. Identifying listening ports is critical to determining the services running, and consequently the vulnerabilities present from remote. Additionally, you can determine the type and version of the operating system and applications in use. Active services that are listening are akin to the doors and windows of your house. They are ways into the domicile. Depending on the type of path in (a window or door), it may allow an unauthorized user to gain access to systems that are misconfigured or running a version of software known to have security vulnerabilities. In this section we will focus on several popular port-scanning tools and techniques that will provide us with a wealth of information and give us a window into the vulnerabilities of the system. The port-scanning techniques that follow differ from those previously mentioned, when we were trying to just identify systems that are alive. For the following steps, we will assume that the systems are alive, and we are now trying to determine all the listening ports or potential access points on our target.

We want to accomplish several objectives when port-scanning the target system(s). These include but are not limited to the following:

• Identifying both the TCP and UDP services running on the target system

• Identifying the type of operating system of the target system

• Identifying specific applications or versions of a particular service

Scan Types

Before we jump into the requisite port-scanning tools themselves , we must discuss the various port-scanning techniques available. One of the pioneers of implementing various port-scanning techniques is Fyodor. He has incorporated numerous scanning techniques into his nmap tool. Many of the scan types we will be discussing are the direct work of Fyodor himself:

• TCP connect scan This type of scan connects to the target port and completes a full three-way handshake (SYN, SYN/ACK, and ACK), as the TCP RFC (Request for Comments) states. It is easily detected by the target system. Figure 2-3 provides a diagram of the TCP three-way handshake.

  
  Figure 2-3: (1) Sending a SYN packet, (2) receiving a SYN/ACK packet, and (3) sending an ACK packet

• TCP SYN scan This technique is called half- open scanning because a full TCP connection is not made. Instead, a SYN packet is sent to the target port. If a SYN/ACK is received from the target port, we can deduce that it is in the LISTENING state. If an RST/ACK is received, it usually indicates that the port is not listening. An RST/ACK will be sent by the system performing the port scan so that a full connection is never established. This technique has the advantage of being stealthier than a full TCP connect, and it may not be logged by the target system. However, one of the downsides of this technique is that this form of scanning can produce a denial of service condition on the target by opening a large number of half-open connections. But unless you are scanning the same system with a high number of these connections, this technique is relatively safe.

• TCP FIN scan This technique sends a FIN packet to the target port. Based on RFC 793 (http://www.ietf.org/rfc/rfc0793.txt), the target system should send back an RST for all closed ports. This technique usually only works on UNIXbased TCP/IP stacks.

• TCP Xmas Tree scan This technique sends a FIN, URG, and PUSH packet to the target port. Based on RFC 793, the target system should send back an RST for all closed ports.

• TCP Null scan This technique turns off all flags. Based on RFC 793, the target system should send back an RST for all closed ports.

• TCP ACK scan This technique is used to map out firewall rulesets. It can help determine if the firewall is a simple packet filter allowing only established connections (connections with the ACK bit set) or a stateful firewall performing advance packet filtering.

• TCP Windows scan This technique may detect open as well as filtered/nonfiltered ports on some systems (for example, AIX and FreeBSD) due to an anomaly in the way the TCP windows size is reported .

• TCP RPC scan This technique is specific to UNIX systems and is used to detect and identify Remote Procedure Call (RPC) ports and their associated program and version number.

• UDP scan This technique sends a UDP packet to the target port. If the target port responds with an "ICMP port unreachable" message, the port is closed. Conversely, if you don't receive an "ICMP port unreachable" message, you can deduce the port is open. Because UDP is known as a connectionless protocol, the accuracy of this technique is highly dependent on many factors related to the utilization and filtering of the target network. In addition, UDP scanning is a very slow process if you are trying to scan a device that employs heavy packet filtering. If you plan on doing UDP scans over the Internet, be prepared for unreliable results.

Certain IP implementations have the unfortunate distinction of sending back reset (RST) packets for all ports scanned, regardless of whether or not they are listening. Therefore, your results may vary when performing these scans; however, SYN and connect( ) scans should work against all hosts .

Identifying TCP and UDP Services Running

A good port-scanning tool is a critical component of the footprinting process. Although many port scanners are available for both the UNIX and Windows environments, we'll limit our discussion to some of the more popular and time-proven port scanners .

strobe

strobe is a venerable TCP port-scanning utility written by Julian Assange (ftp://ftp. FreeBSD.org/pub/FreeBSD/ports/distfiles/strobe-1.06.tgz). It has been around for some time and is one of the fastest and most reliable TCP scanners available. Some of strobe's key features include the ability to optimize system and network resources and to scan the target system in an efficient manner. In addition to being efficient, strobe (version 1.04 and later) will actually grab the associated banner (if available) of each port it connects to. This may help identify both the operating system and the running service. Banner grabbing is explained in more detail in Chapter 3.

The strobe output lists each listening TCP port:

 [root]  strobe 192.168.1.10  strobe 1.03 (c) 1995 Julian Assange ([e-mail]). 192.168.1.10   echo                7/tcp Echo [95,JBP] 192.168.1.10   discard             9/tcp Discard [94,JBP] 192.168.1.10   sunrpc            111/tcp rpcbind SUN RPC 192.168.1.10   daytime            13/tcp Daytime [93,JBP] 192.168.1.10   chargen            19/tcp ttytst source 192.168.1.10   ftp                21/tcp File Transfer [Control] [96,JBP] 192.168.1.10   exec              512/tcp remote process execution; 192.168.1.10   login             513/tcp remote login a la telnet; 192.168.1.10   cmd               514/tcp shell like exec, but automatic 192.168.1.10   ssh                22/tcp Secure Shell 192.168.1.10   telnet             23/tcp Telnet [112,JBP] 192.168.1.10   smtp               25/tcp Simple Mail Transfer [102,JBP] 192.168.1.10   nfs              2049/tcp networked file system 192.168.1.10   lockd            4045/tcp 192.168.1.10   unknown         32772/tcp unassigned 192.168.1.10   unknown         32773/tcp unassigned 192.168.1.10   unknown         32778/tcp unassigned 192.168.1.10   unknown         32799/tcp unassigned 192.168.1.10   unknown         32804/tcp unassigned 

Although strobe is highly reliable, you need to keep in mind some of its limitations. strobe is a TCP scanner only and does not provide UDP scanning capabilities. Therefore, in the preceding scan we are only looking at half the picture. For additional scanning techniques beyond what strobe can provide, we must dig deeper into our toolkit.

udp_scan

Because strobe covers only TCP scanning, we can use udp_scan, originally from SATAN (Security Administrator Tool for Analyzing Networks), written by Dan Farmer and Wietse Venema in 1995. Although SATAN is a bit dated, its tools still work quite well. In addition, newer versions of SATAN, now called SAINT , have been released at http://wwdsilx.wwdsi.com. Many other utilities perform UDP scans; however, we have found that udp_scan is one of the most reliable UDP scanners available. We should point out that although udp_scan is reliable, it does have a nasty side effect of triggering a SATAN scan message from major IDS products. Therefore, it is not one of the more stealthy tools you could employ . Typically, we will look for all well-known ports below 1024 and specific high-risk ports above 1024. Here's an example:

 [root]  udp_scan 192.168.1.1 1-1024  42:UNKNOWN: 53:UNKNOWN: 123:UNKNOWN: 135:UNKNOWN: 

netcat

Despite the raw nature of the tool, another excellent utility is netcat (or nc), written by Hobbit ([e-mail]). This utility can perform so many tasks that everyone in the industry calls it the Swiss Army knife of security. Although we will discuss many of its advanced features throughout the book,nc provides basic TCP and UDP port-scanning capabilities. The -v and -vv options provide verbose and very verbose output, respectively. The -z option provides zero mode I/O and is used for port scanning, and the -w2 option provides a timeout value for each connection. By default, nc will use TCP ports. Therefore, we must specify the -u option for UDP scanning, as in the second example shown next :

 [root]  nc -v -z -w2 192.168.1.1 1-140  [192.168.1.1] 139 (?) open [192.168.1.1] 135 (?) open [192.168.1.1] 110 (pop-3) open [192.168.1.1] 106 (?) open [192.168.1.1] 81 (?) open [192.168.1.1] 80 (http) open [192.168.1.1] 79 (finger) open [192.168.1.1] 53 (domain) open [192.168.1.1] 42 (?) open [192.168.1.1] 25 (smtp) open [192.168.1.1] 21 (ftp) open [root]  nc -u -v -z -w2 192.168.1.1 1-140  [192.168.1.1] 135 (ntportmap) open [192.168.1.1] 123 (ntp) open [192.168.1.1] 53 (domain) open [192.168.1.1] 42 (name) open 

Network Mapper (nmap)

Now that we have discussed basic port-scanning tools, we can move on to one of the premier port-scanning tools available for UNIX, nmap (http://www. insecure .org/nmap). nmap, by Fyodor, provides basic TCP and UDP scanning capabilities as well as incorporates the aforementioned scanning techniques. Let's explore some of its most useful features:

 [root]#  nmap -h  nmap V. 3.70 Usage: nmap [Scan Type(s)] [Options] <host or net list> Some Common Scan Types ('*' options require root privileges)   -sT TCP connect() port scan (default) * -sS TCP SYN stealth port scan (best all-around TCP scan) * -sU UDP port scan   -sP ping scan (Find any reachable machines) * -sF,-sX,-sN Stealth FIN, Xmas, or Null scan (experts only)   -sR/-I RPC/Identd scan (use with other scan types) Some Common Options (none are required, most can be combined): * -O Use TCP/IP fingerprinting to guess remote operating system   -p <range> ports to scan. Example range: '1-1024,1080,6666,31337'   -F Only scans ports listed in nmap-services   -v Verbose. Its use is recommended. Use twice for greater effect.   -P0 Don't ping hosts (needed to scan www.microsoft.com and others) * -Ddecoy_host1,decoy2[,...] Hide scan using many decoys   -T <ParanoidSneakyPoliteNormalAggressiveInsane> General timing policy   -n/-R Never do DNS resolution/Always resolve [default: sometimes resolve]   -oN/-oM <logfile> Output normal/machine parsable scan logs to <logfile>   -iL <inputfile> Get targets from file; Use '-' for stdin * -S <your_P>/-e <devicename> Specify source address or network interface   --interactive Go into interactive mode (then press h for help) [root]  nmap -sS 192.168.1.1  Starting nmap V. 3.70 by [e-mail] Interesting ports on (192.168.1.11): (The 1504 ports scanned but not shown below are in state: closed) Port    State     Protocol    Service 21      open      tcp          ftp 25      open      tcp          smtp 42      open      tcp          nameserver 53      open      tcp          domain 79      open      tcp          finger 80      open      tcp          http 81      open      tcp          hosts2-ns 106     open      tcp          pop3pw 110     open      tcp          pop-3 135     open      tcp          loc-srv 139     open      tcp          netbios-ssn 443     open      tcp          https 

nmap has some other features we should explore as well. You have seen the syntax that can be used to scan one system. However, nmap makes it easy for us to scan a complete network. As you can see, nmap allows us to enter ranges in CIDR (Classless Inter-Domain Routing) block notation (see RFC 1519 at http://www.ietf.org/rfc/rfc1519.txt), a convenient format that allows us to specify 192.168.1.1-192.168.1.254 as our range. Also notice that we used the ndash;o option to save our output to a separate file. Using the -oN option will save the results in human-readable format:

 [root]# nmap -sF 192.168.1.0/24 -oN outfile 

If you want to save your results to a tab-delimited file so you can programmatically parse the results later, use the -oM option. Because we have the potential to receive a lot of information from this scan, it is a good idea to save this information to either format. In some cases, you may want to combine the -oN option and the -oM option to save the output into both formats.

Suppose that after footprinting an organization, we discover that they were using a simple packet-filtering device as their primary firewall. We could use the -f option of nmap to fragment the packets. Essentially, this option splits up the TCP headers over several packets, which may make it harder for access control devices or intrusion detection systems (IDSs) to detect the scan. In most cases, modern packet-filtering devices and application-based firewalls will queue all IP fragments before evaluating them. It is possible that older access control devices or devices that require the highest level of performance will not defragment the packets before passing them on.

Depending on how sophisticated the target network and hosts are, the scans performed thus far may have easily been detected. nmap does offer additional decoy capabilities designed to overwhelm a target site with superfluous information through the use of the -D option. The basic premise behind this option is to launch decoy scans at the same time a real scan is launched. This is achieved by spoofing the source address of legitimate servers and intermixing these bogus scans with the real port scan. The target system will then respond to the spoofed addresses as well as to your real port scan. Moreover, the target site has the burden of trying to track down all the scans to determine which are legitimate and which are bogus. It is important to remember that the decoy address should be alive; otherwise , your scans may SYN-flood the target system and cause a denial of service condition. The following example uses the -D option:

 [root]  nmap -sS  192.168.1.1 -D 10.1.1.1  www.target_web.com, ME -p25,139,443 Starting nmap V. 3.70 by [e-mail] Interesting ports on  (192.168.1.1): Port    State      Protocol   Service 25      open       tcp        smtp 443     open       tcp        https Nmap run completed -- 1 IP address (1 host up) scanned in 1 second 

In the preceding example, nmap provides the decoy scan capabilities to make it more difficult to discern legitimate port scans from bogus ones.

Another useful scanning feature is ident scanning. ident (see RFC 1413 at http://www.ietf.org/rfc/rfc1413.txt) is used to determine the identity of a user of a particular TCP connection by communicating with port 113. Many versions of ident will actually respond with the owner of the process that is bound to that particular port. However, this is most useful against a UNIX target. Here's an example:

 [root]  nmap -I 192.168.1.10  Starting nmap V. 3.70 by [e-mail] Port    State     Protocol    Service       Owner 22      open      tcp          ssh           root 25      open      tcp          smtp          root 80      open      tcp          http          root 110     open      tcp          pop-3         root 113     open      tcp          auth          root 6000    open      tcp          X11           root 

Notice that in the preceding example we can actually determine the owner of each process. The astute reader may have noticed that the web server is running as "root" instead of as an unprivileged user such as "nobody." This is a very poor security practice. Thus, by performing an ident scan, we know that if the HTTP service were to be compromised by allowing an unauthorized user to execute commands, the attacker would be rewarded with instant root access.

The final scanning technique discussed is FTP bounce scanning. The FTP bounce attack was thrust into the spotlight by Hobbit. In his posting to Bugtraq in 1995 (securityfocus.com/templates/archive.pike?list=1&msg=[e-mail]), he outlines some of the inherent flaws in the FTP protocol (see RFC 959 at http://www.ietf.org/rfc/rfc0959.txt). Although dreadfully arcane and virtually unusable on the Internet today, the FTP bounce attack is an insidious method of laundering connections through an FTP server by abusing the support for "proxy" FTP connections. As Hobbit points out in the aforementioned post, FTP bounce attacks "can be used to post virtually untraceable mail and news, hammer on servers at various sites, fill up disks, try to hop firewalls, and generally be annoying and hard to track down at the same time." Moreover, you can bounce port scans off the FTP server to hide your identity, or better yet, bypass access control mechanisms.

Of course, nmap supports this type of scan with the -b option; however, a few conditions must be present. First, the FTP server must have a writable and readable directory such as /incoming. Second, the FTP server must allow nmap to feed bogus port information to it via the PORT command. Although this technique is very effective in bypassing access control devices as well as hiding one's identity, it can be a very slow process. Additionally, many new versions of the FTP server do not allow this type of nefarious activity to take place.

Now that we have demonstrated the requisite tools to perform port scanning, it is necessary for you to understand how to analyze the data that is received from each tool. Regardless of the tool used, we are trying to identify open ports that provide telltale signs of the operating system. For example, when ports 445, 139, and 135 are open, a high probability exists that the target operating system is Windows. Windows 2000 and later normally listens on port 135 and port 139. This differs from Windows 95/98, which only listen on port 139.

Reviewing the strobe output further (from earlier in the chapter), we can see many services running on this system. If we were to make an educated guess, this system seems to be running some flavor of UNIX. We arrived at this conclusion because the portmapper (111), Berkeley R services ports (512-514), NFS (2049), and high-number ports (3277X and above) were all listening. The existence of such ports normally indicates that this system is running UNIX. Moreover, if we had to guess the flavor of UNIX, we would guess Solaris. We know in advance that Solaris normally runs its RPC services in the range of 3277X. Just remember that we are making assumptions and that the type could potentially be something other than Solaris.

By performing a simple TCP and UDP port scan, we can make quick assumptions on the exposure of the systems we are targeting. For example, if port 445 or 139 is open on a Windows server, it may be exposed to a great deal of risk. Chapter 4 discusses the inherent vulnerabilities with Windows and how port 445 and 139 access can be used to compromise the security of systems that do not take adequate security measures to protect access to these ports. In our example, the UNIX system appears to be at risk as well, because the services listening provide a great deal of functionality and have been known to have many security-related vulnerabilities. For example, Remote Procedure Call (RPC) services and the Network File System (NFS) service are two major ways in which an attacker may be able to compromise the security of a UNIX server (see Chapter 5). Conversely, it is virtually impossible to compromise the security of a remote service if it is not listening. Therefore, it is important to remember that the greater the number of services running, the greater the likelihood of a system compromise.

Windows-Based Port Scanners

We've talked a lot to this point about port scanners from the perspective of a UNIX user, but does that mean Windows users can't join in all the fun? Of course notthe following port-scanning tools have risen to the top of our toolbox because of their speed, accuracy, and feature set.

SuperScan

SuperScan, from Foundstone, can be found at http://www.foundstone.com. Over the years , it has become one of the fastest, most reliable, and most flexible Windows port scannersbecoming the de facto tool for assessment projects. Unlike almost every other port scanner, SuperScan is both a TCP and UDP port scanner that comes at a great pricefree! It allows for flexible specification of target IPs and port lists. As you can see in Figure 2-4, the tool allows for ping scanning, TCP and UDP port scanning, and includes numerous techniques for doing them all.

Figure 2-4: SuperScan offers numerous host-discovery tricks.

SuperScan allows you to choose from four different ICMP host-discovery techniques, including traditional Echo Requests and the less familiar Timestamp Requests, Address Mask Requests, and Information Requests . Each of these techniques can deliver various findings that can add to the definitive live host list. Additionally, the tool allows you to choose the ports to be scanned, the techniques for UDP scanning (including Data, Data+ICMP, and static source port scanning), and the techniques for TCP scanning (including SYN, Connect, and static source port scanning).

The UDP Data scanning technique sends a data packet to the UDP port and, based on the response, determines whether the packet is open or closed. This method is incredibly accurate but it does require a valid nudge string to be known by the product. So if the UDP port is an esoteric service, you may not be able to detect it being open. Using the Data+ICMP technique takes the Data technique to the next level of accuracy, including a greatly enhanced traditional UDP scanning technique that sends multiple UDP packets to a presumed closed port. Then, based on the system's ability to respond with ICMP packets, it will create a window in which to scan the target port. This technique is incredibly accurate and will find all ports that are open, but it can take some time to complete. So be sure to plan for this added scanning time when selecting this option.

Some of the great new features in the latest release (version 4) include the following: a slider bar for CPU/resource utilization, the number of host and service discover passes , hostname lookups, banner grabbing, and Source IP scanning.

Additionally, version 4 has a Tools page (see Figure 2-5) that allows for a number of new functions, including Hostname/IP Lookup, Ping, ICMP Traceroute, Zone Transfer, Bulk Resolve, HTTP HEAD Request, HTTP GET Request, HTTPS GET Request, Whois, CRSNIC Whois IP, ARIN Whois IP, RIPE Whois IP, and APNIC Whois IP lookups.

Figure 2-5: The SuperScan tool provides a number of different assessment tools, many of which are discussed in other chapters.

WinScan

WinScan, by Sean Mathias of Prosolve (http://www.prosolve.com), is also a free TCP port scanner that comes in both graphical (winscan.exe) and command-line (scan.exe) versions. We routinely employ the command-line version in scripts because of its ability to scan Class C- sized networks and its easily parsed output. Using the Win32 version of the strings, tee, and tr utilities available from Mortice Kern Systems Inc.

(http://www.mks.com), the following Windows console command will scan a network for the well-known ports 0-1023 and spit the output into colon -delimited columns of IP_address : service_name : port_# pairs (line wrapped for legibility):

 scan.exe -n 192.168.7.0 -s 0 -e 1023 -f  strings  findstr /c:"/tcp"  tr 10 :  tr -s : :  tee -ia results.txt 

scan.exe's -f switch should not be used on slow links; otherwise, results may be unreliable. The results of our script look something like this:

 192.168.22.5:nbsession:139/tcp 192.168.22.16:nbsession:139/tcp 192.168.22.32:nbsession:139/tcp 

ipEye

Think you need Linux and nmap to perform exotic packet scans? Think againipEye from Arne Vidstrom, at http://ntsecurity.nu, will perform source port scanning as well as SYN, FIN, and Xmas scans from the Windows command line. The only limitations to this nifty tool are that it runs only on Windows 2000 and scans only one host at a time. Here's an example of ipEye running a SYN scan sourced on TCP port 20 in an effort to evade filter rules on a router, similar to the -g option of nmap (edited for brevity):

 C:\>  ipeye.exe 192.168.234.110 -syn -p 1 1023 -sp 20  ipEye 1.1 - (c) 2000, Arne Vidstrom ([e-mail])           - http://ntsecurity.nu/toolbox/ipeye/   1-52 [closed or reject]   53 [open]   54-87 [closed or reject]   88 [open]   89-134 [closed or reject]   135 [open]   136-138 [closed or reject]   139 [open] ...   636 [open]   637-1023 [closed or reject]   1024-65535 [not scanned] 

Because many router and firewall ACLs are configured to allow protocols such as DNS (UDP 53), the FTP data channel (TCP 20), SMTP (TCP 25), and HTTP (TCP 80) to move inbound through the filters, source port scanning can potentially evade such controls by masquerading as this type of inbound communications traffic. You must know the address space behind the firewall or router, however, which is often difficult if NAT (Network Address Translation) is involved.

WUPS

The Windows UDP Port Scanner (WUPS) hails from the same author (Arne Vidstrom at http://ntsecurity.nu). It is a reliable, graphical, and relatively snappy UDP port scanner (depending on the delay setting), despite the fact that it can only scan one host at a time for sequentially specified ports. It is a solid tool for quick-and-dirty single-host UDP scans, as shown in Figure 2-6.

Figure 2-6: The Windows UDP Port Scanner (WUPS) nails a system running SNMP (UDP

ScanLine

And now for a completely biased Windows port scanner recommendation, ScanLine from Foundstone is arguably the fastest, most robust port-scanning tool ever built. The tool has a myriad of options, but one of its most valuable is its ability to scan very large ranges quickly and to include both TCP and UDP scanning in a single run of the product. Take a look at this example:

 C:\ >sl -t 21,22,23,25 -u 53,137,138 192.168.0.1 ScanLine (TM) 1.01 Copyright (c) Foundstone, Inc. 2002 http://www.foundstone.com Scan of 1 IP started at Fri Nov 22 23:09:34 2002 ------------------------------------------------------------ 192.168.0.1 Responded in 0 ms. 1 hop away Responds with ICMP unreachable: No TCP ports: 21 23 UDP ports: ---------------------------------------------------------------------- Scan finished at Fri Nov 22 23:09:46 2002 1 IP and 7 ports scanned in 0 hours 0 mins 12.07 secs 

A complete breakdown of ScanLine's functionality can be seen in the help file dump:

 ScanLine (TM) 1.01 Copyright (c) Foundstone, Inc. 2002 http://www.foundstone.com sl [-?bhijnprsTUvz]    [-cdgmq ]    [-flLoO <file>]    [-tu [, ]]    IP[,IP-IP]  -?  - Shows this help text  -b  - Get port banners  -c  - Timeout for TCP and UDP attempts (ms). Default is 4000  -d  - Delay between scans (ms). Default is 0  -f  - Read IPs from file. Use "stdin" for stdin  -g  - Bind to given local port  -h  - Hide results for systems with no open ports  -i  - For pinging use ICMP Timestamp Requests in addition to Echo Requests  -j  - Don't output "-----..." separator between IPs  -l  - Read TCP ports from file  -L  - Read UDP ports from file  -m  - Bind to given local interface IP  -n  - No port scanning only pinging (unless you use -p)  -o  - Output file (overwrite)  -O  - Output file (append)  -p  - Do not ping hosts before scanning  -q  - Timeout for pings (ms). Default is 2000  -r  - Resolve IP addresses to hostnames  -s  - Output in comma separated format (csv)  -t  - TCP port(s) to scan (a comma separated list of ports/ranges)  -T  - Use internal list of TCP ports  -u  - UDP port(s) to scan (a comma separated list of ports/ranges)  -U  - Use internal list of UDP ports  -v  - Verbose mode  -z  - Randomize IP and port scan order Example: sl -bht 80,100-200,443 10.0.0.1-200 This example would scan TCP ports 80, 100, 101...200 and 443 on all IP addresses from 10.0.0.1 to 10.0.1.200 inclusive, grabbing banners from those ports and hiding hosts that had no open ports. 

Port Scanning Breakdown

Table 2-2 provides a list of popular port scanners, along with the types of scans they are capable of performing.

Table 2-2: Popular Scanning Tools and Features

Scanner UNIX	TCP	UDP	Stealth	Resource
strobe	X			ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/strobe-1.06.tgz
tcp_scan	X			http://wwdsilx.wwdsi.com/saint
udp_scan		X		http://wwdsilx.wwdsi.com/saint
nmap	X	X	X	http://www.inscure.org/nmap
netcat	X	X		http://packetstorm. securify .com/UNIX/utilities/nc110.tgz
Windows
netcat	X	X [*]		http://www.atstake.com/research/tools/nc11nt.zip
SuperScan	X			http:// members .home.com/rkeir/software.html
WinScan	X			http://www.prosolve.com
ipEye	X			http://ntsecurity.nu
WUPS		X		http://ntsecurity.nu
ScanLine	X	X		http://www.foundstone.com
[*] CAUTION: netcat UDP scanning never works under Windows, so don't rely on it.

Port Scanning Countermeasures

Detection Port scanning is often used by attackers to determine the TCP and UDP ports listening on remote systems. Detecting port scan activity is of paramount importance if you are interested in providing an early warning system to attack. The primary method for detecting port scans is to use a network-based IDS program such as Snort.

Snort (http://www.snort.org) is a great free IDS, primarily because signatures are frequently available from public authors. As you may have guessed by now, this is one of our favorite programs, and it makes for a great NIDS. (Note that 1. x versions of Snort do not handle packet fragmentation well.) Here is a sample listing of a port scan attempt:

 [**] spp_portscan: PORTSCAN DETECTED from 192.168.1.10 [**] 05/22-18:48:53.681227 [**] spp_portscan: portscan status from 192.168.1.10: 4 connections across      1 hosts: TCP(0), UDP(4) [**] 05/22-18:49:14.180505 [**] spp_portscan: End of portscan from 192.168.1.10 [**] 05/22-18:49:34.180236 

From a UNIX host-based perspective, several utilities, such as scanlogd (http://www.openwall.com/scanlogd) from Solar Designer, will detect and log such attacks. In addition, Psionic PortSentry from the Abacus project (http://www.psionic.com/abacus) can be configured to detect and respond to an active attack. One way of responding to a port scan attempt is to automatically set kernel filtering rules that add a rule to prohibit access from the offending system. Such a rule can be configured in the PortSentry configuration file and will vary from system to system. For a Linux 2.2. x system with kernel firewall support, the entry in the portsentry.conf file looks like this:

 # New ipchain support for Linux kernel version 2.102+ KILL_ROUTE="/sbin/ipchains -I input -s $TARGET$ -j DENY -l" 

PortSentry complies with and works under most UNIX flavors, including Solaris. It is important to remember that if you begin to see a pattern of port scans from a particular system or network, it may indicate that someone is performing network reconnaissance on your site. You should pay close attention to such activity, because a full-scale attack may be imminent. Finally, you should keep in mind that there are cons to actively retaliating against or blocking port scan attempts. The primary issue is that an attacker could spoof an IP address of an innocent party, so your system would retaliate against them. A great paper by Solar Designer can be found at http://www.openwall.com/scanlogd/P53-13.gz. It provides additional tips on designing and attacking port scan detection systems.

Most firewalls can and should be configured to detect port scan attempts. Some do a better job than others in detecting stealth scans. For example, many firewalls have specific options to detect SYN scans while completely ignoring FIN scans. The most difficult part in detecting port scans is sifting though the volumes of log files; for that we recommend Psionic Logcheck (http://www.psionic.com/abacus/logcheck). We also recommend configuring your alerts to fire in real time via e-mail. Use threshold logging where possible, so that someone doesn't try to perform a denial of service attack by filling up your e-mail. Threshold logging will group alerts rather than send an alert for each instance of a potential probe. At a minimum, you should have exception-based reporting that indicates your site was port scanned. Lance Spitzner (http://www.enteract.com/<126>lspitz/intrusion.html) has created a handy utility for FireWall-1 called alert.sh, which detects and monitors port scans via FireWall-1 and runs as a user-defined alert.

From the Windows perspective, one utility can be used to detect simple port scans called Genius 2.0 by Independent Software (Genius 3.2.2 is available at http://www.indiesoft.com) for Windows 95/98 and Windows NT/2000/2003. The product offers much more than simple TCP port-scanning detection, but its inclusion on your system tray is justified for that single feature. Genius will listen to numerous port-open requests within a given period and warn you with a dialog box when it detects a scan, giving you the offender's IP address and DNS name:

Genius' port scan-detection feature detects both traditional TCP connect and SYN scans.

Prevention Although it is difficult to prevent someone from launching a port scan probe against your systems, you can minimize your exposure by disabling all unnecessary services. In the UNIX environment, you can accomplish this by commenting out unnecessary services in /etc/inetd.conf and disabling services from starting in your startup scripts. Again, this is discussed in more detail in Chapter 5 for UNIX.

For Windows, you should also disable all services that are not necessary. This is more difficult because of the way Windows operates, as TCP ports 139 and 445 provide much of the native Windows functionality. However, you can disable some services from within the Control Panel Services menu. Detailed Windows risks and countermeasures are discussed in Chapter 4. For other operating systems or devices, consult the user's manual to determine how to reduce the number of listening ports to only those required for operation.