Date: Fri, 10 Sep 2010 15:14:48 +0400 From: "Marat N.Afanasyev" <amarat@ksu.ru> To: Ian Smith <smithi@nimnet.asn.au> Cc: Gareth de Vaux <bsd@lordcow.org>, Vlad Galu <dudu@dudu.ro>, stable@freebsd.org Subject: Re: ipfw: Too many dynamic rules Message-ID: <4C8A1328.6010508@ksu.ru> In-Reply-To: <20100910125714.Y73353@sola.nimnet.asn.au> References: <20100909153902.GA28341@lordcow.org> <4C89215E.7010203@ksu.ru> <AANLkTi=oaANzhEkDSnaQgaXz%2BTOO8aQPOkaQ9GAP9v0O@mail.gmail.com> <20100910125714.Y73353@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms040401010206020101000606 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: quoted-printable 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 a= ttacker. ;) > > > > With a stateless firewall, you help the attacker even more. Becaus= e > > 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 h= ost > > 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_dat= a(9) > > and various forking workarounds, but they don't work unless your T= CP > > 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=20 some ipfw table using external methods. did you try to use lighweight and FAST frontend web-server as proxy?=20 e.g. www/nginx or www/zerowait-httpd? > > PF also allows you to tarpit malicious hosts based on how often th= ey > > try to reconnect - you can dynamically add them to a table which y= ou > > can refer to from ALTQ. > > As mentioned, ipfw 'limit' rules accomplish effectively the same withou= t > needing an extra table; eg only allowing N simultaneous connections fro= m > any one address. If N were say 4, even a distributed attack by 20 host= s > 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=20 files) client software may open DOZENS of connections simultaneously,=20 and you will deny absolutely rightful connections. btw, real DDoS is=20 often uses thousands, tens of thousands and even hundreds of thousands=20 botware hosts. I've rarely seen millions, may be 2 or three times at=20 all, while 50-80 thousands hosts is average. > That said, I've also tables blocking noted pests, including some recent= > distributed bots seeking eg blocklist=3D'scripts/setup.php p=3Dphpinfo(= );' > which irritated me enough to knock up a script to knock them off :) yes, this is one of the best looking solutions. -- SY, Marat --------------ms040401010206020101000606--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8A1328.6010508>