Solaris NIS Security

(part 4 of the Solaris NIS mini-tutorial)

Contents

There are a few precautions that can be taken to make NIS in Solaris more secure:

If you are trying to keep your NIS maps private to hide hostnames or usernames within your network, do not make any host that is on two or more networks an NIS server. Users on the external networks can forcibly bind to your NIS domain and dump the NIS maps from a server that is also performing routing duties. While the same trick may be performed if the NIS server is inside the router, it can be defeated by disabling IP packet forwarding on the router for NIS-related ports.
On the master NIS server, separate the server's password file and the NIS password file so that all users in the NIS password file do not automatically gain access to the NIS master server.
Avoid changing UID or GID outside of maintenance windows. If a user's UID changes while he or she is logged in, many utilities break in esoteric ways. Simple editing mistakes, such as deleting a digit in the UID field of the password file and then distributing the "broken" map file, are enough to create a lot of trobles. Replacement of an NIS password file entry with a local password file entry where the two UIDs are not identical is another error that causes a UID mismatch.
The whoami command replies with "no login associated with uid" if the effective UID of its process cannot be found in the password file. Other utilities that check the validity of UIDs are rcp, rlogin, and rsh, all of which generate "can not find password entry for user id" messages if the user's UID cannot be found in the password map.

Securenets

Any remote user can issue an RPC call to ypserv and retrieve the contents of your NIS maps, provided the remote user knows NIS domainname. To prevent such unauthorized transactions, ypserv supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, ypserv will attempt to load /var/yp/securenets file that limits access to NIS services. If it exists after loading it, the server only answers queries/supplies maps to hosts and networks whose IP addresses exist in the file. The server must be able to access itself. Therefore the following entry should be present:

host 127.0.0.1

The following example describes a securenets file where:

The server is configured to access itself.
A class C network 50.10.1.0 is configured for access.
Two specific hosts, 50.10.12.1 and 50.10.14.1, are configured to access the NIS information.

host 127.0.0.1
255.255.255.0 50.10.1.0
host 50.10.12.1
host 50.10.14.1

After modification of the /var/yp/securenets file, you need to restart the ypserv and ypxfrd daemons:

# /usr/lib/netsvc/yp/ypstop && /usr/lib/netsvc/yp/ypstart

The passwd.adjunct File

The passwd.adjunct file prevents disclosing the encrypted passwords that normally form part of the output when viewing the NIS passwd maps to unauthoriaed users.

Encrypted passwords are normally hidden from the user in the /etc/shadow file. With the default NIS configuration, however, the encrypted password string is shown as part of the passwd maps.

The following example shows that if passwd.adjunct file exists, then user passwd is hidden from view when viewing the /etc/passwd file:

# cat /etc/passwd | grep joeuser
joeuser:x:10001:10001::/export/home/joeuser:/bin/ksh

When the ypmatch command runs against the joeuser account value in the passwd map, the following output appears:

# ypmatch -k joeuser passwd
joeuser: joeuser:LojyTdiQev5i2:10001:10001::/export/home/joeuser:/bin/ksh

The encrypted user password is included as part of the NIS passwd maps. To maintain the same security, the system configures the passwd.adjunct file. The passwd.adjunct file contains the account name preceded by ## in the password field. After that the ypcat or ypmatch commands, returns the password entry from the passwd.adjunct file, as follows:

# ypmatch -k joeuser passwd
joeuser:##joeuser:10001:10001::/export/home/joeuser:/bin/ksh

To enable the passwd.adjunct file you need to configure configure C2 security features. See http://sunsolve.sun.com for details.

Contents

Copyright © 1996-2009 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with.
We do not warrant the correctness of the information provided or its fitness for any purpose
In no way this site is associated with or endorse cybersquatters using the term "softpanorama" with other main or country domains (e.g. softpanorama.com) with bad faith intent to profit from the goodwill belonging to someone else.

Last modified: August 10, 2009