Date: Wed, 11 Dec 1996 14:23:22 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: taob@io.org (Brian Tao) Cc: freebsd-security@freebsd.org Subject: Re: Risk of having bpf0? (was URGENT: Packet sniffer found on my system) Message-ID: <199612110353.OAA21602@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.BSF.3.95.961210215417.9494P-100000@nap.io.org> from Brian Tao at "Dec 10, 96 09:58:09 pm"
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 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. > Brian Tao (BT300, taob@io.org, taob@ican.net) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612110353.OAA21602>