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
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.