|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Merits of purpose-built (appliance) vs. FreeBSD+ipfw firewalls
On Thu, Jan 16, 2003 at 03:17:44PM -0800, [email protected] 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:
pgp00009.pgp
|