From owner-freebsd-pf@FreeBSD.ORG Tue Dec 27 12:26:09 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3847416A41F for ; Tue, 27 Dec 2005 12:26:09 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01F1743D45 for ; Tue, 27 Dec 2005 12:26:07 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jBRCPniR030685 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 13:25:50 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jBRCPmeb032192; Tue, 27 Dec 2005 13:25:48 +0100 (MET) Date: Tue, 27 Dec 2005 13:25:47 +0100 From: Daniel Hartmeier To: Alberto Alesina Message-ID: <20051227122546.GE81@insomnia.benzedrine.cx> References: <20051227084823.28384.qmail@web32611.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051227084823.28384.qmail@web32611.mail.mud.yahoo.com> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: tracking half-open connections X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2005 12:26:09 -0000 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