Date: Mon, 28 Sep 1998 01:59:47 +1200 (NZST) From: Andrew McNaughton <andrew@squiz.co.nz> To: Heikki Suonsivu <hsu@clinet.fi> Cc: freebsd-security@FreeBSD.ORG Subject: Re: ipfw Message-ID: <Pine.BSF.3.96.980928011721.390K-100000@aniwa.sky> In-Reply-To: <199809271216.PAA24629@katiska.clinet.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 27 Sep 1998, Heikki Suonsivu wrote: > Date: Sun, 27 Sep 1998 15:16:42 +0300 (EEST) > From: Heikki Suonsivu <hsu@clinet.fi> > To: freebsd-security@FreeBSD.ORG > Subject: ipfw > > > How much work would be to rewrite ipfw to have interface-specific lists > instead of current global lists ? It think it would probably work best if > directives with "via" directive would be entered into a ipfw list attached > to if-specific structure, while the global ipfw lists would be handled > separately whereever they are handled today. > > Another possibility would be a more efficient matching data structure for > ipfw, which would hash addresses, in/out ports and device numbers into a > map of rules applicable to specific packet. I assume this would be more > compilicated but better solution in long term, as it would scale. > > We are building a >= 32-port device, and having ipfw lists global is > tremendous waste of precious CPU, as most interfaces need at least some > interface-specific access lists. Some improvement could be had from a hash table, but you can go a long way with a decision tree implemented with skipto, and it's a far more general technique. To split by interface you can do stuff like: 1000 skipto 10000 ip from any to any via lo0 1010 skipto 12000 ip from any to any via ed0 1010 skipto 14000 ip from any to any via ed1 1020 skipto 18000 ip from any to any via ed2 ... I've just set up ipfw for a school where I defined 5 general security zones (the router, world, office, servers, classrooms) using a combination of interface and ip# and multiplexed first by which zone the packet was from and then by which zone the packet was going to. In some cases there was an allow or deny rule in the second decision level, and for the others the packet got run through a list with a deny all rule at the end of it. The whole ruleset consists of a bit over 100 rules (not all that big anyway), but the worst case number of comparisons for any given packet is about 15 (could be improved a little if desired) and at least as importantly it's easy to find the relevant rules for any given communication and know you haven't missed anything. A downside of this scheme is that rules related to one session are not located in the same place for incoming and outcoming traffic. Interaction between global and interface specific rule sets could be a bit messy, depending what you want to do. You can run one set after another, but need to be clear about how the rulesets are going to interact. I could see good uses for a subroutine like mechanism in simplifying the rules for this sort of thing, but you can pretty much set up whatever you like as is. Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" 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.3.96.980928011721.390K-100000>