ipfw: Too many dynamic rules

[Ian Smith]

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 at 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