next up previous
Next: Examples of TCP Normalizations Up: A Systematic Approach Previous: A Systematic Approach

   
The IP Identifier and Stealth Port Scans

The IP identifier (ID) of outgoing packets may give away information about services running on internal hosts. This issue is not strictly a normalizer problem, but the normalizer is in a location well suited to deal with the issue.

One particular problem is the exceedingly devious stealth port-scanning technique described in [16,18], which enables an attacker to probe the services running on a remote host without giving away the IP address of the host being used to conduct the scan. Figure 4 illustrates the technique, which we review here to develop how a normalizer can thwart it. Host A is the attacker, V is the victim, and P is the patsy. The patsy must run an operating system that increments the IP ID by one2 for every packet sent, no matter to what destination--many common operating systems use such a ``global'' IP ID.

Host A continually exchanges packets with host P, either through a TCP transfer or simply by pinging it. While doing this, the IP IDs of the responses from P to A normally increment by one from one packet to the next. Now A fakes a TCP SYN to the port on V they wish to probe, and they fake the source address of the packet as being from P.

If there is no service listening on the port, V sends a RST to P. As P has no associated connection state, P ignores the RST, and there is no effect on the IP IDs of the stream of packets from P to A.


  
Figure 4: Stealth Port Scan
\begin{figure}
\centerline{\psfig{figure=stealth.ps,width=3.1in}}
\vspace{.05in}\end{figure}

However, if there is a service listening on the port, V sends a SYN-ACK to P to complete the connection, rather than a RST. P has no state for this connection, and promptly sends a RST back to V. In so doing, the global ID sequence on P increases by one; consequently, in the stream of packets from P to A, the attacker observes a step of two (rather than one) in the ID sequence, since it missed one of the packets sent by P, namely the RST from P to V.

Thus P and not A appears to be the host conducting the port-scan, whereas in fact it is completely innocent. V never sees a packet with a source of A. If A chooses a different patsy for every port it wishes to check, then this port scan is very hard to detect.

The solution for patsies is for the normalizer to scramble (in a cryptographically secure, but reversible fashion) the IP IDs of incoming and outgoing packets. This prevents internal hosts from being used as patsies for such scans. The effect on semantics is that any diagnostic protocol that reports the IP IDs of incoming packets back to the sender may break. ICMP messages can still function if the normalizer applies the unscrambling to the embedded ID fields they carry.

The solution for victims is to use the ``reliable RST'' technique (see § 6.1 below). The normalizer transmits a ``keep-alive'' acknowledgment (ACK) packet behind every RST packet it forwards out of the site. When the ACK arrives at the patsy, the patsy will reply with a RST, just as it does in the SYN-ACK case. Consequently, the IP ID sequence as seen by the attacker will jump by two in both cases, whether the victim is running the given service or not.

Sending keep-alives for reliable RSTs generates extra traffic, but has no effect on end-to-end semantics, since the keep-alive ACK following the RST is guaranteed to be either rejected by the victim (if it first received the RST) or ignored (if the RST was lost and the connection remains open).


next up previous
Next: Examples of TCP Normalizations Up: A Systematic Approach Previous: A Systematic Approach
Vern Paxson
2001-05-22