Udp_scan

---

Udp_scan is part of the old SATAN tool. It is a command-line UDP-only scanner for Unix. It can be downloaded separately from SATAN with its TCP scanning partner, tcp_scan, at ftp://ftp.porcupine.org/pub/security/port-scan.tar.gz. Udp_scan is reliable, but like another Unix TCP-only scanner called strobe, it has all but been overshadowed by newer tools. Although it is considered to be one of the ancient tools, its technique was the basis for just about all other UDP scanning tools.

Unix TCP-only scanner called strobe, it has all but been overshadowed by newer tools.Although it is considered to be one of the ancient tools, its technique was the basis for just about all other UDP scanning tools.

Installation

Like most Unix programs, udp_scan comes in source code. After you download and untar port-scan.tar.gz, you’ll need to change to the port-scan directory and run the make command.

Note 

Linux users need to run the command make CFLAGS=-D_BSD_SOURCE to get udp_scan to build.

Implementation

Udp_scan’s usage is very simple; give it an IP address and a range of ports and let it do its thing.

# ./udp_scan 192.168.1.102 1-1024 137:netbios-ns: 138:netbios-dgm: 445:UNKNOWN: 500:UNKNOWN

Behind the scenes, udp_scan uses the same technique used by ScanLine to optimize its scanning routines. Before it does anything, udp_scan sends a UDP packet to UDP port 1 (by default) on the target host. It then waits to receive an ICMP port unreachable error. If it gets none, it assumes the target host is dead (even though a firewall may just be blocking the ICMP error) and doesn’t continue the scan. The UDP test port 1 can be changed to any port using the –p <port> option. The test port should always be a UDP port that is not being used by any service on the target host.

Tip 

Sometimes udp_scan won’t be able to report properly on down hosts. If the target host’s IP address is on your local network but its MAC address isn’t in your ARP cache, udp_scan can time out while waiting for a response to the ARP lookup broadcasts. Udp_scan will appear to hang and output nothing instead of reporting that the host appears to be down as it normally would.

Udp_scan carefully watches its performance as it works through the port scan. By default, it can open up to 100 simultaneous UDP connections. (You can change this upper limit by specifying a –l <max_connections> option on the command line.) It uses the round-trip travel time for packets, determined by the initial test port probe, to calculate the maximum number of simultaneous probes that the network can handle. Every UDP packet sent by udp_scan contains only one data byte (the character 0) in an effort to minimize bandwidth usage while obtaining the most accurate results. Some UDP services and port filters respond differently to UDP packets with zero data bytes than UDP packets with an actual data payload.

You can use only a few other options with udp_scan. The –a option tells udp_scan to print out all the errors it encounters as well as the reachable UDP ports. The –u option tells you about any ICMP host unreachable errors it receives, printing the number of the UDP port that returned the error. On the other hand, the –U option tells you the exact opposite, printing the ports that do not return ICMP host unreachable errors. The only other thing you can specify to udp_scan is a source UDP port to use, by indicating –s <source_port> on the command line.

Udp_scan has a few limitations. Because it uses raw ICMP sockets, udp_scan can be run only as root or with super user privileges (uid 0). Also, like WUPS, it can handle only one IP address at a time.

Case Study: OS Fingerprinting

Excluding those few tricky systems whose admins took the time to build in traps, most systems are sold as “turnkey” solutions and are simply taken out of the packaging, plugged in, and turned on without much modification and without turning off any of the default services. A port scan of a system in this state will return an “out-of-the-box” port map that can most likely be matched to a particular OS. If you port scan a known unmodified system and then use that as comparison to port scans on unknown hosts, you can often find close or even exact matches, revealing the identity of the remote OS.

Most systems won't be identifiable by their “map of ports.” However, just as a person's accent when he or she talks can identify from what geographic region that person hails, the way a system speaks TCP/IP can be an identifying marker. The actual specifications of the TCP/IP protocol are laid out in a set of documents called RFCs (Request For Comments). The documents outline the structure of the actual data packets and how network stack implementations should package, transmit, receive, and unpack data packets.

The specifications and standards set out in these documents are meant to be the guidelines for people writing and designing network stack OS-level software. By following these specifications, designers and writers can ensure that their network stack will be able to communicate with everyone else's network stack.

However, as with any well-written protocol, both TCP and IP leave room for future expansion and special handling of packets. Both IP and TCP have room at the end of their headers for things called options. The option fields allow the TCP/IP implementation to store optional information in the packet headers that might be useful to other TCP/IP implementations upon receipt of those packets. Because this area of the packet structure is so loosely defined, it leaves each TCP/IP stack developer a little room to be creative. One vendor might use and respond to certain options, while other vendors might choose completely different sets of options. As each vendor comes up with its own use and handling of these header fields, each vendor's stack begins to exhibit its own kind of digital signature or fingerprint.

A particular TCP/IP stack can be linked to a particular vendor in even more ways. IP packets must contain a 16-bit identification field. Other than stating that these numbers must be unique, nothing is laid out in the RFCs about how these numbers must be chosen (other than the byte-size limitation of the field). Also, TCP packets must contain similar information in their headers (referred to as sequence numbers). Sequence numbers help TCP keep track of the connection. Each side of a TCP connection chooses its initial sequence numbers at the beginning of a connection. A method for choosing that initial sequence number is suggested in the specification; however, it can still be chosen by the developer as long as the numbers don't often repeat themselves (otherwise TCP connections could easily get mixed up). These are two more areas for customization and flexibility within a TCP/IP stack implementation. Each vendor's implementation can be analyzed for patterns, providing more ways to fingerprint a particular OS by its network traffic. Nmap uses this technique to make reasonable guesses at the operating system being run on each host it scans.

Other protocols within the TCP/IP can be used to identify an operating system. Most TCP/IP stacks come with their own Ping utilities. Internet Control Message Protocol (ICMP) echo messages have room for optional data, which allows the user to use different sized ICMP echo messages to see how larger data packets are handled. When a user indicates a data size for the echo message, the Ping utility must then pad the message with the appropriate amount of data. It may fill the data field with all zeroes, it may use a repeated string of alphanumeric characters, or it may use random digits. The point is that every Ping implementation has the option of padding its data field with whatever it wants. If you know what method a particular OS's Ping uses, you can identify it just by watching how it Pings a host.

By examining such things as TCP sequence numbers, IP ID numbers, TCP timestamps, TCP options, and IP fragmentation handling, an OS can be identified using its network stack. Check out Fyodor's paper on Nmap Remote OS Detection at http://www.insecure.org/nmap/nmap-fingerprinting-article.html.

---