From: prl@iis.ethz.ch (Peter Lamb) Newsgroups: alt.security,comp.unix.admin Subject: Re: NIS and password security Keywords: NIS, YP, passwords Message-ID: Date: 5 Nov 91 11:24:21 GMT References: <1991Nov3.162147.14010@frcs.Alt.ZA> Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH dank@blacks.jpl.nasa.gov (Dan Kegel) writes: >prl@iis.ethz.ch (Peter Lamb) writes: >>Without a firewall, NIS permits your passwd and passwd.adjunct maps >>to be read from any machine that can route packets to and from your >>server. >This is supposedly fixed in NIS 3.0, which I think will ship with >SunOS 4.1.2. Good. I had been unable to find out a shipping date for NIS 3.0. >In the meantime, connect your local net to the Internet >through a Cisco router, and refuse to route packets using the sunrpc >tcp or udp ports (is that right, Peter?) Nope. Disabling access to the sunrpc port (port #111, tcp & udp, usually served by portmapper) will stop some attacks, most notably the ones possible using vendor-supplied utilities, and the most obvious of the do-it-yourself attacks, but will not prevent more intelligent attacks. It is necessary to block access on all ports 600-1023 to prevent the attacks reliably. Then it doesn't really matter if the portmapper can be addressed or not. (Un)fortunately, this blocks access to all RPC services which use a Unix privileged port but it is the only reliable method, since RPC-to-port registration is pseudo-random (in that range). Disabling access to port nfs/udp (port #2049) in the firewall is probably a good idea too. None of this helps, of course, if a machine on the wrong side of the firewall gets cracked by some other method. >A second wall of protection can be had by replacing passwd with npasswd, >which will prevent people from using easily-crackable passwords. >Npasswd (with my local changes) is available for ftp from blacks.jpl.nasa.gov >in pub/security. >- Dan Kegel (dank@blacks.jpl.nasa.gov) Yes, this is a good precaution. After installing this, you should make a copy of the password file, and then insist that everyone run their current password through npasswd, and change it if the current password was unacceptable, and after a reasonable delay, diff the old username:passwd fields of the old and new files to make sure that every password has been vetted (this allows users to keep their old password if it was OK, since each password has only a 1/4096 probability of having the same encryption if the password text itself is the same). Choosing a non-obvious NIS domain-name will also make it more difficult for a remote cracker to gain access to your NIS maps (yes, this is security-through-obscurity). Using Kerberos/Hesiod is a good alternative. Peter Lamb (prl@iis.ethz.ch)