Date: Fri, 01 Mar 1996 11:03:29 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: Darren Reed <avalon@coombs.anu.edu.au> Cc: security@FreeBSD.ORG Subject: Re: IP filtering strawman, comments please. Message-ID: <2151.825674609@critter.tfs.com> In-Reply-To: Your message of "Thu, 29 Feb 1996 12:02:58 %2B1100." <199602290101.RAA02493@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I was passed this e-mail and asked to comment, which I don't mind doing, > so long as someone will listen. Don't worry, I will :-) > This can (only) reliably come from looking at the MAC address and will need > to be done in the driver, somewhere. ie if_ether.c and if_ppp.c (not if_ed.c , > etc). Yes, it is a problem, but a check for IP level broadcase is better than no check for broadcast. > If this is a requirement, then the current ipfw structure needs to be > totally scrapped and something using BPF implemented. Having looked into > this already, I'd suggest that a filter list would then be a set of BPF > programs, with filter return statuses used bsed on what BPF thinks. > There are some problems with this, however... Yes, I have been looking at this, and I should be possible to add a the possiblity of specifying a BPF-code filter as well. These will be too much slower than the regular ones, so they should only be used for "weird" things. > Have you considered what this does for management of packet filtering ? yes, carefully even. > The complexity is increased too much, I fear. If I want to delete a rule, > how many times do I have to delete it if it is referenced by several > interfaces/control points ? My idea is that unless you tell it to apply a rule at a certain point, it will be installed at the points needed for it to appear as a "global" rule. (A,B,C in the draft. If you delete a rule by lineno, it will be gone from all points of application. If you delete it by lineno+filter-point, it will only disappear from there. That means that the normal case will look just like now. > The main problem I see with this is: how easily can I view a complete list of > rules that can possibly effect the packet and what do I have to do to verify > that my access list rules are doing what I want ? I imagined that you could view the matrix like the example in the strawman, but this is clearly a point that needs some work. > Filtering packets being "routed onwards" is a dubious distinction from those > being sent as output, IMHO. No, you need to be able to do that if you want to use the "divert" action to examine a packet, also, it will make proxys easier, for instance a mandatory web-proxy can be made that way. > The only reason I'd be thinking about making changes like this would be for > performance reasons. In testing IP Filter, I've noticed very little > degradation on a P-100 with 1 or 100 rules for ftp across my own ethernet. There are a lot of things that are needlessly hard to express in the current setup. Having the option of multiple filter-points will make these easier to express. If you just want "one filter, one place: all over the place", then you should hopefully find that to be the default :-) > The correctness of the implementation also becomes harder to prove, requiring > bits of the kernel to be used in testing. Currently, you could take the > engine from ipfw and build a userland progam around it (I hope!) which could > trivially test any/all packets. Firewalls are hard to get right. > The problem of how to "log" packets is a side effect of how it is currently > being done: either via log() or printf()/kprintf(). This is better solved > by fixing the way interaction is done with the in-kernel filtering. exactly. Havn't really got a good idea for it yet. > On a separate note, prior to 2.1.0 release, a few people from > freebsd-security asked about incorporating IP Filter. The reason given then > for not including it (accounting) has since been fixed; > URL: http://coombs.anu.edu.au/~avalon/ip-filter.html wasn't there some copyright thing also ? > I guess what you end up doing depends upon what your goals and aims are. and what gives the most mileage and the fewest problems... > What problems are you trying to address (and solve) with your strawman ? I'm trying to make it easier to setup complext firewalls, without making it harder to set up simple ones. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2151.825674609>