From owner-freebsd-security Tue Mar 27 21:53:36 2001 Delivered-To: freebsd-security@freebsd.org Received: from moek.pir.net (moek.pir.net [130.64.1.215]) by hub.freebsd.org (Postfix) with ESMTP id E9C7B37B71A for ; Tue, 27 Mar 2001 21:53:31 -0800 (PST) (envelope-from pir@pir.net) Received: from pir by moek.pir.net with local (Exim) id 14i8te-0007V7-00 for security@FreeBSD.ORG; Wed, 28 Mar 2001 00:53:30 -0500 Date: Wed, 28 Mar 2001 00:53:29 -0500 From: Peter Radcliffe To: security@FreeBSD.ORG Subject: Re: SSHD revelaing too much information. Message-ID: <20010328005329.A28036@pir.net> Reply-To: security@freebsd.org Mail-Followup-To: security@FreeBSD.ORG References: <20010327005503.J5425@rfx-216-196-73-168.users.reflex> <20010327005503.J5425@rfx-216-196-73-168.users.reflex> <4.3.2.20010327160147.02c1b6c0@207.227.119.2> <20010327173454.J12888@pir.net> <4.3.2.20010327173917.02803ae0@207.227.119.2> <20010327194550.A20633@pir.net> <4.3.2.20010327215647.02842490@207.227.119.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.20010327215647.02842490@207.227.119.2>; from jeff-ml@mountin.net on Tue, Mar 27, 2001 at 10:24:28PM -0600 X-fish: < X-Copy-On-Listmail: Please do NOT Cc: me on list mail. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jeffrey J. Mountin" probably said: > Does it even announce that it is BIND. If not then the reason might be due > to them thinking it isn't BIND. The status from a query of version.bind txt chaos is 'REFUSED', which non-bind servers do not give. Some people may not know this, however. > Was thinking more about how you internally configure the server and > internal network. As you mention BIND, there are 3 ways to run it. Was > thinking more along the lines of limiting the scope of a compromise. and yes, I also don't run it in anything like the default configuration, doesn't run as root, etc. As I said early on, obscurity is not something to rely on. > "Hmmm... this a FBSD system, let's just move on and find some M$ system." part of my point is that this is an application level problem, not a system level problem. The fact that it's a FreeBSD box is pretty much irrelevant to me, the _application_ is giving out information it doesn't need to and has no way of turning this off. If you think it should be done by the individual to prevent automated detection of obscured information then that isn't easy either; there is no reasonable way for the administrator to make the choice to turn it off or obscure it, you have to recompile and replacing it everywhere. > You could say we are betting on different outcomes. 8-) I would say the same thing I've said in practically all of these emails; we disagree. P. -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message