[rescue] RFA: firewall

[Steve Sandau]

Thanks, Gavin. That does all make sense. I also now know what a receive 
window is.

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 
is not.

I'm posting this whole thing to the rescue list as you asked...

Steve



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 
> dropped.
> 
> 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 
> connection.
> 
> 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 
> http://alon.wox.org/tcpseq.html
> 
> Hopefully this post explains why randomised ISNs are a good thing. If 
> you need more information, the RFCs are a good place to start.
> 
> Regards,
> 
> 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.
> 
> 
> 

>