On Sun, Jun 12, 2005 at 04:44:26PM +0200, Thomas Graf wrote:
> * Willy Tarreau <20050612133654.GA8951@xxxxxxxxxxxxxxxx> 2005-06-12 15:36
> > > The RST packet is sent by client A using its sequence numbers. Therefore
> > > it will pass the sequence number check on server B.
> > >
> > > 4) server B resets the connection.
> > No, precisely the RST sent by A will take its SEQ from C's ACK number.
> > This is why B will *not* reset the connection (again, tested) if C's ACK
> > was not within B's window.
> Absolutely but it relies on the other stack being correctly implemented.
> The attack would work perfectly fine if there wasn't the rule that a RST
> must not be sent in response to another RST.
Of course, if you target a buggy stack, you can expect anything.
> The attack has been successful and still is because some firewalls
> are configured to send RSTs without respecting this rule.
In fact, I voluntarily did not speak about firewalls because almost all
of them are very sensible to TCP DoSes. First of all, all those which
don't check sequence numbers will blindly kill a session when they
receive an RST. And some of the other ones will not let certain ACK
packets pass through, which will make other DoS described in this
thread effective while it should not be, by not letting the server
tell the client to reset its session when really needed.
> I like your patch and the idea behind it, it can successfully defeat the
> most simple method of preventing connections being established.
That's what I thought, too. I have another one for 2.4.31 which only adds
a CONFIG option to remove the associated code, which reduces the image by