From owner-freebsd-stable@FreeBSD.ORG Fri Sep 10 03:46:14 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4010C106564A for ; Fri, 10 Sep 2010 03:46:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id A31C78FC08 for ; Fri, 10 Sep 2010 03:46:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o8A3k4Yg010032; Fri, 10 Sep 2010 13:46:06 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 10 Sep 2010 13:46:03 +1000 (EST) From: Ian Smith To: Vlad Galu In-Reply-To: Message-ID: <20100910125714.Y73353@sola.nimnet.asn.au> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Marat N.Afanasyev" , Gareth de Vaux , stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 03:46:14 -0000 On Thu, 9 Sep 2010, Vlad Galu wrote: > 2010/9/9 Marat N.Afanasyev : > > I wonder, are these dynamic rules really necessary? let's see, a client > > connects to your web-server and you immediately should create a new dynamic > > rule, therefore you participate in this DoS attack as well as attacker. ;) > > With a stateless firewall, you help the attacker even more. Because > he's able to connect to your httpd/whatever daemon is listening > directly and he can easily fill up the descriptor table of that > process. Limiting the number of states/connections from the same host > prevents that. Sure, those states eat up RAM, but so do the > established connections. Having a slightly more aggressive state > expiry policy always helps. Sure, there are accf_http(9), accf_data(9) > and various forking workarounds, but they don't work unless your TCP > server is specifically designed to use them. Agreed. > PF also allows you to tarpit malicious hosts based on how often they > try to reconnect - you can dynamically add them to a table which you > can refer to from ALTQ. As mentioned, ipfw 'limit' rules accomplish effectively the same without needing an extra table; eg only allowing N simultaneous connections from any one address. If N were say 4, even a distributed attack by 20 hosts will only allow 80 concurrent connections, no big deal for the firewall and no need to bother trying to limit connections later at the server. That said, I've also tables blocking noted pests, including some recent distributed bots seeking eg blocklist='scripts/setup.php p=phpinfo();' which irritated me enough to knock up a script to knock them off :) BTW, Gareth: ... while talking to mail.lordcow.org.: >>> DATA <<< 550 5.1.1 ... User unknown 550 5.1.1 ... User unknown <<< 503 5.0.0 Need RCPT (recipient) cheers, Ian