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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:17:05 PDT