|Edited: Jan 12,2001 at 16:23 (-0700 UTC)||. . . because sometimes it IS rocket science!|
Eliminate Denial of Service (DoS) Vulnerability
Part I - Understanding the Problem
by Steve Gibson
While developing our own custom IP protocol suite to host our forthcoming NanoProbe™ Technology, I faced the problem of dealing with attacks of this sort, to which our high-profile site will surely be subjected. Since I was implementing the TCP protocol on my own, from scratch, I could do anything I wanted. On this occasion I devised a unique and highly-effective solution which, while completely compliant with the TCP protocol specification, completely eliminates the problems associated with falsified inbound connections.
Using this technique, outlined below, falsified connections cease to present any sort of problem for a Server. Any implementation of the TCP protocol can be easily enhanced to render it absolutely immune to source address spoof flooding while allowing it to remain highly available to legitimate inbound connection requests.
To understand the technique, it's important to understand the problem . . .
How TCP connects:
non-deterministic, packet-switched network.
By this we mean that data flows across the Internet encapsulated within individual data packages — or packets — and that individual packets might arrive out of sequence . . . or perhaps not at all. To manage this high degree of uncertainty, individual TCP packets are transmitted with "sequence numbers" to allow the receiving end to reassemble the original packet sequence and acknowledge the receipt of packets received.
Before packets of data can begin flowing from end-to-end over a TCP "connection" the endpoints must exchange their initial packet sequence numbers (so that the other end knows what sequence numbers to expect). Each end sends its initial sequence number and acknowledges the receipt of the other's in a "connection opening" process known as the 3-Way Connection Handshake:
Let's examine the three packet transactions:
Now that we understand how TCP connections are established between two machines, let's see how this process can be deliberately subverted by malicious hackers . . .
Source address spoofing:
Every IP packet traversing the Internet carries the IP address of both its source and its destination. So, for example, when an IP "Ping" packet arrives at a machine with its implicit request to be "echoed" back to the sender, the receiving machine simply swaps the source and destination IP addresses, changes the packet "type" from "Echo Request" to "Echo Reply", and sends it back out. It will automatically return to the originating Source IP address, which has now become the destination.
But the "Source IP" address is just a data field like any other in the IP packet and nothing about the design of the Internet prevents this information from being deliberately falsified. A packet's Source IP is the only identification of the packet's originating machine, and packets travel across the Internet by hopping from one router to the next. Therefore, the true source of a packet with a "spoofed" source IP address is immediately obscured and backtracking a packet to its source is flatly impossible. As you can see . . .
packets, the Internet provides virtually perfect anonymity.
How can spoofed packets deny service?
To understand the operation of a SYN Flood style Denial of Service (DoS) attack, consider the consequence of opening a TCP connection to a Server using a spoofed Source IP address:
A Malicious Client's SYN packet, containing a deliberately "spoofed" and falsified Source IP address, appears to be just as valid to the receiving Server as any other. So, upon receipt of the SYN packet, the Server prepares for this new TCP connection exactly as we saw above: It sets aside some of its RAM memory (to hold the details of this new connection) into which it dutifully records the Client's initial sequence number (CISN) and the Client's apparent source IP and TCP port numbers. It chooses an initial sequence number for its own packets, and sends its replying SYN/ACK packet off to the Client containing its SISN and ACKnowledging the Client's CISN . . .
lied about its IP address!
Since the Source IP contained in the Client's original SYN packet was spoofed, the Server sends its replying SYN/ACK packet to the spoofed IP address, which is probably to no machine at all. The well-meaning SYN/ACK packet heads off across the Internet, never to be heard from again.
As we know, once the Server has sent the SYN/ACK packet to the Client, it expects — and waits for — the Client's final "ACK" acknowledging the receipt of the SYN/ACK, and finalizing the establishment of the TCP connection.
But in this case, that final "ACK" will never arrive.
After some amount of waiting, a "timer" located in the block of memory set aside to manage this connection expires. The Server determines that the SYN/ACK must have been lost in transit to the Client, so it resends the SYN/ACK to the same spoofed IP address. Since the Internet really does lose, drop, and discard packets with some frequency, this "retrying" process must be repeated several more times. Since the Server has no way of knowing how "far away" the Client is, it also waits longer and longer after each retry in a well-meaning attempt to "adapt" to a particularly distant Client. All attempts must fail before the Server can reliably decide that a TCP connection with the Client can not be completed.
waiting, can it release the resources it set aside
for managing the anticipated connection.
. . . And this, of course, is the key to the destructive potential of flooding a Server with an endless stream of SYN packets containing spoofed Source IP addresses.
There is no way for the Server to know which inbound SYN packets are valid and which are spoofed, so it must treat each one as valid. But every received SYN forces the Server to set aside some RAM memory to manage that connection, and to keep this memory tied-up during lengthy waits and retries. If spoofed SYN packets arrive in a constant flood, all of the Server's available connection management memory will be quickly exhausted in managing connections that will never succeed . . . and legitimate Clients will be denied the service due to its inability to accept additional connections.
Since packets with spoofed Source IPs cannot be backtracked to their source there's no way to catch the perpetrators, and since the spoofed packets are otherwise completely valid, they cannot be "filtered" and prevented from being handled.
a good solution . . . until now.
For a detailed specification of the DoS Solution,
Part II - Exploring the
|Purchasing Info||GRC Mail System||To GRC's Home||Tech Support||Discussions|