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

Whitespace-only fixes. Translators, please ignore.

Browse source
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
1 changed files with 204 additions and 151 deletions

355
en_US.ISO8859-1/books/handbook/security/chapter.xml
View file

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