Date: Wed, 19 Sep 2001 09:59:50 +0200 (CEST) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: ipfw problems ... Message-ID: <Pine.BSF.4.21.0109190909310.402-100000@lhotse.zaraska.dhs.org> In-Reply-To: <20010918230726.M30377-100000@mail1.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 18 Sep 2001, Marc G. Fournier wrote: > > I recently setup a box on our network, running FreeBSD 4.4-PRERELEASE, > with ipfw and dummynet to do bandwidth shaping as well as firewalling ... > > The machine is a Dual PIII 733 w/1gig of RAM and 2xfxp0 devices ... > > I've got an /etc/fw.rules file that has ~1200 rules in it so far, and > still have more that I want to put in, but today the machine locked up > solid ... > > I ended up re-starting the machine with fw set to open, and loaded a few > rules at a time ... got up to 747 rules before the machine pretty much > ground to a halt, with the occasional keystroke going through ... > > ~900 or so of the rules are purely 'pass thru' rules ... we have two > connections to the internet ... one that costs us nothing, and one that > costs us quite dearly ... we want to allow all traffic that goes to sites > on the 'costs us nothing' network to go through unimpeded, while that > which goes through the 'costs us quite dearly' to be 'shaped' ... th ~900 > rules are the ones that define those b-class networks that are on the > 'costs us nothing' network ... With all respect, that looks like a flawed firewall design. Quoting Lance Spitzner's paper on firewall design (http://www.enteract.com/~lspitz) , every firewall having over 50 rules becomes unmanageable. I'd say that the threshold may be moved to 100..150 rules since sometimes it's necessary to split one policy rule into several filter rules, but your number IMHO is way too much. First, is there any specific reason for allowing only specific 900 subnets instead of the whole 'cost nothing' network? How big is this network? How would this increase the risk? Second, with that number of networks, it is probable that at least some of them have the same prefix; for example 10.10.0.0/16 10.11.0.0/16 can be matched with 10.10.0.0/15. This may bring down the number of rules. Continuing from previous point, if all class B networks are on the same network block (having, say 1024 class B networks) you may allow whole block and disallow only 124 subnets. That would bring the number of relevant rules down to 125. Third, take into account that since ipfw takes 'first matching rule wins' approach, you will get performance boost by moving more frequently used and more general rules "up" in the ruleset. For example, if you move the rule from position 700 to 200 packet will be matched only against 200 rules instead of 700. Fourth, if you have any "keep-state" rules, each of them effectively generates new "dynamic" rules. In order to improve performance with TCP connections you may try to switch to TCP flag-based approach (keywords "setup" and "established"). This will save you from additional growth of ruleset, but may open you to the TCP ACK scan (I haven't verified it) which exposes inside network topology. Fifth, you may try separating routers. For example, set up one machine for each uplink, and set each one with a ruleset relevant with the link it is connected to. You may then connect them to the internal network with a non-filtering router or just set the routing tables on each internal host appropriately. This should distribute the load and ease management. > I'm not seeing any errors on the console to indicate a problem, it just > slowly grinds to a halt ... is there a setting in the kernel, or > somewhere, that I should be setting to allow fur such a high number of > rules, or is it just not possible to do more then a few hundred? :( Well. A friend of mine gave up on a Linux router with ca 300 rules. Matching every of literally millions of packets traversing the router against a huge ruleset will bring every machine to it's knees. > Thanks Not at all. Regards, Krzysztof To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109190909310.402-100000>