ScanLine

---

Of all the Windows port scanners discussed so far, only one of them does UDP scans. ScanLine, formerly called FScan, from Foundstone, Inc., is a free Windows command-line port scanner that will do UDP, TCP, and Ping scans. It is available from http://www.foundstone.com/resources/scanning.htm.

Implementation

ScanLine’s biggest advantage, other than being free and working on all Windows variants, is that it performs UDP scanning. As with any UDP scanner, packet filters running on or in between the target host might keep your results from being accurate. However, ScanLine tries to optimize its UDP scanning by first sending UDP packets to a port that shouldn’t have anything on it (ScanLine chooses UDP port 1 by default). If it does not receive an ICMP “port unreachable” message, it assumes that a packet filter or firewall is blocking responses, meaning it can’t accurately scan the host. By using this method, ScanLine will not report a UDP port as “open” unless it is truly open—however, it will miss any open UDP ports on a host if it fails the UDP port 1 test.

Note 

Because of a Winsock implementation issue on Windows 9x/Me, the network stack on these systems won’t register ICMP port unreachable messages. This means that if you’re running ScanLine on this platform, all of your UDP scans will come up empty. You’ll need to run ScanLine on a Windows NT/200x/XP box to perform UDP scans.

The following screen shows a UDP scan of an unfiltered machine on ports 130–140, looking for NetBIOS services. You can see that 192.168.1.101 has some of the typical NetBIOS ports open (UDP ports 135, 137 and 138).

Everything else about ScanLine is similar to nmap and other scanners out there. You can use –b to retrieve banners, or responses, from the ports to which you connect, as shown in the following illustration:

ScanLine has vastly improved on the original Fscan tool. The original Fscan’s banner grabbing capabilities were limited, as it was unable to negotiate telnet options or retrieve the HTTPD banner by using an HTTP GET request to make the server respond. ScanLine is able to do both to give you more information.

Note 

Some web servers don’t require an HTTP GET command to return information. The web server running on the Linksys EtherFast Cable/DSL Router, for example, will return HTTP information simply by sending a carriage return/linefeed.

You can use –c, –d, and –q to control standard timeout values. You can specify IP addresses in comma-separated lists and ranges (such as 192.168.1.1,192.168.1.100-192 .168.1.102), as well as ports (such as –t 21-23,80 or –u 137-138,514). This table shows ScanLine’s command-line arguments.

Command-line Argument	Description
-?	Shows the help text and command-line arguments
-b	Get port banners
-c <time>	Timeout for TCP and UDP attempts in milliseconds(default is 4000 ms)
-d <time>	Delay between scans in milliseconds (default is none)
-f <file>	Read IPs from file; use “stdin” for standard input
-g <port>	Use the specified local port as the source port when performing scans
-h	Hide results for systems with no open ports
-i	Use ICMP timestamp requests in addition to echo requests
-j	Don’t output separators between IPs
-l <file>	Read TCP ports from <file>
-L <file>	Read UDP ports from <file>
-m <ip>	Bind to given local interface IP as the source address when performing scans
-n	Don’t scan any ports; Ping only
-o <file>	Output results to file (overwrite)
-O <file>	Output results to file (append)
-p	Do not Ping hosts before scanning
-q <time>	Timeout for Pings in milliseconds (default is 2000 ms)
-r	Resolve IP addresses to hostnames
-s	Output in comma separated format (csv)
-t <ports>	TCP port(s) to scan (a comma separated list of ports/ranges)
-T	Use internal list of TCP ports
-u <ports>	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

Case Study: Banner Identification

Gathering information about operating systems didn't used to be as difficult as it can be today. A few years back, users, programmers, and system administrators weren't so paranoid and security conscious. When a user would telnet to a remote host, along with a login prompt the host would tell the user its hostname, the type and version of the operating system, and even perhaps its geographic location—all without the user first supplying a valid username and password.

Unix operating systems were fond of divulging their life stories with a simple TCP connection to a telnet server. People could gather information about hosts on a network by obtaining a list of IP addresses alive on that network (possibly by using fping) and starting a TCP connection on port 23 to each host to capture the responses. They could also try to grab lists of users from systems using Finger. Today, many admins don't allow their network applications to announce quite so much information about the underlying OS without some kind of authentication or authorization being established first. However, application-specific version information is still obtainable.

Telnet has all but been replaced by Secure Shell (SSH). When an SSH connection is made, the server will spit out what version of the SSH protocol it's running without requiring any input from the client. The server usually expects the client to identify itself with its version of the SSH protocol. These version exchanges are often necessary in client/server communications to ensure that both sides are speaking the same language. Therefore, the disclosure of application-specific version information is often unavoidable. Using a mail client to connect to a mail server or a web client to connect to a web server won't necessarily get you this information. But using a program such as Telnet or Netcat to make a TCP connection directly to a mail or web server will usually allow you to obtain information you normally wouldn't see using the clients built to interact with that server.

Let's try a few of these. First, let's see if my Linux box is nice enough to tell us what version of FTP server it's running (if it's running one).

[bjohnson@originix ~]$ telnet 192.168.1.50 21 Trying 192.168.1.50... Connected to 192.168.1.50. Escape character is '^]'. 220 originix FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready

Not only did originix tell us the version of FTP it's running, but it was also nice enough to tell us the date it was built. Noting that this is fairly old, chances are this version has a few vulnerabilities that might be exploited by an intruder. Note this as a possible weakness. This technique is called banner grabbing, and it is done by many port scanners (including Foundstone's SuperScan and ScanLine) as part of the process. Let's see what the web server has to say:

[bjohnson@originix ~]$ telnet 192.168.1.50 80 Trying 192.168.1.50... Connected to 192.168.1.50. Escape character is '^]'. GET / HTTP     HTTP/1.1 200 OK Date: Tue, 29 Jan 2002 07:18:07 GMT Server: Apache/1.3.14 (Unix)  (Red-Hat/Linux) Last-Modified: Sat, 05 Aug 2000 04:39:51 GMT ETag: "3a107-24-398b9a97" Accept-Ranges: bytes Content-Length: 36 Connection: close Content-Type: text/html     I don't think you meant to go here. Connection closed by foreign host.

This was a little trickier. When we first made the connection, the web server answered (indicating that something was indeed running on the web port), but then it just sat there, as if it was waiting for something from us. Normally, web clients request HTML pages from a web server. With a little research on HTTP, I found out that I needed to send a GET request to the server (followed by two presses of the ENTER key) to obtain any meaningful information. By doing that, I could see the details of the HTTP header that are normally hidden by a web client. This server appears to be running version 1.3.14 of Apache. Oh…and look at that! It also told us that it's running on RedHat Linux!

Just for the heck of it, let's see what kind of banner we get when we telnet to this host's telnet server:

[bjohnson@originix ~]$ telnet 192.168.1.50 23 Trying 192.168.1.50... Connected to 192.168.1.50. Escape character is '^]'. Dobbylan Linux release 8.1 (Cauliflower) Kernel 2.5.38-02 on an i986 login: telnet close Connection closed. [bjohnson@originix ~]$

Dobbylan Linux? Kernel 2.5? i986? None of this makes sense. This last telnet teaches us an important lesson; don't necessarily trust the information that these banners provide. For example, by editing the /etc/issue.net file on a RedHat Linux 6.1 box, we were able to change the telnet banner into nonidentifiable gibberish. The web server, however, still spilled the beans about our running RedHat. Some network application banners can be modified only by changing the actual source code, but that is usually not hard to do. BIND, one of the most popular DNS server packages, can have its version string altered by specifying a version directive in the options section of the named.conf file.

Deceit is an important tool at every defender's disposal. Every attacker always has to wonder if the information he or she is gathering is accurate. With the proper tools and skill sets, an operating system's network stack could even be modified specifically to make it look like a different operating system! This is somewhat complicated, so don't expect to see this happen often. But it's possible, and the possibility is enough to make an attacker always second guess the validity of the available information.

---