Date: Tue, 27 Dec 2005 13:25:47 +0100 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Alberto Alesina <aalesina@yahoo.com> Cc: freebsd-pf@freebsd.org Subject: Re: tracking half-open connections Message-ID: <20051227122546.GE81@insomnia.benzedrine.cx> In-Reply-To: <20051227084823.28384.qmail@web32611.mail.mud.yahoo.com> References: <20051227084823.28384.qmail@web32611.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 27, 2005 at 12:48:23AM -0800, Alberto Alesina wrote:
> Turning on PF synproxy filter rule flag and choosing
> aggressive timeouts seems a good defense against SYN
> flood attacks, but I was curious if there are any
> options similar to some commercial firewall vendors,
> where after a configured maximum threshold of
> "half-open" connections is exceeded, new connection
> setup requests cause an existing (either the oldest or
> random) half-open TCP connection to be dropped (with
> the corresponding RST to the server to clear the
> entry) before any new connection is allowed through.
> Is overwhelming the system (by causing generation of
> RST's) a pitfall of such an approach and hence the
> reason not to implement it?
Using synproxy state (max) and aggressive tcp.first/opening timeouts
on that particular rule achieves just that effect, doesn't it?
The attacker sending a flood of spoofed SYNs from different source
addresses creates state entries, but can't deliver a single SYN to the
real server (hence, not allocating any resources on the server), up to
the point where the rule's max limit is reached.
After that, the attacker and legitimate client race for new empty
slots in the state table (quickly generated due to the aggressive
timeouts). Unlike with a 'remove random half-open state on overflow'
scheme, the legitimate client is guaranteed to get a working connection
when
a) it (randomly) gets a free slot in the state table, and
b) it completes the handshake before the (aggressive) timeout
expires
If the attacker has such overwhelming bandwidth that he can cause most
legitimate client packets to get dropped upstream of you, either scheme
will fail similarily, like in a plain DoS flood case.
So, how is synproxy not the best possible solution in this case? How
would the other scheme (passing the SYN to the real server, generating
RSTs to the server on overflow) have ANY advantage, in ANY case?
Ignoring the non-technical "advantage" of providing a feature present in
a competitor's product for the mere sake of marketing (which you'll have
to excuse me for completely ignoring ;)
Daniel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051227122546.GE81>