Date: Wed, 19 Sep 2001 08:05:36 -0400 (EDT) From: "Marc G. Fournier" <scrappy@hub.org> To: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> Cc: <freebsd-security@FreeBSD.ORG>, <freebsd-net@FreeBSD.ORG> Subject: Re: ipfw problems ... Message-ID: <20010919075409.G30377-100000@mail1.hub.org> In-Reply-To: <Pine.BSF.4.21.0109190909310.402-100000@lhotse.zaraska.dhs.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Sep 2001, Krzysztof Zaraska wrote: > 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? CA*Net3 vs "commercial net" traffic ... > 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. Actually, I've already done that :( Some areas, I've been able to get her down to /12 ... so imagine the number of rules if I *hadn't* done that ... > 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. Thought about, but not possible ... unless I'm mis-understanding something ... these rules are the exceptions ... "if none of these b-class networks isn't matched, *then* shape the bandwidth for anything not in there" ... Is there someway of creating a 'group', similar to /etc/networks, where its one rule with many addresses in it? > 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. Not using any 'keep-state' rules ... 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?20010919075409.G30377-100000>