Date: Wed, 3 Feb 1999 09:56:43 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, "Jonathan M. Bresler" <jmb@FreeBSD.ORG>, woodford@cc181716-a.hwrd1.md.home.com, security@FreeBSD.ORG Subject: Re: tcpdump Message-ID: <199902031756.JAA74538@apollo.backplane.com> References: <199902022137.NAA07900@hub.freebsd.org> <9575.918011566@zippy.cdrom.com> <199902031717.KAA29988@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> OK, time to raise this topic again. What to people think about
:> enabling bpfilter by default in GENERIC?
:>
:> And before everyone screams "That would not be BSD!" let me just
:> note that NetBSD and probably OpenBSD (haven't looked) already do
:> this.
What if we extended the ipfw rules to cover bpf sockets? This way
we could enable bpf yet still restrict its use.
Even better, what if we were able to impose a bpf filter 'in front' of
any filter specified by a bpf user? We could then impose a filter that
only allows through packets related to the services we wish to support
via bpf. When securelevel is > 0, this imposed filter becomes locked.
We could also have a toggle to enable/disable promiscuous mode which
could be compiled into the kernel and/or made programmable.
I admit it is somewhat a silly argument - nobody should be using
unencrypted network connections for sensitive work these days. I don't
even have telnetd or rlogind ( or friends ) enabled on any of my systems -
it's sshd or nothing. It is *FAR* more dangerous for a hacker to monitor
pty's then it is for a hacker to monitor a network. So at the very least
we should enable bpf in GENERIC and then work on a followup solution
to help w/ security.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199902031756.JAA74538>