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:33:49PM +1000, Herbert Xu wrote:
> On Sun, Jun 12, 2005 at 11:13:23PM +1000, herbert wrote:
> > On Sun, Jun 12, 2005 at 02:32:53PM +0200, Willy Tarreau wrote:
> > >
> > > 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/