Network probes are important clues in detecting intrusions. In this article, Lawrence Teo explains two common network probes and what can be done to detect them.
Almost any system administrator of a large network will tell you that their network has been probed before. As cracking tools become more popular and increase in number, this trend is likely to continue. Although network probes are technically not intrusions themselves, they should not be taken lightly—they may lead to actual intrusions in the future. As the saying goes, better be safe than sorry. In this article I'll explain the concepts behind two common network probes, as well as how they're performed and what can be done to detect them.
The most common type of network probe is probably the port scan. A port scan is a method used by intruders to discover the services running on a target machine. The intruder can then plan an attack on any vulnerable service that she finds. For example, if the intruder finds that port 143 (the IMAP port) is open, she may proceed to find out what version of IMAP is running on the target machine. If the version is vulnerable, she may be able to gain superuser access to the machine using an “exploit” (a program that exploits a security hole).
A port scan is actually very simple to perform. All we have to do is to connect to a series of ports on the machine and find out which ports respond and which don't. A simple port scanner can be written in under 15 minutes by a good programmer in a language such as Java or Perl. However, this kind of port scan is easily detectable by the operating system of the target machine. Listing 1 shows the traces produced by such a port scan in a log file (usually /var/log/messages) on a Linux box. Notice that a series of connections to various services occurred in a short span of three seconds. Since it's so easily detectable, most intruders will not run this kind of port scan against a machine these days.
Another sneakier, “stealthier” kind of port scan is called the “half-open” SYN scan. In this scan, the port scanner connects to the port but shuts down the connection right before a full connection occurs (hence the name “half-open”). Since a full connection never happened, the operating system of the target machine usually does not log the scan. This concept will be clearer if you're familiar with the inner workings of TCP/IP. In a normal TCP/IP connection, two devices need to complete a three-way handshake before initiating transmission. In a “half-open” SYN scan, the three-way handshake is never completed—the port scanner judges whether the port is open by the response given by the target machine.
Now that we've covered the basic concepts of port scanning, let's talk about the most popular and powerful network probing tool available today—Nmap (Network Mapper). Nmap is capable of conducting both types of port scans that I've discussed so far. It's also capable of performing other kinds of probes—some of which I'll cover later. Listing 2 shows a typical Nmap scan against a machine.
Now (you might be thinking) if “stealth” port scans are possible, how are we supposed to detect them? The good news is that such port scans are detectable using special tools. Solar Designer has developed such a tool called scanlogd, which is a dæmon that runs in a background and listens on the network interface for port scans. If a port scan is detected, scanlogd writes one line describing the scan using the syslog mechanism. Listing 3 shows a scan detected by scanlogd.
There are other tools that can detect port scans as well. I'll not cover them in this article, however. If you're interested, you can check out the Resources section at the end of this article. You might in particular want to check out tcplogd, a configurable TCP port scan detector (you can specify what kind of packets to log, avoid flooding and specify trusted hosts with it).
A ping sweep is another kind of network probe. In a ping sweep, the intruder sends a set of ICMP ECHO packets to a network of machines (usually specified as a range of IP addresses) and sees which ones respond. The whole point of this is to determine which machines are alive and which aren't. It's a bit like knocking on your neighbors' doors at 3 a.m. to see who's asleep and who's not (okay, don't try that). Once the intruder knows which machines are alive, he can focus on which machines to attack and work from there. Note that there are legitimate reasons for performing ping sweeps on a network—a network administrator may be trying to find out which machines are alive on a network for diagnostic reasons.
fping is a tool that can be used for conducting ping sweeps. fping takes a list of IP addresses and sends ping packets to them. Unlike normal ping, fping sends one ping packet to one IP address, and then proceeds immediately to the next IP address in a round-robin fashion. Listing 4 shows a simple Perl script that is used to generate a list of Class C IP addresses (192.168.0.1 to 192.168.0.20, in our example). Listing 5 shows how that Perl script can be used in conjunction with fping to discover which machines in that IP address range are alive on the network. The -a switch is used to show only machines that are alive without it (fping will show machines that are unreachable as well).
Like port scans, ping sweeps are detectable using special tools as well. ippl is an IP protocol logger that can log TCP, UDP and ICMP packets. It is similar to scanlogd, where it sits in the background and listens for packets. Listing 6 shows a line in the log file that demonstrates a ping packet being intercepted by ippl. Be careful when using ippl though—if you're on a busy Ethernet network, you might find that your ippl log files (usually at /var/log/ippl/*) may fill up rather quickly.
There are other ping detection tools available besides ippl—unfortunately, I haven't been able to look at them in detail. One that caught my interest was pingd, which is a userland dæmon that handles ICMP traffic at the host level. One neat feature of pingd is that it integrates with TCP Wrappers to allow you to specify who can ping you and who can't in TCP Wrappers' access control files (/etc/hosts.allow and /etc/hosts.deny).
Port scans and ping sweeps are just two of many types of network probes. Current network-probing tools have matured significantly. Their continued development and availability means that system administrators will see more interesting probe patterns in the future.
To examine some of these other network probes, let's go back to Nmap. Nmap is able to perform decoy scans. When such a scan occurs, you'll see scans from unique IP addresses on your system, but you won't be able to pick out which one is the real IP address that scanned you. The point of this is to confuse the system administrator, of course.
Besides decoy scans, Nmap also has the ability to remotely identify the operating system running on the target machines. This is done using a technique called TCP/IP stack fingerprinting. We have already seen this in Listing 2, where Nmap correctly identified my target machine as running Linux 2.1.122 - 2.2.14 (my machine was actually running 2.2.12). At the time of writing, the current version of Nmap (2.53) is capable of identifying 465 different versions of operating systems, routers and other devices. Such ability is useful for the intruder because it enables the intruder to identify the weaknesses on a machine since security holes are usually operating system-specific.
If you're interested in other kinds of probe patterns, I highly recommend that you read Stephen Northcutt's book (see Resources). Fyodor's articles on port scanning and TCP/IP stack fingerprinting in Phrack magazine are also interesting.
I hope that this article has been useful to you in understanding two common network probes and how they can be detected. However, security, as always, is an ongoing process. Network probes are going to increase, new security holes are going to be discovered and you'll definitely read about these things in the news almost every day. It pays to be up-to-date. For that reason, I recommend that you subscribe to a security mailing list (BUGTRAQ is highly recommended!) or visit newsgroups and security-related web sites frequently.
