Re: Merits of purpose-built (appliance) vs. FreeBSD+ipfw firewalls

[Scott Francis <darkuncle () darkuncle net>]

On Thu, Jan 16, 2003 at 03:17:44PM -0800, user () mail econolodgetulsa com said:
> I am looking for comments and suggestions regarding the merits of
> purpose-built, appliance style firewalls (like a netscreen or Cisco PIX)
> vs. running ipfw on a commodity server running FreeBSD.  I am interested
> only in packet filtering and rate limiting performance - NOT in VPNs or
> IPsec/crypto considerations.
[snip]
> The problem I am running into is simply that my firewall CPU chokes.  It
> is not because the traffic is high - the line does not become saturdated,
> and sometimes total traffic can be less than 5 megabits/s - BUT the
> packets/s count goes way up (sometimes by a factor of 50) and because all
> of these packets have to go through my entire ruleset, the firewalls CPU
> chokes.  It does not crash, it simply stops forwarding any traffic,
> effectively blackholing my entire network.  As soon as the attack is
> stopped, the firewall is fine.

You may want to look into OpenBSD's new packet filter, pf(4). It's a stateful
filter, which, according to pf.conf(8), is usually faster than a rule-based
filter:

     Also, looking up states is usually faster than evaluating rules.  If one
     has 50 rules, all of them are evaluated sequentially in O(n).  Even with
     50000 states, only 16 comparisons are needed to match a state, since
     states are stored in a binary search tree that allows searches in O(log2
     n).
 
Also, pf in -current now has filtering, NAT, queueing (rule-based bandwidth
control - QoS, formerly a separate altq utility), table definitions,
normalization (scrubbing), routing, macros and options to the filtering
engine. Word is that some of the new queueing features are very spiffy, but
that stuff is fairly bleeding edge, so you may want to test that or wait a few
months for 3.3 to come out. (Sufficient testing while it's in -current will
ensure it is stable enough for 3.3)

I'm not a developer, just a satisfied user. I have not personally used the
new pf code on anything more heavily trafficked than a home network, but
several of the developers use it on fairly high-traffic areas with good
results. Worth a look, at least.

> 2. I happen to like a host-based firewall (a firewall running on a normal
> user OS like FreeBSD) better than an appliance.  You get to do anything
> you need with it, you have a full compliment of unix tools like grep and
> awk and tcpdump and expect, etc. - it seems like you have more control.
> Assuming (for a moment) that performance were equal, does anyone else feel
> this way ?  Does anyone else prefer a normal system for a firewall over,
> say, a PIX ?

I'm with you on that, mainly for (a) flexibility of configuration, (b)
ease/speed of upgrades/patches, and (c) price involved in purchase and
maintenance. Also as you mentioned, a firewall that starts out just filtering
can later be modified easily to capture packets for analysis later, run
active or passive intrusion detection, etc.

> 3. I am not that high profile ... but what do the high profile (shell
> servers like foonet and EFnet irc server operators) people use ?  Would
> any of those people consider even for a moment using a FreeBSD+ipfw system
> for their packet filtering and rate shaping ?

Avleen Vig may be able to give an answer from involvement with the SAFE
project, or at least some interesting statistics ... :)

> I just want to know if I should give up now and shell out a few grand for
> an appliance, or if it is reasonable for me to attempt to protect a
> network of my size.

When the traffic/attacks pass a certain point, my personal feeling is that
it's time to distribute the load, rather than look for a more expensive
single point of failure. Of course, this is not currently backed up by much
personal operational experience, so take that with a grain of salt. :)

> Thank you very much.

cheers,
-- 
-= Scott Francis || darkuncle (at) darkuncle (dot) net =-
  GPG key CB33CCA7 has been revoked; I am now 5537F527
        illum oportet crescere me autem minui

Attachment: _bin
Description: