From owner-freebsd-security Tue Dec 10 20:33:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id UAA10031 for security-outgoing; Tue, 10 Dec 1996 20:33:08 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id UAA10022 for ; Tue, 10 Dec 1996 20:33:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id UAA10905; Tue, 10 Dec 1996 20:32:02 -0800 (PST) Message-Id: <199612110432.UAA10905@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith cc: taob@io.org (Brian Tao), freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-reply-to: Your message of "Wed, 11 Dec 1996 14:23:22 +1030." <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: dg@root.com Date: Tue, 10 Dec 1996 20:32:02 -0800 Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >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