From owner-freebsd-stable@FreeBSD.ORG Sun Sep 12 04:02:52 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 5513F106566B for ; Sun, 12 Sep 2010 04:02:52 +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 8EE408FC13 for ; Sun, 12 Sep 2010 04:02:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o8C42eEg064688; Sun, 12 Sep 2010 14:02:41 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 12 Sep 2010 14:02:40 +1000 (EST) From: Ian Smith To: "Marat N.Afanasyev" In-Reply-To: <4C8A1328.6010508@ksu.ru> Message-ID: <20100912131228.M73353@sola.nimnet.asn.au> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> <20100910125714.Y73353@sola.nimnet.asn.au> <4C8A1328.6010508@ksu.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Gareth de Vaux , Vlad Galu , 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: Sun, 12 Sep 2010 04:02:52 -0000 On Fri, 10 Sep 2010, Marat N.Afanasyev wrote: > Ian Smith wrote: > > 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. > > stateful firewall does not limits numbers of states/connections. it just add > a new layer which can be overfulled easily. if you experience a DDoS attack > it's better to block attackers addresses, e.g, adding them to some ipfw table > using external methods. Sure, that's another tool in the box. There's no single solution to such things, however connection limits applied to a stateful firewall are specifically intended to prevent state tables being overwhelmed, and the default table sizes are generally more useful for smaller systems. > did you try to use lighweight and FAST frontend web-server as proxy? e.g. > www/nginx or www/zerowait-httpd? Wasn't me having the problem :) ADSL1 here, not nearly enough bandwidth to worry about DDoS choking server processes. I use stateless for most inbound connections anyway, sendmail's connection limits for mail, and inetd connection limits per time for POP, FTP and some other services. > > > 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. > > I can say that 4 connection limit is extremely low limit, because if you use > a somewhat "distributed" web site (css, images, etc. in different files) > client software may open DOZENS of connections simultaneously, and you will > deny absolutely rightful connections. btw, real DDoS is often uses thousands, > tens of thousands and even hundreds of thousands botware hosts. I've rarely > seen millions, may be 2 or three times at all, while 50-80 thousands hosts is > average. It's all a matter of scale. I didn't get the impression that Gareth was running anything big enough to see that scale of attack, but that's just my impression. And of course 4 was just that example from the manual, a limit perhaps suitable for a small mailserver? By all means make it 4 dozen if you really think clients each need that many open connections. Given he was already enquiring about ipfw used statefully, one could instead use 'limit dst-port N' to limit _total_ active connections to the webserver to something reasonable for the particular environment, and other tuning as others have suggested. I still tend to agree with Vlad; better to limit connections/states than then having to deal with the consequences of overwhelmed servers; YMMV. > > 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 :) > > yes, this is one of the best looking solutions. Just one more tool .. there are various firewall log tailing utilities available; one size is never going to fit all, and I'd been wanting to try writing something myself for ages. But it's all small beer here :) cheers, Ian