NIS stands for Network Information Service. It is an RPC service,
called ypserv, which is used in
conjunction with portmap and other related
services to distribute maps of usernames, passwords, and other
sensitive information to any computer claiming to be within its
An NIS server is comprised of several applications. They include
/usr/sbin/rpc.yppasswdd — Also
called the yppasswdd service, this daemon
allows users to change their NIS passwords.
/usr/sbin/rpc.ypxfrd — Also
called the ypxfrd service, this daemon is
responsible for NIS map transfers over the network.
/usr/sbin/yppush — This
application propagates changed NIS databases to multiple NIS
/usr/sbin/ypserv — This is the
NIS server daemon.
NIS is rather insecure by todays standards. It has no host
authentication mechanisms and passes all of its information over
the network unencrypted, including password hashes. As a result,
extreme care must be taken to set up a network that uses NIS.
Further complicating the situation, the default configuration of
NIS is inherently insecure.
It is recommended that anyone planning to implement an NIS
server first secure the portmap service as
outlined in Section 5.2 Securing
Portmap, then address the following issues, such as network
Because NIS passes sensitive information unencrypted over the
network, it is important the service be run behind a firewall and
on a segmented and secure network. Any time NIS information is
passed over an insecure network, it risks being intercepted.
Careful network design in these regards can help prevent severe
Any machine within an NIS domain can use commands to extract
information from the server without authentication, as long as the
user knows the NIS server's DNS hostname and NIS domain name.
For instance, if someone either connects a laptop computer into
the network or breaks into the network from outside (and manages to
spoof an internal IP address), the following command reveals the
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
If this attacker is a root user, they can obtain the /etc/shadow file by typing the following
ypcat -d <NIS_domain> -h <DNS_hostname> shadow
If Kerberos is used, the /etc/shadow
file is not stored within an NIS map.
To make access to NIS maps harder for an attacker, create a
random string for the DNS hostname, such as o7hfawtgmhwg.domain.com. Similarly, create a
different randomized NIS domain name. This
makes it much more difficult for an attacker to access the NIS
NIS listens to all networks, if the /var/yp/securenets file is blank or does not exist
(as is the case after a default installation). One of the first
things to do is to put netmask/network pairs in the file so that
ypserv only responds to requests from the
Below is a sample entry from a /var/yp/securenets file:
Never start an NIS server for the first time without creating
the /var/yp/securenets file.
This technique does not provide protection from an IP spoofing
attack, but it does at least place limits on what networks the NIS
All of the servers related to NIS can be assigned specific ports
except for rpc.yppasswdd — the
daemon that allows users to change their login passwords. Assigning
ports to the other two NIS server daemons, rpc.ypxfrd and ypserv,
allows for the creation of firewall rules to further protect the
NIS server daemons from intruders.
To do this, add the following lines to /etc/sysconfig/network:
The following IPTables rules can be issued to enforce which
network the server listens to for these ports:
iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP
iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP
Refer to Chapter 7 Firewalls for
more information about implementing firewalls with IPTables
One of the most glaring flaws inherent when NIS is used for
authentication is that whenever a user logs into a machine, a
password hash from the /etc/shadow map is
sent over the network. If an intruder gains access to an NIS domain
and sniffs network traffic, usernames and password hashes can be
quietly collected. With enough time, a password cracking program
can guess weak passwords, and an attacker can gain access to a
valid account on the network.
Since Kerberos uses secret-key cryptography, no password hashes
are ever sent over the network, making the system far more secure.
For more about Kerberos, refer to the chapter titled Kerberos in the Red Hat
Enterprise Linux Reference Guide.