This patch provides general tightening and clarification of the sections NIS Slave Servers through NIS Security.
This commit is contained in:
Dru Lavigne
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
|
|
@ -1517,14 +1517,16 @@ ellington has been setup as an YP master server without any errors.</screen>
|
|||
<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 transferred
|
|||
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 ellington.</screen>
|
|||
<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>
|
||||
other problems may force the retirement of these client
|
||||
systems or the abandonment of
|
||||
<filename>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>
|
||||
|
||||
<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 user:/nonexistent:/sbin/nologin
|
|||
+:::::::::
|
||||
|
||||
basie&prompt.root;</screen>
|
||||
</sect3>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="network-netgroups">
|
||||
|
|
|
|||
Loading…
Reference in a new issue