From owner-freebsd-security Thu Dec 12 06:33:54 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA14453 for security-outgoing; Thu, 12 Dec 1996 06:33:54 -0800 (PST) Received: from maslow.cia-g.com (maslow.cia-g.com [206.206.162.5]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA14448 for ; Thu, 12 Dec 1996 06:33:52 -0800 (PST) Received: from maslow.cia-g.com (maslow.cia-g.com [206.206.162.5]) by maslow.cia-g.com (8.8.3/8.7.3) with SMTP id HAA02802; Thu, 12 Dec 1996 07:32:56 -0700 (MST) Date: Thu, 12 Dec 1996 07:32:56 -0700 (MST) From: Stephen Fisher To: David Greenman cc: Michael Smith , Brian Tao , freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110432.UAA10905@root.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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 >