If your organization’s intrusion detection system (IDS)
identifies a scan of your network, and you just block that IP address, you
likely haven’t addressed the real threat to your network. Black hats employ
several stealth scanning techniques, and one of those threats is the idle scan.

Idle scanning is a procedure that involves scanning TCP
ports. An attacker will probe a public host with SYN|ACK (synchronization
acknowledgement) and receive an RST (reset the connection) response that has
the current IPID (IP identification) number. The attacker will then send a SYN
(synchronization) request packet to the port of his or her target with a source
IP of the public host.

If the port is open, the target will send a SYN|ACK packet
to the public host. The public host will then send an RST packet to the target
and increment the IPID.

If the port is closed, the target will send an RST packet to
the public host indicating that the port is closed. The attacker will then send
another SYN|ACK packet to the public host and look at the IPID number to
determine if sending an RST packet to the target incremented the IPID.

After several hundred of these bogus session requests, your
IDS will realize that something is scanning the network, and you’ll eventually
block the public host. But even though you didn’t identify the attacker, the
intruder still managed to map your network.

This preemptive probe becomes an even greater problem if the
public host used to scan your internal network is one of the trusted machines
that sits in front of your firewall. However, you can protect your network from
this type of scanning technique.

The best defense against idle scanning is to follow these
simple best practices:

  • Don’t
    put a public host in front of your firewall that uses a predictable IPID
    sequence. Solaris and Linux are two operating systems that aren’t
    vulnerable to this type of behavior. UNIX/Linux is a much more stable and secure platform for your Web site.
    Learn UNIX, and replace the Windows box that sits outside your firewall.
  • Use a
    firewall that can maintain state-on connections, determine whether someone
    initiated a phony session request, and drop those packets without a target
    host response. If your firewall doesn’t maintain state-on connections, your network
    really just has a “speed bump”—not a firewall.
  • Use an
    ingress filter on your network to ensure that no packets enter your
    outside boundary with a source address of your internal network.
  • Use an
    egress filter on your network to ensure that no packets leave your network
    with a source address that isn’t a part of your internal network.

If you don’t use ingress and egress filtering, you’re an
easier target for black hats and wannabes on your own network to attack the
rest of the Internet.

Final thoughts

New scanning techniques will continue to evolve and bombard
your network, probing for holes and weak spots in your security. It’s up to you
to continue to use best practices to defend your organization’s systems.

Miss a column?

Check out the Security Solutions Archive,
and catch up on the most recent editions of Mike Mullins’ column.

Worried about security issues? Who isn’t? Automatically
sign up for our free Security Solutions newsletter, delivered each Friday,
and get hands-on advice for locking down your systems.

Mike Mullins has served as an assistant
network administrator and a network security administrator for the U.S. Secret
Service and the Defense Information Systems Agency. He is currently the
director of operations for the Southern Theater Network Operations and Security
Center.