If you stay connected to the Internet, you will be scanned. It's a fact of life. If you have a continuous connection, you'll be scanned regularly, quite often by someone with bad intentions. This week's column is a basic primer on scanning: what it is, why it's done, and the wonderful world of "secret handshakes" and stealth scans.

Scanning a system, or a network, is normally done in order to find out what services are available. But remember, there are two groups who do it regularly. The good guys -- system administrators and network security folk -- do it to see what is exposed and thus vulnerable to attack. The bad guys -- script kiddies and worse -- do it to see what is exposed and thus vulnerable to attack. Funny, that is.

Scanning is like going up to an apartment building and knocking on each door to see who is home. Are you running a Web server? A mail server? BIND? Telnet? FTP? RPC? Those are the questions that scanning answers. Unfortunately, the answers often reveal enough about your system to allow an uncouth visitor unauthorized access.

I'm not talking about The Lone Gunmen kind of kung fu hackers. I'm talking about someone with no greater skills than those possessed by a high-school (or junior high-school) student who knows how to download text and programs from the Net. A script kiddie who has found an exploit that can gain access to any system running the right platform and application. In addition to one of the thousands of widely published exploits available on the Net, the attacker may also have downloaded a port scanner, perhaps something as old as the freely available version of ISS or as new as Beta 22.1 of NMAP 2.54. If the attacker can find a match for a known exploit on your system, as happens all the time to novices and professionals alike, it's all over. They own you. And scanning is not even illegal. It's "casing the joint," not robbery.

As people have become increasingly aware of the risks involved in advertising to the world exactly what services they have running while connected to the Net, scanners have had to become sneakier. It's no longer a matter of downloading ISS (one of the earliest port scanners available), pointing it at potential victims, and letting it try to connect to every port from one to whatever.

The problem for the bad guys is that your machine usually logs each connection that a scanner makes. Perhaps the most naive and unsophisticated script kiddies don't realize that they are leaving their fingerprints behind when they scan a system, but they should. There are many ways to avoid being quite so conspicuous. For example, many attackers run scans remotely from "owned" machines. That way telltale traces don't lead directly to the culprit, but instead simply point out another victim. Machines that are "owned" are valuable enough to the bad guys not to be revealed unnecessarily, so even when the scan is coming from such a site, it makes sense to try not to leave any tracks. "Stealth scans" are yet another way to avoid detection, or at least to make it a little more difficult. Stealth scans do their work without ever making a connection.

To understand what stealth scans are and how they work, you first have to understand a little bit about packets and TCP/IP's "secret handshakes." In addition to carrying the IP address and port number of the recipient and sender, the TCP header also contains a sequence number and some special-purpose flags. I'll only mention three of the flags -- SYN, ACK, and FIN -- as they are the only ones germane to this discussion. For more detail on the header format you can find the complete specification in RFC 793 (see Resources for a link). The "secret handshakes" I mentioned are perhaps unknown only to the uninitiated. Documentation for them is also in RFC 793.

The handshakes occur when the systems say hello and when they say goodbye. Let's start by looking at the three-way handshake used by TCP/IP to establish a connection. Connection in this context means establishing a link between an IP address and port number at each end. The three-way handshake, the first thing that happens when you want to surf a Website, telnet to another box, or FTP files, is designed to create such a connection.

It works like this. In the first part of the handshake, one computer asks another to establish a connection. It does this by sending a SYN request, meaning that the SYN flag I mentioned above is turned on. The message itself says something like this: "Hey, listen up. I want to talk with the service listening on port X, so let's get in synch. I will start the connection using sequence number Y." Port X identifies the type of connection and the service, desired. For a list of the "well-known" TCP/IP services and their ports, take a look at the list of services and their port numbers in /etc/services. Every message between the two computers carries a sequence number from the sending site. The sequence number allows both ends to know that they are still in synch, and alerts them if they have dropped a message or received it out of sequence.

Two things happen in the second part of the handshake. The machine receiving the SYN request acknowledges the sequence number sent by the other party by turning on the ACK flag. It also provides its own starting sequence number. Sort of like saying, "Ack! I got your number, baby. Here's mine!"

At this point, the computer initiating the conversation considers it to be established. The other computer doesn't, and won't until it receives an ACK (acknowledgement) for its own sequence number. The session is considered "half open" because one side thinks it's established but the other doesn't. If the originator never completes the handshake, well, the connection is never made, and because it isn't made, the attempt never gets logged.

Finally, the system originating the connection acknowledges that it got the starting sequence number of the other. Now we have a connection established at each end, and each end is defined as a machine (the IP address) and a service (the port number). We're good to go.

A similar handshake occurs when it's time to say goodbye. When one side or the other has no more data to send, it sends a message with the FIN flag turned on to notify the other end of that. The side receiving the FIN may or may not have more data, but in either case it acknowledges receipt of the FIN. When it has finished with everything it has to send, it turns on its own FIN signal, and when the other side acknowledges it, the connection is cleared.

The FIN stealth scan sends its target a FIN message for a connection that doesn't exist. The target replies with an error message if the service is not available, but simply ignores the message if it is. Thus the scanner's question, "Do you run X?" is answered, but not logged.

There are two other tricky scans worth mentioning. One is called the Christmas Tree scan because it has all the flags -- not just SYN, ACK, and FIN -- lit up at once. The other is called a NULL scan because none of the flags are turned on. These handcrafted sneaky scans result in different error responses depending upon the platform the receiving end is running.

Modern port scanners like NMAP take advantage of stealth measures like those to find out what's up on a system. NMAP is probably not only the best-known but also the best-performing of such tools, and it is widely used by both system admins and those with bad intentions. I've just downloaded the latest NMAP beta and will write about it next week.