Re: [PATCH] fix small DoS on connect() (was Re: BUG: Unusual TCP Connect() results.)

[Willy Tarreau <willy@w.ods.org>]

On Sun, Jun 12, 2005 at 11:50:18PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 03:47:25PM +0200, Willy Tarreau wrote:
> > 
> > Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
> > so the connection will survive.
> 
> Sorry I wasn't thinking straight.
> 
> > 
> > > My point is that there are many ways to kill TCP connections in ways
> > > similar to what you proposed initially so it isn't that special.
> > 
> > No, there are plenty of ways to kill TCP connections when you can guess
> > the window (which is more and more easy thanks to window scaling). But
> > I have yet found no way to kill a TCP session without this info, except
> > by exploiting the simultaneous connect feature.
> 
> I still stand by this point though.  The most obvious thing I can think
> of right now is to change your attack to simply connect to kernel.org's
> webserver first from source port 10000.  That will cause the real SYN
> packet to fail the sequence number check.

This case is interesting, but it will be resolved in two possible ways :
1) no firewall in front of A
  - C spoofs A and sends a fake SYN to B
  - B responds to A with a SYN-ACK
  - A sends an RST to B, which clears the session
  - A wants to connect and sends its SYN to B which accepts it.

2) A behind a firewall
  - C spoofs A and sends a fake SYN to B
  - B responds to A with a SYN-ACK, which does not reach A (firewall, etc...)
  - A tries to connect to B and sends its SYN with a different SEQ
  - B responds to A with only an ACK (no SYN) indicating the expected SEQ.
  - A responds to B's ACK with an RST and B flushes its session too.
  - A resends its SYN to B which accepts it.
 
Cheers,
Willy