Date: Thu, 12 Dec 1996 07:32:56 -0700 (MST) From: Stephen Fisher <lithium@cia-g.com> To: David Greenman <dg@root.com> Cc: Michael Smith <msmith@atrad.adelaide.edu.au>, Brian Tao <taob@io.org>, freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Message-ID: <Pine.BSI.3.95.961212073226.2381E-100000@maslow.cia-g.com> In-Reply-To: <199612110432.UAA10905@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Can't the hacker just recompile the kernel with bpf support and then use it, though? On Tue, 10 Dec 1996, David Greenman wrote: > >Brian Tao stands accused of saying: > >> What are people's feelings on enabling devices like bpf or snp > >> in the kernel on a public server? Obviously, had I not compiled bpf > >> into the shell and Web server kernels, this particular incident would > >> never have happened. However, I like to have access to tcpdump to > >> check for things like ping floods, and trafshow to see where bytes are > >> being sent. > > > >Evil evil evil. Definitely never on a public server; bpf lets you do > >lots more than just snoop, it makes it possible (easier) to spoof as > >well. > > I made the mistake of putting bpf in freefall's kernel a long time ago and > forgot it was in there. Someone eventually took advantage of that and used it > to sniff passwords at Walnut Creek CDROM. This led to a serious break-in on > wcarchive. Needless to say, bpf is no longer in freefall's kernel. It was > never in wcarchive's kernel (and never will be)...the damage would have been > much worse if it had been. The moral of the story for me was never to put > bpf in a "public" server's kernel. I hope you've learned the same lesson. :-) > > >> I know this depends entirely on your local setup, and every site > >> has different policies, but I'd like to hear if anyone has strong > >> feelings about "enabled" kernels or proposed solutions (i.e., an > >> option to make bpf work only for processes run on the console). > > > >No. If you want to watch the network, set up a utility machine, or > >at least a machine with no shell users on it, and use that. > > Right, and if you have machines co-located, be sure to always give them > their own switch port - never connect them to a shared hub. You should also > strongly encourage the use of ssh whenever doing remote logins. We've taken > all of these precautions at Walnut Creek CDROM... > > -DG > > David Greenman > Core-team/Principal Architect, The FreeBSD Project >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.961212073226.2381E-100000>