Date: Sun, 12 Sep 2010 14:02:40 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: "Marat N.Afanasyev" <amarat@ksu.ru> Cc: Gareth de Vaux <bsd@lordcow.org>, Vlad Galu <dudu@dudu.ro>, stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules Message-ID: <20100912131228.M73353@sola.nimnet.asn.au> In-Reply-To: <4C8A1328.6010508@ksu.ru> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> <AANLkTi=oaANzhEkDSnaQgaXz%2BTOO8aQPOkaQ9GAP9v0O@mail.gmail.com> <20100910125714.Y73353@sola.nimnet.asn.au> <4C8A1328.6010508@ksu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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<amarat@ksu.ru>: > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100912131228.M73353>