[rescue] RFA: firewall
ssandau at gwi.net
Tue Jan 11 16:55:36 CST 2005
Thanks, Gavin. That does all make sense. I also now know what a receive
So, once a conversation is started the sequence numbers are predictable.
While I was thinking that the random thing was to prvent someone
stepping into the middle of an existing exchange, it is really to
prevent starting an exchange with a host that appears to be someone it
I'm posting this whole thing to the rescue list as you asked...
Gavin Hubbard wrote:
> Hi Steve
> The explanation that Wes posted was not entirely correct.
> Where Wes went wrong was that the sequence numbers for a TCP connection
> _are_always_ sequential. This is how the hosts at each end of the TCP
> link reassemble the packets in the correct order. The key to the IP
> spoofing attack is that some types of hosts generate predictable initial
> sequence numbers (ISN).
> A TCP connection is initiated when a computer_0 sends a SYN packet to
> computer_1. After receiving the SYN, computer_1 sends an ACK packet
> along with an ISN. In reply, computer_0 sends a SYN/ACK packet in which
> the ISN is incremented by 1. This process is sometimes called a
> three-way-handshake. Once the three-way-handshake is completed, a TCP
> connection has been successfully initiated between the hosts.
> When either host in the connection receives a packet from the other
> host, the sequence number is checked and the following occurs:
> a) If the sequence number is where it should be, the data is placed into
> the next available position in the receive buffer
> b) If the sequence number is less than it should be, the packet is
> treated as a retransmission and the packet is discarded.
> c) If the sequence number is larger than expected but still within the
> limit of the receive window, it is held in the TCP buffer until the
> missing packets arrive.
> d) If the sequence number is larger than expected, and outside the
> receive window, the packet is dropped and the host responds with a
> packet that contains the expected sequence number.
> To understand why all of this is important, you might want to consider
> the following hypothetical IP spoofing attack:
> 1. The attacker identifies a host that he wants to spoof. He begins to
> DDOS this host. This means that any traffic the host receives will be
> 2. The attacker now sends a flood of forged SYN packets to a server he
> wants to attack. The SYN packets have their source address set to the IP
> address of the machine that is being DDOS'd. This fills up the TCP queue
> in the server. Once the TCP queue is filled, the server starts to drop
> all incoming SYN packets. The reason the SYN queue must be filled is
> because attacker needs to stop other people connecting to the server (as
> each new connection creates a new ISN).
> 3. The server sends out ACK packets in reply to each of the SYN packets
> it has placed in the TCP queue. Because the host that corresponds to the
> forged address is being DDOS'd, it cannot send out SYN/ACK packets in
> response and therefore no SYN/ACK packets are received by the server. If
> the host whose IP address is being forged was reachable, it would send
> an RST (reset) packet back to the server and this would abort the
> 4. The attacker sends a forged SYN/ACK packet to the server. Because the
> attacker does not see the SYN packets sent out by the server, he needs
> to guess what the ISN was and increment it by one. If the correct ISN is
> chosen, the server believes that the three-way-handshake is completed
> and starts placing data from the attacker into the receive buffer.
> Importantly, it believes that the data is coming from a host at the
> forged source address.
> The ISN is simply a 32-bit number. Historically BSD systems had a
> terrible way of generating ISNs. They simply added 128,000 per second
> and 64,000 per connection. Because you can get the round-trip-time
> simply by pinging a host, all you needed to do was divide the RTT by 2
> and increment the last received ISN accordingly.
> The code used to generate ISNs is now much more robust. There is a dated
> but interesting paper that compares the different ISN generating
> algorithms in commercial operating systems at
> Hopefully this post explains why randomised ISNs are a good thing. If
> you need more information, the RFCs are a good place to start.
> Gavin Hubbard
> P.S. I cannot post to rescue at sunhelp.org from this host. If you could
> forward this email to the rescue list, I'd be very grateful.
More information about the rescue