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

On Sun, Jun 12, 2005 at 11:33:49PM +1000, Herbert Xu wrote:

On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:

quoted

On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:

quoted

but it's not the case (although the naming is not clear). So if the remote
end was the one which sent the SYN-ACK, it will clear its session. If it has
been spoofed, it will ignore the RST because in turn, the SEQ will not be
within its window.

This is what should happen:

Sorry, you're right.  The SEQ check should catch this.

No problem. Fortunately, this part of the code is *very well* documented :-)

However, a few lines down in that same function there is a th->rst
check which will kill the connection just as effectively.

Yes, but only if there's an ACK and the ACK is exactly equal to snd_next,
so the connection will survive.

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.

My point was that it would not be too difficult to remotely prevent an
anti-virus or IDS from downloading its updates when you know the update
site's address and you know that by default it uses source ports
1024-4999 to connect outside. I don't really care for BGP however
because people should use MD5 or they get what they deserve.

Cheers,
Willy