Understanding Stealth Scans: Forewarned is Forearmed


If you stay connected to the Internet, you will be scanned. It's a fact

of life. If you have a continuous connection, someone with bad

intentions'll scan you regularly, quite often. 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.

Free Course: JavaScript: The Good Parts
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies