[CfD] Securing NIS

F

fonz

Granted, we don't get a lot of NIS questions here, but still. Out of the box, NIS has some inherent (potential) security issues. I felt like trying to start a discussion, identifying what the (potential) security threats are and figuring out how to mitigate them.

I can think of the following three threats myself:
  1. Users can obtain a list of usernames and the accompanying password hashes, which they can feed to a password cracker, thus obtaining other users' passwords.
  2. Any host on the Internet can connect to your NIS server(s) and obtain the same.
  3. NIS traffic is unencrypted. If I'm not mistaken NIS is not stupid enough to transmit passwords in the clear, but still the password hashes can be intercepted.
And my assessment:
  1. This I think is a thing of the past. Sure, back in the late '90s and early '00s I used to do this regularly at the university. I just did ypcat passwd, took the result home, fired up John the Ripper and let it run overnight and/or while I was away. This would usually reveal at least 5 or 10 users with lame passwords. Obviously, I always mailed the results to the head sysadmin who would then break out the LART ;) However, FreeBSD's implementation of NIS can be configured to not export the master.passwd map. In fact, this is default behaviour. ypcat passwd works fine but returns the passwd map, which has the passwords starred out. ypcat master.passwd only works for root, mortal users simply get an error message.
  2. This sounds like nothing a good firewall/router setup can't fix. Just make sure any NIS servers are only accessible from the local network. NIS also has access control (/var/yp/securenets), but I'm not sure whether this is vulnerable to spoofing. It may not offer as much security as one would think.
  3. This does sound like a potentially big problem. Has anyone ever tried to fiddle with some kind of encryption layer (e.g. SSH tunnelling) around NIS?

Any additions, suggestions, solutions, corrections etc. are welcome.
 
I rarely find anyone that still uses it. And when they do use it they suffer from the first threat on your list. Most people will probably have migrated to LDAP by now. Which has it's own issues but should be easier to secure.
 
1. You must have a very tightly locked down network or the NIS server in a separate DMZ, otherwise it's trivial to boot your own Linux laptop, connect to the network and fetch the master.passwd map. The NIS protocol has no means of authentication so the only way to restrict access is a firewall.
 
SirDice said:
I rarely find anyone that still uses it.
Click to expand...
I do :) Not in a production environment obviously, I use it on my server at home to share users between jails.

But yes, NIS is old and it's starting to show.

SirDice said:
Most people will probably have migrated to LDAP by now. Which has it's own issues but should be easier to secure.
Click to expand...
Last time I checked LDAP was reportedly rather a faff to set up on FreeBSD. Has there been any improvement in that area?

kpa said:
1. You must have a very tightly locked down network or the NIS server in a separate DMZ, otherwise it's trivial to boot your own Linux laptop, connect to the network and fetch the master.passwd map.
Click to expand...
That's a good shout. I knew about this, but it had completely slipped my mind :r I would think that there'd be an option to just disable exportation of master.passwd altogether (including for root), but I can't find anything.
 
It may sound crazy now but the NIS server decides to give access to super user only maps like master.passwd based on the source port of the request. If the request comes from a privileged port < 1024 the client has access to the restricted maps.
 
kpa said:
It may sound crazy now but the NIS server decides to give access to super user only maps like master.passwd based on the source port of the request. If the request comes from a privileged port < 1024 the client has access to the restricted maps.
Click to expand...
Exactly. So it should be fairly straightforward to turn it off.
 
The inventor of NIS+ recommends not to use it. From the wikipedia NIS+ entry:
NIS+ is a directory service developed by Sun Microsystems to replace its older 'NIS' (Network Information Service). It is designed to eliminate the need for duplication across many computers of configuration data such as user accounts, host names and addresses, printer information and NFS disk mounts on individual systems, instead using a central repository on a master server, simplifying system administration. NIS+ client software has been ported to other Unix and Unix-like platforms.

Prior to the release of Solaris 9 in 2002, Sun announced its intent to remove NIS+ from Solaris in a future release and now recommends that customers instead use an LDAP-based lookup scheme.

NIS+ was present in Solaris 9 and 10 (although both releases include tools to migrate NIS+ data to an LDAP server)[1] and it has now been removed from Solaris 11.1.[2]
Click to expand...
 
You must log in or register to reply here.
Back
Top