From owner-freebsd-security Tue Dec 10 22:27:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA20726 for security-outgoing; Tue, 10 Dec 1996 22:27:28 -0800 (PST) Received: from obie.softweyr.com (slc148.modem.xmission.com [204.228.136.148]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id WAA20713 for ; Tue, 10 Dec 1996 22:27:24 -0800 (PST) Received: (from wes@localhost) by obie.softweyr.com (8.7.5/8.6.12) id XAA00240; Tue, 10 Dec 1996 23:27:12 -0700 (MST) Date: Tue, 10 Dec 1996 23:27:12 -0700 (MST) Message-Id: <199612110627.XAA00240@obie.softweyr.com> From: Wes Peters To: Michael Smith CC: security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) In-Reply-To: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> References: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> 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. Michael Smith opined: > 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 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. Better yet, get some sort of sniffer package to run on another system. We use Ether Peek for Macintosh and Win95 at work, both seem to work well. In addition to *not* opening up your important machines to hack attacks, such a tool will also let you look at non-IP activity, bare ethernet activity, and let you examine the output of a machine that seems to be going sick in the ether adapter. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com