Date: Tue, 15 Oct 2013 22:03:05 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42970 - head/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201310152203.r9FM359V046645@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Tue Oct 15 22:03:04 2013 New Revision: 42970 URL: http://svnweb.freebsd.org/changeset/doc/42970 Log: This patch provides general tightening and clarification of the sections NIS Slave Servers through NIS Security. Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 21:03:04 2013 (r42969) +++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 22:03:04 2013 (r42970) @@ -1517,14 +1517,16 @@ ellington has been setup as an YP master <primary>NIS</primary> <secondary>slave server</secondary> </indexterm> - <para>Setting up an <acronym>NIS</acronym> slave server is - simpler than setting up the master. Log on to + <para>To set up an <acronym>NIS</acronym> slave server, log on to the slave server and edit - <filename>/etc/rc.conf</filename> as before. This - time, include - <option>-s</option> when running - <command>ypinit</command>. This option - requires the name of the <acronym>NIS</acronym> master, as + <filename>/etc/rc.conf</filename> as for the master server. + Do not generate any <acronym>NIS</acronym> maps, as these + already exist on the master server. When running + <command>ypinit</command> on the slave server, use + <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> <screen>coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput> @@ -1584,56 +1586,51 @@ ypxfr: Exiting: Map successfully transfe coltrane has been setup as an YP slave server without any errors. Remember to update map ypservers on ellington.</screen> - <para>There should be a directory called - <filename>/var/yp/test-domain</filename>. Copies of the - <acronym>NIS</acronym> master server's maps should be in - this directory. These files must always be up to date. - The following <filename>/etc/crontab</filename> entries on - the slave servers should do the job:</para> + <para>This will generate a directory on the slave server called + <filename class="directory">/var/yp/test-domain</filename> which contains copies of the + <acronym>NIS</acronym> master server's maps. + Adding these <filename>/etc/crontab</filename> entries on each + slave server will force the slaves to sync their maps with + the maps on the master server:</para> <programlisting>20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting> - <para>These two lines force the slave to sync its maps with - the maps on the master server. These entries are not + <para>These entries are not mandatory because the master server automatically attempts - to push any map changes to its slaves; however, due to - the importance of correct password information on other - clients depending on the slave server, it is recommended - to specifically force the password map updates frequently. + to push any map changes to its slaves. However, since clients may + depend upon the slave server to provide correct password information, + it is recommended + to force frequent password map updates. This is especially important on busy networks where map updates might not always complete.</para> - <para>Now, run the command <command>/etc/netstart</command> - on the slave server as well, which again starts the NIS - server.</para> + <para>To finish the configuration, run <command>/etc/netstart</command> + on the slave server in order to start the <acronym>NIS</acronym> + services.</para> </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 - called a binding to a particular <acronym>NIS</acronym> - server using the <command>ypbind</command> daemon. The - <command>ypbind</command> command checks the system's - default domain (as set by the - <command>domainname</command> command), and begins - broadcasting RPC requests on the local network. These - requests specify the name of the domain for which - <command>ypbind</command> is attempting to establish a - binding. If a server that has been configured to serve the - requested domain receives one of the broadcasts, it will - respond to <command>ypbind</command>, which will record the - 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 + <para>An <acronym>NIS</acronym> client binds + to an <acronym>NIS</acronym> + server using &man.ypbind.8;. This + daemon + broadcasts RPC requests on the local network. These + requests specify the domain name configured on the client. + If an <acronym>NIS</acronym> server in the same domain + receives one of the broadcasts, it will + respond to <application>ypbind</application>, which will record the + server's address. If there are several servers available, + the client will use the address of the first + server to respond and will direct all of its <acronym>NIS</acronym> requests to that - server. <command>ypbind</command> will occasionally - <quote>ping</quote> the server to make sure it is still up - and running. If it fails to receive a reply to one of its - pings within a reasonable amount of time, - <command>ypbind</command> will mark the domain as unbound + server. The client will automatically + <application>ping</application> the server on a regular basis to make sure it is still + available. If it fails to receive a reply + within a reasonable amount of time, + <application>ypbind</application> will mark the domain as unbound and begin broadcasting again in the hopes of locating another server.</para> @@ -1641,16 +1638,15 @@ Remember to update map ypservers on elli <secondary>client configuration</secondary> </indexterm> - <para>Setting up a &os; machine to be a - <acronym>NIS</acronym> client is fairly - straightforward.</para> + <para>To configure a &os; machine to be an + <acronym>NIS</acronym> client:</para> <procedure> <step> <para>Edit <filename>/etc/rc.conf</filename> and add the following lines in order to set the <acronym>NIS</acronym> domain name and start - <command>ypbind</command> during network + &man.ypbind.8; during network startup:</para> <programlisting>nisdomainname="test-domain" @@ -1659,40 +1655,34 @@ nis_client_enable="YES"</programlisting> <step> <para>To import all possible password entries from the - <acronym>NIS</acronym> server, remove all user - accounts from the - <filename>/etc/master.passwd</filename> file and use - <command>vipw</command> to add the following line to + <acronym>NIS</acronym> server, use + <command>vipw</command> to remove all user + accounts except one from + <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> <programlisting>+:::::::::</programlisting> - <note> - <para>This line will afford anyone with a valid + <para>This line configures the client to provide anyone with a valid account in the <acronym>NIS</acronym> server's - password maps an account. There are many ways to - configure the NIS - client by changing this line. See the - <link linkend="network-netgroups">netgroups - section</link> below for more information. For - more detailed reading see O'Reilly's book on - <literal>Managing NFS and NIS</literal>.</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> + password maps an account on the client. There are many ways to + configure the <acronym>NIS</acronym> + client by modifying this line. One method is described in + <xref linkend="network-netgroups"/>. For + more detailed reading, refer to the book + <literal>Managing NFS and NIS</literal>, published by + O'Reilly Media.</para> </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 <filename>/etc/group</filename>:</para> @@ -1707,32 +1697,27 @@ nis_client_enable="YES"</programlisting> <screen>&prompt.root; <userinput>/etc/netstart</userinput> &prompt.root; <userinput>service ypbind start</userinput></screen> - <para>After completing these steps, the command, - <command>ypcat passwd</command>, should show the - server's passwd map.</para> + <para>After completing these steps, running + <command>ypcat passwd</command> on the client should show the + server's <filename>passwd</filename> map.</para> </sect2> <sect2> <title><acronym>NIS</acronym> Security</title> - <para>In general, any remote user may issue an RPC to - &man.ypserv.8; and retrieve the contents of the - <acronym>NIS</acronym> maps, provided the remote user knows - the domain name. To prevent such unauthorized transactions, + <para>Since <acronym>RPC</acronym> is a broadcast-based service, + any system running <application>ypbind</application> within the same domain + can retrieve the contents of the + <acronym>NIS</acronym> maps. To prevent unauthorized transactions, &man.ypserv.8; supports a feature called <quote>securenets</quote> which can be used to restrict access - to a given set of hosts. At startup, &man.ypserv.8; will - attempt to load the securenets information from a file called - <filename>/var/yp/securenets</filename>.</para> - - <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 - separated by white space. Lines starting with - <quote>#</quote> are considered to be comments. A sample - securenets file might look like this:</para> - </note> + to a given set of hosts. By default, this information is stored in + <filename>/var/yp/securenets</filename>, unless &man.ypserv.8; is started with + <option>-p</option> and an alternate path. This file contains entries + that consist of a network specification and a network mask + separated by white space. Lines starting with + <literal>#</literal> are considered to be comments. A sample + <filename>securenets</filename> might look like this:</para> <programlisting># allow connections from local host -- mandatory 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 normally. If the address fails to match a rule, the request 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 host.</para> - <para>The <command>ypserv</command> program also has support for - Wietse Venema's <application>TCP Wrapper</application> - package. This allows the administrator to use the - <application>TCP Wrapper</application> configuration files for + <para><xref linkend="tcpwrappers"/> is + an alternate mechanism for providing access control instead of - <filename>/var/yp/securenets</filename>.</para> - - <note> - <para>While both of these access control mechanisms provide - some security, they, like the privileged port test, are + <filename>securenets</filename>. While either access control mechanism adds + some security, they are both 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> - <para>Servers using <filename>/var/yp/securenets</filename> + <para>Servers using <filename>securenets</filename> may fail to serve legitimate <acronym>NIS</acronym> clients with archaic TCP/IP implementations. Some of these 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 problems can be fixed by changing the client configuration, - other problems may force the retirement of the client - systems in question or the abandonment of - <filename>/var/yp/securenets</filename>.</para> - - <para>Using <filename>/var/yp/securenets</filename> on a - 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> + other problems may force the retirement of these client + systems or the abandonment of + <filename>securenets</filename>.</para> - <indexterm><primary>TCP Wrappers</primary></indexterm> + <indexterm><primary>TCP Wrapper</primary></indexterm> <para>The use of <application>TCP Wrapper</application> increases the latency of the <acronym>NIS</acronym> server. The additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of the client systems suffers - from these symptoms, convert the client systems in question + client programs, especially in busy networks with slow + <acronym>NIS</acronym> servers. If one or more clients suffer + from latency, convert those clients into <acronym>NIS</acronym> slave servers and force them to bind to themselves.</para> - </note> - </sect2> - <sect2> - <title>Barring Some Users from Logging On</title> + <sect3> + <title>Barring Some Users</title> - <para>In our lab, there is a machine <hostid>basie</hostid> that - is supposed to be a faculty only workstation. We do not want - to take this machine out of the <acronym>NIS</acronym> domain, - yet the <filename>passwd</filename> file on the master + <para>In this example, the <hostid>basie</hostid> system + is a faculty workstation within the <acronym>NIS</acronym> domain. + The <filename>passwd</filename> map on the master <acronym>NIS</acronym> server contains accounts for both - faculty and students. What can we - do?</para> + faculty and students. This section demonstrates how to allow + faculty logins on this system while refusing student logins.</para> - <para>There is a way to bar specific users from logging on to a - machine, even if they are present in the - <acronym>NIS</acronym> database. To do this, add + <para>To prevent specified users from logging on to a + system, even if they are present in the + <acronym>NIS</acronym> database, use <command>vipw</command> to add <literal>-<replaceable>username</replaceable></literal> with - the correct number of colons like other entries to the end of - the <filename>/etc/master.passwd</filename> file on the client - machine, where <replaceable>username</replaceable> is the - username of the user to bar from logging in. The line with + the correct number of colons towards the end of + <filename>/etc/master.passwd</filename> on the client, + where <replaceable>username</replaceable> is the + username of a user to bar from logging in. The line with the blocked user must be before the <literal>+</literal> line - for allowing <acronym>NIS</acronym> users. This should - preferably be done using - <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 + that allows <acronym>NIS</acronym> users. + In this example, <username>bill</username> is barred from logging on to <hostid>basie</hostid>:</para> - <screen>basie&prompt.root; <userinput>vipw</userinput> -<userinput>[add -bill::::::::: to the end, exit]</userinput> -vipw: rebuilding the database... -vipw: done - -basie&prompt.root; <userinput>cat /etc/master.passwd</userinput> - + <screen>basie&prompt.root; <userinput>cat /etc/master.passwd</userinput> 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 daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin @@ -1850,6 +1810,7 @@ nobody:*:65534:65534::0:0:Unprivileged u +::::::::: basie&prompt.root;</screen> + </sect3> </sect2> <sect2 id="network-netgroups">
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310152203.r9FM359V046645>