In some email I received from Brent Chapman, Sie wrote:
>
[...]
> What _I'd_ like to see is some experimentation with these issues,
> particularly on the part of the vendors. One of the recurring
> responses I get when I badger vendors about improving their filtering
> capabilities is that it costs too much in performance. My response is
> always that I (and many of my clients) are willing to pay that cost,
> in order to improve our security. But most of the vendors aren't even
> offering us the option of trading speed for security; they keep making
> things faster and faster, without necessarily improving the products
> along any other axis, like security.
Just out of curiosity, how good would a kernel implementation of a similar
complexity to Sun's NIT or the BPF be if it was used as an interface to
a packet screen ? (I think that the "packet filter" has to be given over
to features such as NIT and BPF and "packet screen" used for firewalling
:-/ ). Having used the NIT, I know that it allows you quite an amount of
flexibility whereas packet screening interfaces seem to be based on
"deny" and "allow" with various constants to be compared.
That leaves it upto the end user to construct an efficient set of commands
for the screening process, although it puts the screening in the kernel
which some seem to dislike for logging reasons.
For those kernels which give packets up to a user process to deal with,
maybe someone should hassle someone at GNU and have a 'free' and flexible
packet screen written to replace the vendor's ? Heck, if nobody was
willing to do a 'GNU' version, is there sufficient info in man pages for
someone else to do a 3rd party screening process ? Considering the main
push for this s/w is from the corporate sector, there is probably money
in a good packet screen.
Darren
References:
|
|
