See comments below. > > On Mon, 17 Dec 2001, Carol Smith wrote: > > > Does anyone use NIS+ to go across a firewall to the dmz? If yes (or no) > > what issues should I be concerned with? > > I vote no:
I vote NO! > > As a general rule of thumb, I recommend against sharing authentication > credentials over a trust boundary. If a server gets compromised (and > generally systems in a DMZ are at higher risk to compromise) and > you're using the same credentials for internal services, VPN access, etc. > then your authentication realm is compromised. Seondly, if a compromise > in the DMZ works, it's possible to go from outside in if the NIS server > has a bug-- generally I like my firewall->DMZ traffic to be outbound. > > A config oops on NIS+ to enable NIS compat mode will make your > encrypted password file obtainable externally- that can't be a good thing. >From the perspective of someone that has spent quite a bit of time working with NIS+, I think the insecurity issues are even worse than those illustrated above. It is important to remember that NIS+ was designed around 1991, and for its day it was a fairly secure enterprise directory service. That really doesn't account for much today. For example, in order for NIS+ to operate properly, the perms on the cred.org_dir table MUST be READABLE by NOBODY (unauthenticated principals). The cred.org_dir table contains both the public and PRIVATE DH keys of all principals within the NIS+ domain. The private DH key for the principal, be it a user or a host, is encrypted using the network password of the principal. In the case of a host, this is typically the ROOT password of the host, and in the case of a user, it's their network (NIS+) login password. Of course, this doesn't have to be the case, the Secure RPC Password could indeed differ from that of the network password, but this would require an administrator to physically keylogin a box after reboot to authenticate it, or in the case of a user principal for the user to manually keylogin after each login (highly unlikely that anyone will tolerate network pass != secure RPC pass for long). The APIs to decrypt the DH private key are published interfaces, and writing a crack equivalent to brute force a DH private key from a cred.org_dir dump is quite trivial. The cred.org_dir table is actually MUCH more useful then a standard YP/NIS passwd.byname table, since it provides an opportunity to crack ROOT accounts across an entire domain. And of course, anyone with knowledge of NIS+ would focus on the root password for the NIS+ master which would provide rmcd perms for literally the entire domain. This is only the tip of the iceberg for NIS+ insecurity - e.g. during initialization of a NIS+ client the "nisinit -cH <master>" command is used to pull the public key of the master across a network in the CLEAR, and the client trusts it - no issue. I would advise NEVER to run NIS+ outside of a very secure intranet, and to begin looking very seriously at some of the better LDAPv3 implementations for a new directory service ASAP on your intranet. NIS+ will not be supported for much longer, on any platform. Best to begin migration plays ASAP. > > Password guessing and rpcbind worms aside, it just feels wrong. > Strongly agree with the above as well. Allowing rpcbind through a FW is suicidal. Brett Lynch [EMAIL PROTECTED] _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
