Date: Tue, 10 Dec 1996 20:32:02 -0800 From: David Greenman <dg@root.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: taob@io.org (Brian Tao), freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Message-ID: <199612110432.UAA10905@root.com> In-Reply-To: Your message of "Wed, 11 Dec 1996 14:23:22 %2B1030." <199612110353.OAA21602@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>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?199612110432.UAA10905>