Re: NMRC Advisory - Default NDS Rights

[thegnome () NMRC ORG (Simple Nomad)]

I guess I should make it clear that you CAN configure NDS to not allow
public browse access to container contents, but still allow the names of
the containers to be displayed. This would allow a legit user to browse up
and down the tree looking for their context, without revealing valid
names.

As has been pointed out to me, Intruder Detect is not only off by default
but has to be manually turned on in each container. This means that by
default I can get a list of user names and perform a dictionary or brute
force attack without those annoying console messages giving away my
location. In fact the Pandora tools include a utility to help "automate"
this attack process (at least a dictionary attack).

Personally I consider this a security problem. Not critical, but something
to consider if your security policy involves not giving intruders half the
equation to log in AND not allowing undetected attacks against accounts.

-SN

P.S. - Yes this is mainly for the internal threat, I promise to work on
access to that SYS:LOGIN directory ;-)

On Sat, 19 Sep 1998, costello, don wrote:

> First of all, simply displaying login ID's or their context is not
> necessarily a security risk (millions disagree, I know, but it's not the
> real risk), provided all other aspects of the security system are in tact.
> What IS a risk is faulty passwords (ie blank, easily guessed, never expire,
> etc).  In this case, the real risk is the carelessness of the administrator,
> not a flaw with the system.
>
> What you're suggesting here is not really a fix, rather it is a removal of
> necessary functionality needed by "trusted" users of a Novell network.  In
> fact, Novell has said that it is widely known that, if the presence if CX or
> NLIST poses some paranoia in your environment, you should delete these
> utilities from SYS:LOGIN, not modify the rights structure of the NDS tree.
> (I happened to learn this in training but others will more than likely
> concur).  A non-logged in connection NEEDS read access to containers in
> order to set their starting context as well as walk the tree if the default
> context is not correct.  By virtue of READ being on the container, all
> objects in that container can be displayed.  It's a judgement call whether
> or not this poses any *real* threat.
>
> Besides, just to get access to the SYS:LOGIN directory itself is quite a
> touch trick.  Unless *all* routers along a given path are running IPX or the
> site is running Netware IP, it would take some pretty nifty talent to even
> get to the LOGIN directory.  Of course, you can never prevent the internal
> threat.