|
NNSquad NNSquad Network Measurement Agent NNSquad Network Measurement Agent (NNMA) Spoofed Reset Detection Methodology John Bartas (jbartas@speakeasy.net) Lauren Weinstein (lauren@vortex.com) May, 2008 Introduction to Terminating Network
Connections TCP connections are normally presumed to terminate via the two endpoint systems exchanging FIN packets. However, sometimes one or both endpoints instead sends a reset (RST) packet as part of a termination sequence. In these cases, the reset packets fulfill a useful purpose from the standpoint of the end user -- they indicate that the other peer will not continue the connection and that it is wasteful (and useless) to send any more packets. Since resets can and do occur legitimately in this manner, simply counting reset packets in an attempt to detect "spoofed" packets being injected into the data stream by ISPs is ineffective and may easily yield misleading results. "Spoofed" (some observers prefer the term "forged") resets are those injected into an existing data stream by a suitably positioned third-party (e.g. an ISP), with the goal of terminating the connection prematurely against the wishes of the endpoints. These resets are referred to as "spoofed" since this term has long been used to label network packets containing false source IP addresses in the context of various other forms of network attacks. Spoofing is used to fool the receiving endpoint system into treating the packet as though it came from the other endpoint of the TCP connection, when in fact it did not. We wish to determine whether any given reset packet is legitimate (generated by an endpoint) or spoofed (injected by an intermediary entity using a falsified source IP address). Detecting the Spoofs Successfully and accurately detecting a spoofed reset packet involves finding ways in which spoofed resets differ from legitimate resets. For a spoofed reset to be effective in its disruptive purpose, various fields in the TCP and IP headers must contain the exact values expected by the receiver, including TCP ports, SYN numbers, and ACK numbers. It's fairly easy for a spoofer to fake these and any other sensitive fields in the TCP/IP headers. Early data samples of ISP-generated spoof resets indicated that the IP header "hop count" (TTL) field did not match other packets in the TCP stream. In fact, by guessing the round number with which the hop count had been seeded, and then using traceroute, we were able to make a good guess as to which machine inside the ISP had first routed the spoofed packet. However, altering spoofing systems to forge more reasonable values for TTL fields is a trivial exercise. Since it's therefore not robust to rely on TTL to detect spoofs, we do not utilize the TTL detection technique. It's much harder to fake the timing of a spoofed reset. Packets traversing an IP network take a finite amount of time to travel between two TCP endpoints. Since all of the data sent in a TCP stream carries sequence numbers within that stream, and those sequence numbers are acknowledged ("acked") by the endpoint peer, the total time for data to be sent to the peer and for the "ack" associated with that data to return can be measured. This round trip time (RTT) is tracked internally by TCP protocol layers, however it can also be measured by external monitoring devices or software at the endpoints. It is this methodology that is implemented by the current beta NNSquad Network Measurement Agent (NNMA). When sending bulk data during a TCP connection, the RTT between two TCP endpoints usually settles into a narrow, predictable range. Spoofed resets which are injected into the stream will usually have an RTT well below the measured average. Logging and analysis of these TCP "early" resets (those which show unusually low RTTs as compared against the average RTT for that given data stream) should provide a useful indication of likely spoofed reset activity. Reset packet spoofers could attempt to evade this detection technique and improve their "stealthiness" by first measuring the RTT of a connection that they are planning to disrupt, then delaying the transmission of their spoofed reset until timing falls within the "expected" RTT. The problem with this approach is the significant risk that the spoofed reset will arrive too late from the standpoint of the receiving endpoint. Most TCP stacks will ignore resets that arrive after the current sequence window (that is, late), but these may also potentially be useful flags that something unusual might be afoot. In short, spoofed resets have only a relatively narrow time window in which they can be both effective at disrupting connections and simultaneously be resistant to detection as potentially anomalous events. While NNMA currently only looks for early resets and not late ones, the latter is definitely an area worthy of further study. |