Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Sure, you’ve heard it a thousand times: “Get rid of your creaky, leaky old NIS/NFS mess. Replace it with Samba.” Conspicuously absent from these unsolicited exhortations are offers of help, because it is no small task to replace NIS/NFS, and the choices you make about them can badly affect network security.
It is true that NIS/NFS (network information service, network file system) were created in earlier, more innocent times. It is also true that you don’t need to chuck them just yet. For serving a Unix/Linux LAN, they work fine. And they can be integrated with Samba, so you can harmoniously introduce Windows hosts without overhauling your network.
Problems
NIS/NFS relies trustingly on UIDs (user IDs) and GIDs (group IDs). Here comes a client knocking on the server’s door, claiming to be a particular UID, and the server won’t know any better. So theoretically, any user could be maliciously masqueraded.
Both run on unprivileged ports, which means any user can run them. A malicious user could replace the NIS/NFS daemons with evil, twisted imposters, which would give an intruder free rein on your network.
If an intruder gains access to your LAN, they could easily bind to your NIS domain. How? It would take guessing the name of your NIS domain, then simply running ypcat to glom your entire NIS database. No authentication needed. Let’s say the NIS domain is fred and the hostname is ginger:
$ ypcat -d fred -h ginger passwd
Well there goes your password map. If they manage to escalate to root privileges, they can capture /etc/shadow, and there goes the master key to your network:
# ypcat -d fred -h ginger shadow
Network traffic is unencrypted, so eavesdroppers will have an easy time of it.
Root is “squashed” by default; that is, anytime UID 0 makes a request, it is demoted to an ordinary user with limited privileges. But privilege escalation is Job 1 of any attacker, so it’s a weak defense, because any user is a potential point of entry.
Then our old friend portmap, which does dynamic port assignment for NIS and NFS, is about as inherently secure as NIS/NFS.
Fixes
The biggest potential problem is a compromised client, which is then used to launch attacks on your nice NIS/NFS servers. So don’t run NIS/NFS over untrusted networks. Keep your servers tucked safely behind firewalls, protected from the big bad world. Then your problems are limited to your local users. Which may or may not be a comfort, as they tend to display ingenuity and persistence at all the wrong times.
Keep your daemons and utilities patched and updated. Yada yada, you hear it all the time, and it’s good advice no matter how many times you hear it. And no root passwords on your NIS/NFS servers! Keep root strictly local.
NIS
This is a bit tricky, as it is supposed to provide directory service, including central access to /etc/passwd, /etc/group, and /etc/hosts, so anything you do to impair intruders may also get in the way of users. So keep it local, don’t serve clients across untrusted networks, and don’t replicate to slave servers across untrusted networks.
Again, rehashing the same old nag, how good are your user’s passwords? Do you enforce a stern password policy that forbids names, dictionary words, birthdays, Social Security Numbers, and writing them on Post-Its? Most “experts” advise that no one ever write down a password; use weirdo mnemonics to remember them, like PBLMGMS, which is pronounced “peanut butter loves my gums.” Phooey, says I. Train your users to write down their passwords and keep them in a safe place. Like their wallets, or a locked file drawer.
How up-to-date are your user accounts? Obsolete accounts for long-gone users and test accounts are notorious points of entry for an attacker. I don’t know of any way but tedious manual perusal to weed these out. However you can use this to look for null passwords:
$ getent passwd | awk -F ':' '{ if ($2 == "") { print $0; } }'
fred::713:713:fred smith,,,:/home/fred:/bin/bash
getent is a dandy little command that will not return your NIS entries, which have all but the first field empty:
+alice::::::
Use /var/yp/securenets to control which hosts can access the NIS server. NIS listens for the whole wide world by default. Even though it’s tucked behind a nice firewall, and serves only the LAN, it’s good insurance. You can define a range, and individual hosts:
255.255.255.0 192.168.1.0 host 216.239.39.99
NFS
Take a good look in /etc/exports and /etc/netgroup. Are they up to date? Weed out stale and incorrect entries.
In/etc/exports, check filesystem permissions. Never have entries without permissions. Make them as precise as you can:
/home 192.168.1.101(rw) 192.168.1.102(ro)
Watch your whitespaces. Make sure that /etc/exportsand /etc/netgroup are mode 644, and owned by root:root. Remember to run /etc/exportfs to activate the changes.
Run the showmount -e command at any time to see a list of directories exported by the NFS server:
# showmount -e Export list on local host /home ellen.hardwork.net
Securing Portmap
Once again, a stateful firewall is quite valuable. The first pair rule drops all TCP and UDP packets not from the local network, and the second pair allows localhost.
iptables -A INPUT -p tcp -s! $LAN --dport 111 -j DROP iptables -A INPUT -p udp -s! $LAN --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT iptables -A INPUT -p udp -s 127.0.0.1 --dport 111 -j ACCEPT
Don’t forget your TCP wrappers, /etc/hosts.allow and /etc/hosts.deny. This is an entry for /etc/hosts.allow:
portmap : server.hardwork.net 192.168.1.
This line in /etc/hosts.deny. denies all but allowed traffic for portmap:
portmap : ALL
Remember to restart your NIS or NFS daemons after making changes.
Dead Tree Help
The book “Managing NFS and NIS” by Mike Eisler, Ricardo Labiaga, and Hal Stern is a good reference for all aspects of using NIS/NFS. If you really want to go nuts on security, the book has a chapter on using various forms of keys and encryption.
NIS/NFS are not obsolete yet. You have to be careful, but these days that is true of everything.
