Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Mar 2001 00:53:29 -0500
From:      Peter Radcliffe <pir@pir.net>
To:        security@FreeBSD.ORG
Subject:   Re: SSHD revelaing too much information.
Message-ID:  <20010328005329.A28036@pir.net>
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
References:  <20010327005503.J5425@rfx-216-196-73-168.users.reflex> <Pine.NEB.3.96L.1010326205118.81313D-100000@fledge.watson.org> <p05010404b6e5bb325d3c@[128.113.24.47]> <20010327005503.J5425@rfx-216-196-73-168.users.reflex> <p05010407b6e693b73e7c@[128.113.24.47]> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
"Jeffrey J. Mountin" <jeff-ml@mountin.net> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010328005329.A28036>