Date: Thu, 19 Jun 2003 15:28:12 -0700 From: Michael Sierchio <kudzu@tenebras.com> To: Tom Daly <tom@dyndns.org> Cc: freebsd-net@freebsd.org Subject: Re: Firewall Performance Question. Message-ID: <3EF238FC.6040005@tenebras.com> In-Reply-To: <Pine.BSF.4.53.0306191701320.71421@manganese.bos.dyndns.org> References: <Pine.BSF.4.53.0306191542190.71421@manganese.bos.dyndns.org> <3EF21648.8080205@tenebras.com> <Pine.BSF.4.53.0306191701320.71421@manganese.bos.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Tom Daly wrote:
>>>The average firewall ruleset runs around 600-800 rules, running on IPFW.
>>
>>That's a huge number of rules -- do you have any idea what number
>>of packets are checked against how many rules before being accepted
>>or denied? A histogram would be nice....
>
> Most of these rules are a simple "ipfw deny all from x.x.x.x to any."
> Could some sort of source route to a null interface be better?
>
> The base ruleset is about 160 rules. The box can handle this with minimal
> CPU load. The additional 500 rules, similar to the one above are the
> problem.
I'm of the opinion that 100 rules makes for a very large
ruleset.
> Suggestions?
So, you're incurring a huge penalty for those packets that you
allow in order to deny hosts/networks explicitly. Why? What
percentage of packets are denied if you let them fall through to
the bottom?
Also, I strongly urge you to switch to IPFW2 -- in addition to
using sets you can enable or disable atomically, or switch
atomically, you can do things like:
#!/bin/sh
# fw rules
bad_guys="{ \
61.11.0.0/19 or \
61.144.16.0/16 or \
61.72.248.192/26 or \
203.248.0.0/13 or \
210.72.224.0/24 or \
211.71.128.0/18 or \
211.104.0.0/13 or \
211.112.0.0/13 or \
211.194.117.160/27 or \
212.45.13.0/24 or \
217.80.0.0/13 or \
218.144.0.0/12 \
etc.
}"
# people we simply are not at home for
ipfw add 00700 set 0 deny ip from $bad_guys to any in recv $oif
# block those Microsoft protocols
ipfw add 00900 set 0 deny ip from any to any 137-139,445,568-569,1433-1434,1512,2002 in recv $oif
You get the idea -- it's not just the expressiveness of the
notation, but the efficiency in matching packets that helps.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EF238FC.6040005>