Whitespace-only fixes. Translators, please ignore.

This commit is contained in:
Warren Block 2014-05-25 20:55:35 +00:00
parent 5f593963f9
commit 1b91d8fe65
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44952

View file

@ -4,7 +4,10 @@
$FreeBSD$ $FreeBSD$
--> -->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security"> <chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="security">
<info> <info>
<title>Security</title> <title>Security</title>
@ -1083,35 +1086,46 @@ sendmail : PARANOID : deny</programlisting>
<title><application>Kerberos</application></title> <title><application>Kerberos</application></title>
<authorgroup> <authorgroup>
<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed <author>
by </contrib></author> <personname>
<firstname>Tillman</firstname>
<surname>Hodgson</surname>
</personname>
<contrib>Contributed by </contrib>
</author>
</authorgroup> </authorgroup>
<authorgroup> <authorgroup>
<author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>Based <author>
on a contribution by </contrib></author> <personname>
<firstname>Mark</firstname>
<surname>Murray</surname>
</personname>
<contrib>Based on a contribution by </contrib>
</author>
</authorgroup> </authorgroup>
</info> </info>
<para><application>Kerberos</application> is a network <para><application>Kerberos</application> is a network
authentication protocol which was originally created by the authentication protocol which was originally created by the
Massachusetts Institute of Technology Massachusetts Institute of Technology (<acronym>MIT</acronym>)
(<acronym>MIT</acronym>) as a way to securely provide authentication as a way to securely provide authentication across a potentially
across a potentially hostile network. hostile network. The <application>Kerberos</application>
The <application>Kerberos</application> protocol uses protocol uses strong cryptography so that both a client and
strong cryptography so that both a client and server can prove server can prove their identity without sending any unencrypted
their identity without sending any unencrypted secrets over the network. secrets over the network. <application>Kerberos</application>
<application>Kerberos</application> can be described as an can be described as an identity-verifying proxy system and as a
identity-verifying proxy system and as a trusted third-party trusted third-party authentication system. After a user
authentication system. After a user authenticates with authenticates with <application>Kerberos</application>, their
<application>Kerberos</application>, their communications can be communications can be encrypted to assure privacy and data
encrypted to assure privacy and data integrity.</para> integrity.</para>
<para>The only function of <application>Kerberos</application> is <para>The only function of <application>Kerberos</application> is
to provide the secure authentication of users and servers on the network. to provide the secure authentication of users and servers on the
It does not provide authorization or auditing functions. It is network. It does not provide authorization or auditing
recommended that <application>Kerberos</application> be used functions. It is recommended that
with other security methods which provide authorization and <application>Kerberos</application> be used with other security
audit services.</para> methods which provide authorization and audit services.</para>
<para>The current version of the protocol is version 5, described <para>The current version of the protocol is version 5, described
in <acronym>RFC</acronym>&nbsp;4120. Several free in <acronym>RFC</acronym>&nbsp;4120. Several free
@ -1123,18 +1137,20 @@ sendmail : PARANOID : deny</programlisting>
<acronym>US</acronym> export regulations. In &os;, <acronym>US</acronym> export regulations. In &os;,
<acronym>MIT</acronym> <application>Kerberos</application> is <acronym>MIT</acronym> <application>Kerberos</application> is
available as the <package>security/krb5</package> package or available as the <package>security/krb5</package> package or
port. The Heimdal <application>Kerberos</application> implementation was port. The Heimdal <application>Kerberos</application>
explicitly developed outside of the <acronym>US</acronym> to implementation was explicitly developed outside of the
avoid export regulations. The Heimdal <acronym>US</acronym> to avoid export regulations. The Heimdal
<application>Kerberos</application> distribution is included in <application>Kerberos</application> distribution is included in
the base &os; installation, and another distribution with more the base &os; installation, and another distribution with more
configurable options is available as <package>security/heimdal</package> configurable options is available as
in the Ports Collection.</para> <package>security/heimdal</package> in the Ports
Collection.</para>
<para>In <application>Kerberos</application> users and services are <para>In <application>Kerberos</application> users and services
identified as <quote>principals</quote> which are contained within are identified as <quote>principals</quote> which are contained
an administrative grouping, called a <quote>realm</quote>. A within an administrative grouping, called a
typical user principal would be of the form <quote>realm</quote>. A typical user principal would be of the
form
<literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal> <literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal>
(realms are traditionally uppercase).</para> (realms are traditionally uppercase).</para>
@ -1177,14 +1193,15 @@ sendmail : PARANOID : deny</programlisting>
<para>The Key Distribution Center (<acronym>KDC</acronym>) is <para>The Key Distribution Center (<acronym>KDC</acronym>) is
the centralized authentication service that the centralized authentication service that
<application>Kerberos</application> provides, the <quote>trusted <application>Kerberos</application> provides, the
third party</quote> of the system. It is the <quote>trusted third party</quote> of the system. It is the
computer that issues <application>Kerberos</application> computer that issues <application>Kerberos</application>
tickets, which are used for clients to authenticate to servers. tickets, which are used for clients to authenticate to
Because the <acronym>KDC</acronym> is considered trusted by servers. Because the <acronym>KDC</acronym> is considered
all other computers in the trusted by all other computers in the
<application>Kerberos</application> realm, it has heightened security <application>Kerberos</application> realm, it has heightened
concerns. Direct access to the KDC should be limited.</para> security concerns. Direct access to the KDC should be
limited.</para>
<para>While running a <acronym>KDC</acronym> requires few <para>While running a <acronym>KDC</acronym> requires few
computing resources, a dedicated machine acting only as a computing resources, a dedicated machine acting only as a
@ -1219,9 +1236,9 @@ kadmind5_server_enable="YES"</programlisting>
<para><application>Kerberos</application> can also use the <para><application>Kerberos</application> can also use the
<acronym>DNS</acronym> to locate KDCs, instead of a <acronym>DNS</acronym> to locate KDCs, instead of a
<literal>[realms]</literal> section in <literal>[realms]</literal> section in
<filename>/etc/krb5.conf</filename>. For large organizations that <filename>/etc/krb5.conf</filename>. For large organizations
have their own <acronym>DNS</acronym> servers, the above example that have their own <acronym>DNS</acronym> servers, the above
could be trimmed to:</para> example could be trimmed to:</para>
<programlisting>[libdefaults] <programlisting>[libdefaults]
default_realm = <replaceable>EXAMPLE.ORG</replaceable> default_realm = <replaceable>EXAMPLE.ORG</replaceable>
@ -1252,22 +1269,22 @@ _kerberos IN TXT <replaceable>EXAMPLE.ORG</replaceable></programl
database which contains the keys of all principals (users and database which contains the keys of all principals (users and
hosts) encrypted with a master password. It is not required hosts) encrypted with a master password. It is not required
to remember this password as it will be stored in to remember this password as it will be stored in
<filename>/var/heimdal/m-key</filename>; it would be reasonable to <filename>/var/heimdal/m-key</filename>; it would be
use a 45-character random password for this purpose. To create the reasonable to use a 45-character random password for this
master key, run <command>kstash</command> and enter a purpose. To create the master key, run
password:</para> <command>kstash</command> and enter a password:</para>
<screen>&prompt.root; <userinput>kstash</userinput> <screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput> Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen> Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
<para>Once the master key has been created, the database should be <para>Once the master key has been created, the database should
initialized. The <application>Kerberos</application> administrative be initialized. The <application>Kerberos</application>
tool &man.kadmin.8; can be used on the KDC in a mode that administrative tool &man.kadmin.8; can be used on the KDC in a
operates directly on the database, without using the &man.kadmind.8; mode that operates directly on the database, without using the
network service, as <command>kadmin -l</command>. &man.kadmind.8; network service, as
This resolves the chicken-and-egg problem of trying to connect to <command>kadmin -l</command>. This resolves the
the database chicken-and-egg problem of trying to connect to the database
before it is created. At the <command>kadmin</command> before it is created. At the <command>kadmin</command>
prompt, use <command>init</command> to create the realm's prompt, use <command>init</command> to create the realm's
initial database:</para> initial database:</para>
@ -1299,10 +1316,11 @@ Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></u
principal that was just created:</para> principal that was just created:</para>
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput> <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman@EXAMPLE.ORG's Password: tillman@EXAMPLE.ORG's Password:</screen>
</screen>
<para>Confirm that a ticket was successfully obtained using <para>Confirm that a ticket was successfully obtained using
<command>klist</command>:</para> <command>klist</command>:</para>
<screen>&prompt.user; <userinput>klist</userinput> <screen>&prompt.user; <userinput>klist</userinput>
Credentials cache: FILE:/tmp/krb5cc_1001 Credentials cache: FILE:/tmp/krb5cc_1001
Principal: tillman@EXAMPLE.ORG Principal: tillman@EXAMPLE.ORG
@ -1333,49 +1351,52 @@ Aug 27 15:37:58 2013 Aug 28 01:37:58 2013 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</scre
regenerated on the new system.</para> regenerated on the new system.</para>
<para>Next, create <filename>/etc/krb5.keytab</filename> on the <para>Next, create <filename>/etc/krb5.keytab</filename> on the
server. This is the main part of <quote>Kerberizing</quote> a service server. This is the main part of <quote>Kerberizing</quote> a
&mdash; it corresponds to generating a secret shared between the service &mdash; it corresponds to generating a secret shared
service and the <acronym>KDC</acronym>. The secret is a cryptographic between the service and the <acronym>KDC</acronym>. The
key, stored in a <quote>keytab</quote>. The keytab contains secret is a cryptographic key, stored in a
the server's host key, which allows it and the <acronym>KDC</acronym> <quote>keytab</quote>. The keytab contains the server's host
to verify each others' identity. It must be transmitted to the key, which allows it and the <acronym>KDC</acronym> to verify
server in a secure fashion, as the security of the server can each others' identity. It must be transmitted to the server
be broken if the key is made public. Typically, the in a secure fashion, as the security of the server can be
broken if the key is made public. Typically, the
<filename>keytab</filename> is generated on an administrator's <filename>keytab</filename> is generated on an administrator's
trusted machine using <command>kadmin</command>, then securely trusted machine using <command>kadmin</command>, then securely
transferred to the server, e.g., with &man.scp.1;; it can also transferred to the server, e.g., with &man.scp.1;; it can also
be created directly on the server if that is consistent with be created directly on the server if that is consistent with
the desired security policy. It is very important that the the desired security policy. It is very important that the
keytab is transmitted to the server in a secure fashion: if keytab is transmitted to the server in a secure fashion: if
the key is known by some other party, that party can impersonate the key is known by some other party, that party can
any user to the server! Using <command>kadmin</command> on the impersonate any user to the server! Using
server directly is convenient, because the entry for the host <command>kadmin</command> on the server directly is
principal in the <acronym>KDC</acronym> database is also created using convenient, because the entry for the host principal in the
<acronym>KDC</acronym> database is also created using
<command>kadmin</command>.</para> <command>kadmin</command>.</para>
<para>Of course, <command>kadmin</command> is a kerberized service; <para>Of course, <command>kadmin</command> is a kerberized
a <application>Kerberos</application> ticket is needed to authenticate service; a <application>Kerberos</application> ticket is
to the network service, but to ensure that the user running needed to authenticate to the network service, but to ensure
<command>kadmin</command> is actually present (and their session has that the user running <command>kadmin</command> is actually
not been hijacked), <command>kadmin</command> will prompt for the present (and their session has not been hijacked),
password to get a fresh ticket. The principal authenticating <command>kadmin</command> will prompt for the password to get
to the kadmin service must be permitted to use the a fresh ticket. The principal authenticating to the kadmin
<command>kadmin</command> interface, as specified in service must be permitted to use the <command>kadmin</command>
<filename>kadmind.acl</filename>. See the section titled interface, as specified in <filename>kadmind.acl</filename>.
<quote>Remote administration</quote> in <command>info See the section titled <quote>Remote administration</quote> in
heimdal</command> for details on designing access control <command>info heimdal</command> for details on designing
lists. Instead of enabling remote <command>kadmin</command> access control lists. Instead of enabling remote
access, the administrator could securely connect to the <command>kadmin</command> access, the administrator could
<acronym>KDC</acronym> via the local console or &man.ssh.1;, securely connect to the <acronym>KDC</acronym> via the local
and perform administration locally using console or &man.ssh.1;, and perform administration locally
<command>kadmin -l</command>.</para> using <command>kadmin -l</command>.</para>
<para>After installing <filename>/etc/krb5.conf</filename>, <para>After installing <filename>/etc/krb5.conf</filename>,
use <command>add --random-key</command> in <command>kadmin</command>. use <command>add --random-key</command> in
This adds the server's host principal to the database, but does not <command>kadmin</command>. This adds the server's host
extract a copy of the host principal key to a keytab. To generate principal to the database, but does not extract a copy of the
the keytab, use <command>ext</command> to extract the server's host host principal key to a keytab. To generate the keytab, use
principal key to its own keytab:</para> <command>ext</command> to extract the server's host principal
key to its own keytab:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput> kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
@ -1387,11 +1408,12 @@ Attributes []:
kadmin&gt;<userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput> kadmin&gt;<userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput>
kadmin&gt;<userinput> exit</userinput></screen> kadmin&gt;<userinput> exit</userinput></screen>
<para>Note that <command>ext_keytab</command> stores the extracted key <para>Note that <command>ext_keytab</command> stores the
in <filename>/etc/krb5.keytab</filename> by default. This is extracted key in <filename>/etc/krb5.keytab</filename> by
good when being run on the server being kerberized, but the default. This is good when being run on the server being
<command>--keytab <replaceable>path/to/file</replaceable></command> kerberized, but the <command>--keytab
argument should be used when the keytab is being extracted <replaceable>path/to/file</replaceable></command> argument
should be used when the keytab is being extracted
elsewhere:</para> elsewhere:</para>
<screen>&prompt.root; <userinput>kadmin</userinput> <screen>&prompt.root; <userinput>kadmin</userinput>
@ -1400,23 +1422,25 @@ kadmin&gt;<userinput> exit</userinput></screen>
<para>The keytab can then be securely copied to the server <para>The keytab can then be securely copied to the server
using &man.scp.1; or a removable media. Be sure to specify a using &man.scp.1; or a removable media. Be sure to specify a
non-default keytab name to avoid inserting unneeded keys into the non-default keytab name to avoid inserting unneeded keys into
system's keytab.</para> the system's keytab.</para>
<para>At this point, the server can read encrypted messages from the <para>At this point, the server can read encrypted messages from
<acronym>KDC</acronym> using its shared key, stored in the <acronym>KDC</acronym> using its shared key, stored in
<filename>krb5.keytab</filename>. It is now <filename>krb5.keytab</filename>. It is now ready for the
ready for the <application>Kerberos</application>-using services to <application>Kerberos</application>-using services to be
be enabled. One of the most common such services is &man.sshd.8;, enabled. One of the most common such services is
which supports <application>Kerberos</application> via the &man.sshd.8;, which supports
<application>Kerberos</application> via the
<acronym>GSS-API</acronym>. In <acronym>GSS-API</acronym>. In
<filename>/etc/ssh/sshd_config</filename>, add the line:</para> <filename>/etc/ssh/sshd_config</filename>, add the
line:</para>
<programlisting>GSSAPIAuthentication yes</programlisting> <programlisting>GSSAPIAuthentication yes</programlisting>
<para>After making this change, &man.sshd.8; must be restared for <para>After making this change, &man.sshd.8; must be restared
the new configuration to take effect: <command>service sshd for the new configuration to take effect:
restart</command>.</para> <command>service sshd restart</command>.</para>
</sect2> </sect2>
<sect2> <sect2>
@ -1428,21 +1452,22 @@ kadmin&gt;<userinput> exit</userinput></screen>
<secondary>configure clients</secondary> <secondary>configure clients</secondary>
</indexterm> </indexterm>
<para>As it was for the server, the client requires configuration in <para>As it was for the server, the client requires
<filename>/etc/krb5.conf</filename>. Copy the file in place configuration in <filename>/etc/krb5.conf</filename>. Copy
(securely) or re-enter it as needed.</para> the file in place (securely) or re-enter it as needed.</para>
<para>Test the client by using <command>kinit</command>, <para>Test the client by using <command>kinit</command>,
<command>klist</command>, and <command>kdestroy</command> from <command>klist</command>, and <command>kdestroy</command> from
the client to obtain, show, and then delete a ticket the client to obtain, show, and then delete a ticket for an
for an existing principal. <application>Kerberos</application> existing principal. <application>Kerberos</application>
applications should also be able to connect to applications should also be able to connect to
<application>Kerberos</application> enabled servers. If that <application>Kerberos</application> enabled servers. If that
does not work but obtaining a ticket does, the problem is does not work but obtaining a ticket does, the problem is
likely with the server and not with the client or the likely with the server and not with the client or the
<acronym>KDC</acronym>. In the case of kerberized &man.ssh.1;, <acronym>KDC</acronym>. In the case of kerberized
<acronym>GSS-API</acronym> is disabled by default, so test using &man.ssh.1;, <acronym>GSS-API</acronym> is disabled by
<command>ssh -o GSSAPIAuthentication=yes default, so test using <command>ssh -o
GSSAPIAuthentication=yes
<replaceable>hostname</replaceable></command>.</para> <replaceable>hostname</replaceable></command>.</para>
<para>When testing a Kerberized application, try using a packet <para>When testing a Kerberized application, try using a packet
@ -1450,12 +1475,12 @@ kadmin&gt;<userinput> exit</userinput></screen>
sensitive information is sent in the clear.</para> sensitive information is sent in the clear.</para>
<para>Various <application>Kerberos</application> client <para>Various <application>Kerberos</application> client
applications are available. With the advent of a bridge so that applications are available. With the advent of a bridge so
applications using <acronym>SASL</acronym> for authentication can that applications using <acronym>SASL</acronym> for
use <acronym>GSS-API</acronym> mechanisms as well, large classes authentication can use <acronym>GSS-API</acronym> mechanisms
of client applications can use <application>Kerberos</application> as well, large classes of client applications can use
for authentication, from Jabber clients to <acronym>IMAP</acronym> <application>Kerberos</application> for authentication, from
clients.</para> Jabber clients to <acronym>IMAP</acronym> clients.</para>
<indexterm> <indexterm>
<primary><filename>.k5login</filename></primary> <primary><filename>.k5login</filename></primary>
@ -1514,8 +1539,8 @@ jdoe@example.org</screen>
<acronym>MIT</acronym> versions if <envar>PATH</envar> lists <acronym>MIT</acronym> versions if <envar>PATH</envar> lists
the system directories first.</para> the system directories first.</para>
<para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;, <para>When using MIT Kerberos as a <acronym>KDC</acronym> on
the following edits should also be made to &os;, the following edits should also be made to
<filename>rc.conf</filename>:</para> <filename>rc.conf</filename>:</para>
<programlisting>kerberos5_server="/usr/local/sbin/krb5kdc" <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
@ -1536,9 +1561,9 @@ kadmind5_server_enable="YES"</programlisting>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para>When using either Heimdal or <acronym>MIT</acronym> <para>When using either Heimdal or <acronym>MIT</acronym>
<application>Kerberos</application> from ports, ensure that the <application>Kerberos</application> from ports, ensure
<envar>PATH</envar> lists the port's versions of the that the <envar>PATH</envar> lists the port's versions of
client applications before the system versions.</para> the client applications before the system versions.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -1580,15 +1605,16 @@ kadmind5_server_enable="YES"</programlisting>
<listitem> <listitem>
<para>With <acronym>MIT</acronym> <para>With <acronym>MIT</acronym>
<application>Kerberos</application>, to allow a <application>Kerberos</application>, to allow a principal
principal to have a ticket life longer than the default to have a ticket life longer than the default lifetime of
lifetime of ten hours, use <command>modify_principal</command> ten hours, use <command>modify_principal</command> at the
at the &man.kadmin.8; prompt to change the &man.kadmin.8; prompt to change the
<literal>maxlife</literal> of both the principal in <literal>maxlife</literal> of both the principal in
question and the <systemitem question and the
class="username">krbtgt</systemitem> principal. The <systemitem class="username">krbtgt</systemitem>
principal can then use <command>kinit -l</command> to principal. The principal can then use
request a ticket with a longer lifetime.</para> <command>kinit -l</command> to request a ticket with a
longer lifetime.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -1998,15 +2024,33 @@ Connection closed by foreign host.</screen>
<acronym>IPsec</acronym></title> <acronym>IPsec</acronym></title>
<authorgroup> <authorgroup>
<author><personname><firstname>Nik</firstname><surname>Clayton</surname></personname><affiliation> <author>
<address><email>nik@FreeBSD.org</email></address> <personname>
</affiliation><contrib>Written by </contrib></author> <firstname>Nik</firstname>
<surname>Clayton</surname>
</personname>
<affiliation>
<address>
<email>nik@FreeBSD.org</email>
</address>
</affiliation>
<contrib>Written by </contrib>
</author>
</authorgroup> </authorgroup>
<authorgroup> <authorgroup>
<author><personname><firstname>Hiten <author>
M.</firstname><surname>Pandya</surname></personname><affiliation> <personname>
<address><email>hmp@FreeBSD.org</email></address> <firstname>Hiten M.</firstname>
</affiliation><contrib>Written by </contrib></author> <surname>Pandya</surname>
</personname>
<affiliation>
<address>
<email>hmp@FreeBSD.org</email>
</address>
</affiliation>
<contrib>Written by </contrib>
</author>
</authorgroup> </authorgroup>
</info> </info>
@ -2155,9 +2199,18 @@ device crypto</screen>
<title>Configuring a <acronym>VPN</acronym> on &os;</title> <title>Configuring a <acronym>VPN</acronym> on &os;</title>
<authorgroup> <authorgroup>
<author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><affiliation> <author>
<address><email>trhodes@FreeBSD.org</email></address> <personname>
</affiliation><contrib>Written by </contrib></author> <firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
<affiliation>
<address>
<email>trhodes@FreeBSD.org</email>
</address>
</affiliation>
<contrib>Written by </contrib>
</author>
</authorgroup> </authorgroup>
</info> </info>