[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ipf

*thud thud thud*

Christ, people. A packet filter, the evening's topic of conversation,
filters based on TCP, UDP, and IP headers. In the more complicated
revision, it also maintains TCP connection state, and pseudo-state for
UDP "connections".

If you want to do Layer 7, or pseudo-Layer 7 inspection of packets,
then you are talking about an application proxy firewall, more or
less. In which case YES, you can have the target of a packet rule be a
socket to a user-mode daemon upon certain criteria (ie, connection
setup or teardown or for all packets).

But I would _still_ advise people in search of that functionality to
look at FWTK.

Yes, context switches ARE that expensive, when you get over a certain
number of packets per second.

We are still speaking, correct, of a packet filter? One that must work
with saturated 100mbit links? At the _very_ least?

As for SMB in the kernel, remember that some idiots [1] strapped HTTP
into a linux kernel. That is MUCH closer an analogy. Anything for
performance tests, right?

jeff
[1] I say idiots, because the concept is mind-boggling to me, but by
all accounts you have to be pretty clever to pull that off. So lets
say "loonies".

On Wed, May 30, 2001 at 03:27:01PM +1000, Michael Samuel wrote:
> On Wed, May 30, 2001 at 12:10:52AM -0500, Jeff Bachtel wrote:
> > What would be the security advantage? Packet filters don't parse
> > strings, or execve() programs, they filter. And thats it.
> 
> Well, in this day in age, people like to do other things than just
> block according to the ip header details.  Searching a packet data is
> a popular request nowadays for people in search of a filewall.
> 
> > The reason you _don't_ put a packet filter in userspace is that a
> > context switch is added for each packet that traverses the firewall.
> 
> Is the overhead of a context switch that much nowadays?  If so, then
> that's another area of work.  The only real problem I see is the extra
> copy of the packet in memory, which could be solved with an mmap()ed
> interface (right??).
> 
> > And the only language to choose for a BSD packet filter is C. That is,
> > if you want it to be capable of handling linespeed.
> 
> [ I won't bite on the language flamewar ]
> 
> > (in short, the only thing userland about a firewall should be the
> > control programs)
> 
> I understand where you're coming from, but then again, your reasoning
> is the same as Microsoft's reasoning for putting SMB into the NT kernel.