Date: Fri, 1 Mar 1996 23:29:48 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: phk@critter.tfs.com (Poul-Henning Kamp) Cc: security@FreeBSD.ORG Subject: Re: IP filtering strawman, comments please. Message-ID: <199603011228.EAA08505@freefall.freebsd.org> In-Reply-To: <2151.825674609@critter.tfs.com> from "Poul-Henning Kamp" at Mar 1, 96 11:03:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Poul-Henning Kamp, sie said:
[...]
> Yes, it is a problem, but a check for IP level broadcase is better than
> no check for broadcast.
That is a degenerate case of ip#/mask, where the IP# is the broadcast
address and the mask is 255.255.255.255, ie not an issue worth
considering.
[...]
> 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.
Define `much'. I think you should look at both the BPF code and the
ip_firewall.c code. Then look at performance results from PathFinder.
Besides which, there is work in progress to improve BPF, but don't hold
your breath waiting.
What about the overhead from invoking filtering not just once, or
twice in the packets life in the kernel, but half a dozen times ?
In designing IP Filter, I gave careful consideration to pipelining
CPU's and can remove a large number of branches from the code in the
early stages of filtering, if need be (hmmm, this should be a compile
time option, perhaps). This is just an example of keeping in mind
the target system as well as overall speed.
[...]
> 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.
Is this intuitive ?
Have you looked at some of the packages available today, what they provide
in terms of flexibility and managability (commercial & non) ?
> > 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.
No, you don't. A packet being output is a packet being output. Whether
it is being diverted, routed, generated, whatever, it is still being
output. You can pretend to know how it got into the kernel, and how
it was generated.
To give you an idea of how this is not a problem, the structure of IP
Filter is something like this:
input-->[NAT]-->[fragment|state]-->[filter]-->[kernel]
\------>----/
[kernel]-->[NAT]-->[fragment|state]-->[filter]-->output
\------>----/
Where a fragment/state cache/table is kept and matching packets skip the
filter (which can add items to the aforementioned cache/table). Even this
is getting more complex than I am (almost) comfortable with. The basis
I've used is, if it stays simple, the code will be simple, and simple code
is always fast :-) It should also be easier to verify, etc.
btw, doing transparent proxying is _not_ as simple as you might think.
The obvious solution (redirect packts to *.www to localhost.www) breaks
TCP connections being 1:1.
[...]
> 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 :-)
Examples of things which are hard to express ?
Are they hard to express because of the interface tool or the engine ?
I think you overestimate the multiple filter-point gain.
[...]
> Firewalls are hard to get right.
There are two very good books and a number of papers on them. They don't
have to be hard to get right, any more.
> > 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.
Suggestion: managing filters through setsockopt()'s is _stupid_ if you're
not implementing it for a new protocol/socket type. I've thought about
doing it this way and would probably do it via recv() on this socket.
> > 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 ?
That disappeared some time ago.
> > 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.
Complex firewalls == complex code...
On a separate note, you could totally rework the internal packet delivery
for each protocol (ie kill off protosw and pcblists/tables) and do it all
with filtering. See PathFinder (OSDI a year or two ago).
darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603011228.EAA08505>