os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

This patch provides general tightening and clarification of the sections NIS Slave Servers through NIS Security.

Browse source
This commit is contained in:
Dru Lavigne 2013-10-15 22:03:04 +00:00
parent b15a185fc3
commit 97f01eecdc
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=42970
1 changed files with 111 additions and 150 deletions
Download patch file Download diff file Expand all files Collapse all files

257
en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
View file

@ -1517,14 +1517,16 @@ ellington has been setup as an YP master server without any errors.</screen>
<primary>NIS</primary> <primary>NIS</primary>
<secondary>slave server</secondary> <secondary>slave server</secondary>
</indexterm> </indexterm>
<para>Setting up an <acronym>NIS</acronym> slave server is <para>To set up an <acronym>NIS</acronym> slave server, log on to
simpler than setting up the master. Log on to
the slave server and edit the slave server and edit
<filename>/etc/rc.conf</filename> as before. This <filename>/etc/rc.conf</filename> as for the master server.
time, include Do not generate any <acronym>NIS</acronym> maps, as these
<option>-s</option> when running already exist on the master server. When running
<command>ypinit</command>. This option <command>ypinit</command> on the slave server, use
requires the name of the <acronym>NIS</acronym> master, as <option>-s</option> (for slave) instead of
<option>-m</option> (for master). This option
requires the name of the <acronym>NIS</acronym> master in
addition to the domain name, as
seen in this example:</para> seen in this example:</para>
<screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput> <screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput>
@ -1584,56 +1586,51 @@ ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any errors. coltrane has been setup as an YP slave server without any errors.
Remember to update map ypservers on ellington.</screen> Remember to update map ypservers on ellington.</screen>
<para>There should be a directory called <para>This will generate a directory on the slave server called
<filename>/var/yp/test-domain</filename>. Copies of the <filename class="directory">/var/yp/test-domain</filename> which contains copies of the
<acronym>NIS</acronym> master server's maps should be in <acronym>NIS</acronym> master server's maps.
this directory. These files must always be up to date. Adding these <filename>/etc/crontab</filename> entries on each
The following <filename>/etc/crontab</filename> entries on slave server will force the slaves to sync their maps with
the slave servers should do the job:</para> the maps on the master server:</para>
<programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname <programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting> 21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting>
<para>These two lines force the slave to sync its maps with <para>These entries are not
the maps on the master server. These entries are not
mandatory because the master server automatically attempts mandatory because the master server automatically attempts
to push any map changes to its slaves; however, due to to push any map changes to its slaves. However, since clients may
the importance of correct password information on other depend upon the slave server to provide correct password information,
clients depending on the slave server, it is recommended it is recommended
to specifically force the password map updates frequently. to force frequent password map updates.
This is especially important on busy networks where map This is especially important on busy networks where map
updates might not always complete.</para> updates might not always complete.</para>
<para>Now, run the command <command>/etc/netstart</command> <para>To finish the configuration, run <command>/etc/netstart</command>
on the slave server as well, which again starts the NIS on the slave server in order to start the <acronym>NIS</acronym>
server.</para> services.</para>
</sect2> </sect2>
<sect2> <sect2>
<title>Setting Up a <acronym>NIS</acronym> Client</title> <title>Setting Up an <acronym>NIS</acronym> Client</title>
<para>An <acronym>NIS</acronym> client establishes what is <para>An <acronym>NIS</acronym> client binds
called a binding to a particular <acronym>NIS</acronym> to an <acronym>NIS</acronym>
server using the <command>ypbind</command> daemon. The server using &man.ypbind.8;. This
<command>ypbind</command> command checks the system's daemon
default domain (as set by the broadcasts RPC requests on the local network. These
<command>domainname</command> command), and begins requests specify the domain name configured on the client.
broadcasting RPC requests on the local network. These If an <acronym>NIS</acronym> server in the same domain
requests specify the name of the domain for which receives one of the broadcasts, it will
<command>ypbind</command> is attempting to establish a respond to <application>ypbind</application>, which will record the
binding. If a server that has been configured to serve the server's address. If there are several servers available,
requested domain receives one of the broadcasts, it will the client will use the address of the first
respond to <command>ypbind</command>, which will record the server to respond and will
server's address. If there are several servers available (a
master and several slaves, for example),
<command>ypbind</command> will use the address of the first
one to respond. From that point on, the client system will
direct all of its <acronym>NIS</acronym> requests to that direct all of its <acronym>NIS</acronym> requests to that
server. <command>ypbind</command> will occasionally server. The client will automatically
<quote>ping</quote> the server to make sure it is still up <application>ping</application> the server on a regular basis to make sure it is still
and running. If it fails to receive a reply to one of its available. If it fails to receive a reply
pings within a reasonable amount of time, within a reasonable amount of time,
<command>ypbind</command> will mark the domain as unbound <application>ypbind</application> will mark the domain as unbound
and begin broadcasting again in the hopes of locating and begin broadcasting again in the hopes of locating
another server.</para> another server.</para>
@ -1641,16 +1638,15 @@ Remember to update map ypservers on ellington.</screen>
<secondary>client configuration</secondary> <secondary>client configuration</secondary>
</indexterm> </indexterm>
<para>Setting up a &os; machine to be a <para>To configure a &os; machine to be an
<acronym>NIS</acronym> client is fairly <acronym>NIS</acronym> client:</para>
straightforward.</para>
<procedure> <procedure>
<step> <step>
<para>Edit <filename>/etc/rc.conf</filename> and add the <para>Edit <filename>/etc/rc.conf</filename> and add the
following lines in order to set the following lines in order to set the
<acronym>NIS</acronym> domain name and start <acronym>NIS</acronym> domain name and start
<command>ypbind</command> during network &man.ypbind.8; during network
startup:</para> startup:</para>
<programlisting>nisdomainname="test-domain" <programlisting>nisdomainname="test-domain"
@ -1659,40 +1655,34 @@ nis_client_enable="YES"</programlisting>
<step> <step>
<para>To import all possible password entries from the <para>To import all possible password entries from the
<acronym>NIS</acronym> server, remove all user <acronym>NIS</acronym> server, use
accounts from the <command>vipw</command> to remove all user
<filename>/etc/master.passwd</filename> file and use accounts except one from
<command>vipw</command> to add the following line to <filename>/etc/master.passwd</filename>. When removing
the accounts, keep in mind that at least one local account
should remain and this
account should be a member of
<groupname>wheel</groupname>. If there is a problem
with <acronym>NIS</acronym>, this local account can be used to log in
remotely, become the superuser, and fix
the problem. Before saving the edits, add the following line to
the end of the file:</para> the end of the file:</para>
<programlisting>+:::::::::</programlisting> <programlisting>+:::::::::</programlisting>
<note> <para>This line configures the client to provide anyone with a valid
<para>This line will afford anyone with a valid
account in the <acronym>NIS</acronym> server's account in the <acronym>NIS</acronym> server's
password maps an account. There are many ways to password maps an account on the client. There are many ways to
configure the NIS configure the <acronym>NIS</acronym>
client by changing this line. See the client by modifying this line. One method is described in
<link linkend="network-netgroups">netgroups <xref linkend="network-netgroups"/>. For
section</link> below for more information. For more detailed reading, refer to the book
more detailed reading see O'Reilly's book on <literal>Managing NFS and NIS</literal>, published by
<literal>Managing NFS and NIS</literal>.</para> O'Reilly Media.</para>
</note>
<note>
<para>Keep in mind that at least one local account
(i.e. not imported via NIS) must exist in
<filename>/etc/master.passwd</filename> and this
account should also be a member of the group
<groupname>wheel</groupname>. If there is something
wrong with NIS, this account can be used to log in
remotely, become <username>root</username>, and fix
things.</para>
</note>
</step> </step>
<step> <step>
<para>To import all possible group entries from the NIS <para>To import all possible group entries from the <acronym>NIS</acronym>
server, add this line to server, add this line to
<filename>/etc/group</filename>:</para> <filename>/etc/group</filename>:</para>
@ -1707,32 +1697,27 @@ nis_client_enable="YES"</programlisting>
<screen>&prompt.root; <userinput>/etc/netstart</userinput> <screen>&prompt.root; <userinput>/etc/netstart</userinput>
&prompt.root; <userinput>service ypbind start</userinput></screen> &prompt.root; <userinput>service ypbind start</userinput></screen>
<para>After completing these steps, the command, <para>After completing these steps, running
<command>ypcat passwd</command>, should show the <command>ypcat passwd</command> on the client should show the
server's passwd map.</para> server's <filename>passwd</filename> map.</para>
</sect2> </sect2>
<sect2> <sect2>
<title><acronym>NIS</acronym> Security</title> <title><acronym>NIS</acronym> Security</title>
<para>In general, any remote user may issue an RPC to <para>Since <acronym>RPC</acronym> is a broadcast-based service,
&man.ypserv.8; and retrieve the contents of the any system running <application>ypbind</application> within the same domain
<acronym>NIS</acronym> maps, provided the remote user knows can retrieve the contents of the
the domain name. To prevent such unauthorized transactions, <acronym>NIS</acronym> maps. To prevent unauthorized transactions,
&man.ypserv.8; supports a feature called &man.ypserv.8; supports a feature called
<quote>securenets</quote> which can be used to restrict access <quote>securenets</quote> which can be used to restrict access
to a given set of hosts. At startup, &man.ypserv.8; will to a given set of hosts. By default, this information is stored in
attempt to load the securenets information from a file called <filename>/var/yp/securenets</filename>, unless &man.ypserv.8; is started with
<filename>/var/yp/securenets</filename>.</para> <option>-p</option> and an alternate path. This file contains entries
<note>
<para>This path varies depending on the path specified with
the <option>-p</option> option. This file contains entries
that consist of a network specification and a network mask that consist of a network specification and a network mask
separated by white space. Lines starting with separated by white space. Lines starting with
<quote>#</quote> are considered to be comments. A sample <literal>#</literal> are considered to be comments. A sample
securenets file might look like this:</para> <filename>securenets</filename> might look like this:</para>
</note>
<programlisting># allow connections from local host -- mandatory <programlisting># allow connections from local host -- mandatory
127.0.0.1 255.255.255.255 127.0.0.1 255.255.255.255
@ -1748,89 +1733,64 @@ nis_client_enable="YES"</programlisting>
matches one of these rules, it will process the request matches one of these rules, it will process the request
normally. If the address fails to match a rule, the request normally. If the address fails to match a rule, the request
will be ignored and a warning message will be logged. If the will be ignored and a warning message will be logged. If the
<filename>/var/yp/securenets</filename> file does not exist, <filename>securenets</filename> does not exist,
<command>ypserv</command> will allow connections from any <command>ypserv</command> will allow connections from any
host.</para> host.</para>
<para>The <command>ypserv</command> program also has support for <para><xref linkend="tcpwrappers"/> is
Wietse Venema's <application>TCP Wrapper</application> an alternate mechanism for providing
package. This allows the administrator to use the
<application>TCP Wrapper</application> configuration files for
access control instead of access control instead of
<filename>/var/yp/securenets</filename>.</para> <filename>securenets</filename>. While either access control mechanism adds
some security, they are both
<note>
<para>While both of these access control mechanisms provide
some security, they, like the privileged port test, are
vulnerable to <quote>IP spoofing</quote> attacks. All vulnerable to <quote>IP spoofing</quote> attacks. All
NIS-related traffic should be blocked at the <acronym>NIS</acronym>-related traffic should be blocked at the
firewall.</para> firewall.</para>
<para>Servers using <filename>/var/yp/securenets</filename> <para>Servers using <filename>securenets</filename>
may fail to serve legitimate <acronym>NIS</acronym> clients may fail to serve legitimate <acronym>NIS</acronym> clients
with archaic TCP/IP implementations. Some of these with archaic TCP/IP implementations. Some of these
implementations set all host bits to zero when doing implementations set all host bits to zero when doing
broadcasts and/or fail to observe the subnet mask when broadcasts or fail to observe the subnet mask when
calculating the broadcast address. While some of these calculating the broadcast address. While some of these
problems can be fixed by changing the client configuration, problems can be fixed by changing the client configuration,
other problems may force the retirement of the client other problems may force the retirement of these client
systems in question or the abandonment of systems or the abandonment of
<filename>/var/yp/securenets</filename>.</para> <filename>securenets</filename>.</para>
<para>Using <filename>/var/yp/securenets</filename> on a <indexterm><primary>TCP Wrapper</primary></indexterm>
server with such an archaic implementation of TCP/IP is a
really bad idea and will lead to loss of
<acronym>NIS</acronym> functionality for large parts of the
network.</para>
<indexterm><primary>TCP Wrappers</primary></indexterm>
<para>The use of <application>TCP Wrapper</application> <para>The use of <application>TCP Wrapper</application>
increases the latency of the <acronym>NIS</acronym> server. increases the latency of the <acronym>NIS</acronym> server.
The additional delay may be long enough to cause timeouts in The additional delay may be long enough to cause timeouts in
client programs, especially in busy networks or with slow client programs, especially in busy networks with slow
NIS servers. If one or more of the client systems suffers <acronym>NIS</acronym> servers. If one or more clients suffer
from these symptoms, convert the client systems in question from latency, convert those clients
into <acronym>NIS</acronym> slave servers and force them to into <acronym>NIS</acronym> slave servers and force them to
bind to themselves.</para> bind to themselves.</para>
</note>
</sect2>
<sect2> <sect3>
<title>Barring Some Users from Logging On</title> <title>Barring Some Users</title>
<para>In our lab, there is a machine <hostid>basie</hostid> that <para>In this example, the <hostid>basie</hostid> system
is supposed to be a faculty only workstation. We do not want is a faculty workstation within the <acronym>NIS</acronym> domain.
to take this machine out of the <acronym>NIS</acronym> domain, The <filename>passwd</filename> map on the master
yet the <filename>passwd</filename> file on the master
<acronym>NIS</acronym> server contains accounts for both <acronym>NIS</acronym> server contains accounts for both
faculty and students. What can we faculty and students. This section demonstrates how to allow
do?</para> faculty logins on this system while refusing student logins.</para>
<para>There is a way to bar specific users from logging on to a <para>To prevent specified users from logging on to a
machine, even if they are present in the system, even if they are present in the
<acronym>NIS</acronym> database. To do this, add <acronym>NIS</acronym> database, use <command>vipw</command> to add
<literal>-<replaceable>username</replaceable></literal> with <literal>-<replaceable>username</replaceable></literal> with
the correct number of colons like other entries to the end of the correct number of colons towards the end of
the <filename>/etc/master.passwd</filename> file on the client <filename>/etc/master.passwd</filename> on the client,
machine, where <replaceable>username</replaceable> is the where <replaceable>username</replaceable> is the
username of the user to bar from logging in. The line with username of a user to bar from logging in. The line with
the blocked user must be before the <literal>+</literal> line the blocked user must be before the <literal>+</literal> line
for allowing <acronym>NIS</acronym> users. This should that allows <acronym>NIS</acronym> users.
preferably be done using In this example, <username>bill</username> is barred from
<command>vipw</command>, since <command>vipw</command> will
sanity check the changes to
<filename>/etc/master.passwd</filename>, as well as
automatically rebuild the password database after editing.
For example, to bar user <username>bill</username> from
logging on to <hostid>basie</hostid>:</para> logging on to <hostid>basie</hostid>:</para>
<screen>basie&prompt.root; <userinput>vipw</userinput> <screen>basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
<userinput>[add -bill::::::::: to the end, exit]</userinput>
vipw: rebuilding the database...
vipw: done
basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>
root:[password]:0:0::0:0:The super-user:/root:/bin/csh root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
@ -1850,6 +1810,7 @@ nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+::::::::: +:::::::::
basie&prompt.root;</screen> basie&prompt.root;</screen>
</sect3>
</sect2> </sect2>
<sect2 id="network-netgroups"> <sect2 id="network-netgroups">