svn commit: r44445 - head/en_US.ISO8859-1/books/handbook/security
Dru Lavigne
dru at FreeBSD.org
Fri Apr 4 15:48:10 UTC 2014
Author: dru
Date: Fri Apr 4 15:48:09 2014
New Revision: 44445
URL: http://svnweb.freebsd.org/changeset/doc/44445
Log:
White space fix only. Translators can ignore.
Sponsored by: iXsystems
Modified:
head/en_US.ISO8859-1/books/handbook/security/chapter.xml
Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:21:36 2014 (r44444)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:48:09 2014 (r44445)
@@ -24,15 +24,14 @@
<sect1 xml:id="security-synopsis">
<title>Synopsis</title>
- <para>Security, whether physical or virtual, is a topic
- so broad that an entire industry has grown up around it.
- Hundreds of standard practices have been authored about
- how to secure systems and networks, and as a user of &os;,
- understanding how to protect against attacks and intruders
- is a must.</para>
+ <para>Security, whether physical or virtual, is a topic so broad
+ that an entire industry has grown up around it. Hundreds of
+ standard practices have been authored about how to secure
+ systems and networks, and as a user of &os;, understanding how
+ to protect against attacks and intruders is a must.</para>
- <para>In this chapter, several fundamentals and techniques will
- be discussed. The &os; system comes with multiple layers of
+ <para>In this chapter, several fundamentals and techniques will be
+ discussed. The &os; system comes with multiple layers of
security, and many more third party utilities may be added to
enhance security.</para>
@@ -76,9 +75,9 @@
</listitem>
<listitem>
- <para>How to use <application>portaudit</application> to
- audit third party software packages installed from the
- Ports Collection.</para>
+ <para>How to use <application>portaudit</application> to audit
+ third party software packages installed from the Ports
+ Collection.</para>
</listitem>
<listitem>
@@ -91,8 +90,8 @@
</listitem>
<listitem>
- <para>Understand the resource limits database and
- how to utilize it to control user resources.</para>
+ <para>Understand the resource limits database and how to
+ utilize it to control user resources.</para>
</listitem>
</itemizedlist>
@@ -121,11 +120,11 @@
integrity, and availability of information systems.</para>
<para>The <acronym>CIA</acronym> triad is a bedrock concept of
- computer security, customers and end users expect privacy
- of their data. They expect orders they place to not be changed
- or their information altered behind the scenes. They also
- expect access to information at all times. Together they make
- up the confidentiality, integrity, and availability of the
+ computer security, customers and end users expect privacy of
+ their data. They expect orders they place to not be changed or
+ their information altered behind the scenes. They also expect
+ access to information at all times. Together they make up the
+ confidentiality, integrity, and availability of the
system.</para>
<para>To protect <acronym>CIA</acronym>, security professionals
@@ -1070,51 +1069,48 @@ sendmail : PARANOID : deny</programlisti
strong cryptography so that both a client and server can prove
their identity over an insecure 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>
+ 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 on the network.
- It does not provide authorization
- or auditing functions. It
- is recommended that <application>Kerberos</application> be used
+ 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> 1510. Several free
- implementations of this protocol are
- available, covering a wide range of operating systems.
- <acronym>MIT</acronym>
- continues to develop their <application>Kerberos</application>
- package. It is commonly used in the <acronym>US</acronym> as
- a cryptography product, and has historically been affected by
- <acronym>US</acronym> export regulations. In &os;,
- <acronym>MIT</acronym> <application>Kerberos</application> is
- available as the <package>security/krb5</package> package or
- port. Heimdal <application>Kerberos</application>
- was explicitly developed outside
- of the <acronym>US</acronym> to avoid export regulations. The
- Heimdal <application>Kerberos</application> distribution is
- available as the <package>security/heimdal</package> package
- or port, and a minimal installation is included in the base
- &os; install.</para>
+ implementations of this protocol are available, covering a wide
+ range of operating systems. <acronym>MIT</acronym> continues to
+ develop their <application>Kerberos</application> package. It
+ is commonly used in the <acronym>US</acronym> as a cryptography
+ product, and has historically been affected by
+ <acronym>US</acronym> export regulations. In &os;,
+ <acronym>MIT</acronym> <application>Kerberos</application> is
+ available as the <package>security/krb5</package> package or
+ port. Heimdal <application>Kerberos</application> was
+ explicitly developed outside of the <acronym>US</acronym> to
+ avoid export regulations. The Heimdal
+ <application>Kerberos</application> distribution is available as
+ the <package>security/heimdal</package> package or port, and a
+ minimal installation is included in the base &os;
+ install.</para>
<para>This section provides a guide on how to set up
<application>Kerberos</application> using the Heimdal
- distribution included in &os;.</para>
+ distribution included in &os;.</para>
<para>For purposes of demonstrating a
- <application>Kerberos</application> installation, the
- name spaces will be as follows:</para>
+ <application>Kerberos</application> installation, the name
+ spaces will be as follows:</para>
<itemizedlist>
<listitem>
- <para>The <acronym>DNS</acronym> domain (zone)
- will be <systemitem
+ <para>The <acronym>DNS</acronym> domain (zone) will be
+ <systemitem
class="fqdomainname">example.org</systemitem>.</para>
</listitem>
@@ -1127,8 +1123,8 @@ sendmail : PARANOID : deny</programlisti
<note>
<para>Use real domain names when setting up
<application>Kerberos</application>, even if it will run
- internally. This avoids <acronym>DNS</acronym> problems
- and assures inter-operation with other
+ internally. This avoids <acronym>DNS</acronym> problems and
+ assures inter-operation with other
<application>Kerberos</application> realms.</para>
</note>
@@ -1144,18 +1140,18 @@ sendmail : PARANOID : deny</programlisti
the centralized authentication service that
<application>Kerberos</application> provides. It is the
computer that issues <application>Kerberos</application>
- tickets. The <acronym>KDC</acronym> is considered
- trusted by all other computers in the
+ tickets. The <acronym>KDC</acronym> is considered trusted by
+ all other computers in the
<application>Kerberos</application> realm, and thus has
heightened security concerns.</para>
- <para>While running a <acronym>KDC</acronym>
- requires few computing resources, a dedicated
- machine acting only as a <acronym>KDC</acronym> is recommended
- for security reasons.</para>
+ <para>While running a <acronym>KDC</acronym> requires few
+ computing resources, a dedicated machine acting only as a
+ <acronym>KDC</acronym> is recommended for security
+ reasons.</para>
- <para>To begin setting up a <acronym>KDC</acronym>, add these lines to
- <filename>/etc/rc.conf</filename>:</para>
+ <para>To begin setting up a <acronym>KDC</acronym>, add these
+ lines to <filename>/etc/rc.conf</filename>:</para>
<programlisting>kerberos5_server_enable="YES"
kadmind5_server_enable="YES"</programlisting>
@@ -1173,27 +1169,26 @@ kadmind5_server_enable="YES"</programlis
[domain_realm]
<replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
- <para>In this example, the
- <acronym>KDC</acronym> will use the fully-qualified hostname
- <systemitem
+ <para>In this example, the <acronym>KDC</acronym> will use the
+ fully-qualified hostname <systemitem
class="fqdomainname">kerberos.example.org</systemitem>. Add
- a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym> zone file
- if the <acronym>KDC</acronym> has a different hostname than
- that specified in <filename>/etc/krb5.conf</filename>.</para>
-
- <para>For large networks with a properly configured
- <acronym>DNS</acronym> server, the above example could be
- trimmed to:</para>
+ a <acronym>CNAME</acronym> entry to the <acronym>DNS</acronym>
+ zone file if the <acronym>KDC</acronym> has a different
+ hostname than that specified in
+ <filename>/etc/krb5.conf</filename>.</para>
+
+ <para>For large networks with a properly configured
+ <acronym>DNS</acronym> server, the above example could be
+ trimmed to:</para>
- <programlisting>[libdefaults]
+ <programlisting>[libdefaults]
default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
- <para>With the following lines being appended to the
- <systemitem
- class="fqdomainname">example.org</systemitem> zone
- file:</para>
+ <para>With the following lines being appended to the
+ <systemitem class="fqdomainname">example.org</systemitem> zone
+ file:</para>
- <programlisting>_kerberos._udp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
+ <programlisting>_kerberos._udp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
_kerberos._tcp IN SRV 01 00 88 <replaceable>kerberos.example.org</replaceable>.
_kpasswd._udp IN SRV 01 00 464 <replaceable>kerberos.example.org</replaceable>.
_kerberos-adm._tcp IN SRV 01 00 749 <replaceable>kerberos.example.org</replaceable>.
@@ -1201,20 +1196,21 @@ _kerberos IN TXT <replace
<note>
<para>In order for clients to be able to find the
- <application>Kerberos</application> services, the <acronym>KDC</acronym>
- <emphasis>must</emphasis> have either a fully configured
- <filename>/etc/krb5.conf</filename> or a minimally
- configured <filename>/etc/krb5.conf</filename>
- <emphasis>and</emphasis> a properly configured <acronym>DNS</acronym>
- server.</para>
+ <application>Kerberos</application> services, the
+ <acronym>KDC</acronym> <emphasis>must</emphasis> have either
+ a fully configured <filename>/etc/krb5.conf</filename> or a
+ minimally configured <filename>/etc/krb5.conf</filename>
+ <emphasis>and</emphasis> a properly configured
+ <acronym>DNS</acronym> server.</para>
</note>
<para>Next, create the <application>Kerberos</application>
- 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>. To create the
- master key, run <command>kstash</command> and enter a password:</para>
+ 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>. To create the master
+ key, run <command>kstash</command> and enter a
+ password:</para>
<screen>&prompt.root; <userinput>kstash</userinput>
Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
@@ -1222,23 +1218,24 @@ Verifying password - Master key: <userin
<para>Once the master key has been created, initialize the
database using <command>kadmin -l</command>. This option
- instructs <command>kadmin</command> to modify the local database files
- directly rather than going through the &man.kadmind.8; network
- service. This handles 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>
+ instructs <command>kadmin</command> to modify the local
+ database files directly rather than going through the
+ &man.kadmind.8; network service. This handles 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>
<screen>&prompt.root; <userinput>kadmin -l</userinput>
kadmin> <userinput>init <replaceable>EXAMPLE.ORG</replaceable></userinput>
Realm max ticket life [unlimited]:</screen>
- <para>Lastly, while still in <command>kadmin</command>, create the first
- principal using <command>add</command>. Stick to the default
- options for the principal for now, as these can be changed
- later with <command>modify</command>. Type
- <literal>?</literal> at the prompt to see the
- available options.</para>
+ <para>Lastly, while still in <command>kadmin</command>, create
+ the first principal using <command>add</command>. Stick to
+ the default options for the principal for now, as these can be
+ changed later with <command>modify</command>. Type
+ <literal>?</literal> at the prompt to see the available
+ options.</para>
<screen>kadmin> <userinput>add <replaceable>tillman</replaceable></userinput>
Max ticket life [unlimited]:
@@ -1249,12 +1246,12 @@ Verifying password - Password: <userinpu
<para>Next, start the <acronym>KDC</acronym> services by running
<command>service kerberos start</command> and
- <command>service kadmind start</command>.
- While there will not be any kerberized daemons
- running at this point, it is possible to confirm that the
- <acronym>KDC</acronym> is functioning by obtaining and
- listing a ticket for the principal that was just
- created from the command-line of the <acronym>KDC</acronym>:</para>
+ <command>service kadmind start</command>. While there will
+ not be any kerberized daemons running at this point, it is
+ possible to confirm that the <acronym>KDC</acronym> is
+ functioning by obtaining and listing a ticket for the
+ principal that was just created from the command-line of the
+ <acronym>KDC</acronym>:</para>
<screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
tillman at EXAMPLE.ORG's Password:
@@ -1266,7 +1263,8 @@ Credentials cache: FILE:/tmp/krb5cc_500
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG at EXAMPLE.ORG</screen>
- <para>The temporary ticket can be revoked when the test is finished:</para>
+ <para>The temporary ticket can be revoked when the test is
+ finished:</para>
<screen>&prompt.user; <userinput>kdestroy</userinput></screen>
</sect2>
@@ -1283,23 +1281,21 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt
<para>To configure a server to use
<application>Kerberos</application> authentication, copy
<filename>/etc/krb5.conf</filename> from the
- <acronym>KDC</acronym> to the server in a secure
- fashion, such as &man.scp.1;, or physically via removable
- media.</para>
+ <acronym>KDC</acronym> to the server in a secure fashion, such
+ as &man.scp.1;, or physically via removable media.</para>
<para>Next, create <filename>/etc/krb5.keytab</filename> on the
- server.
- This is the major difference between a server providing
- <application>Kerberos</application> enabled daemons and a
- workstation: the server must have a
- <filename>keytab</filename>. This file 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 transferred
- to the server using <command>kadmin</command>. This is handy because the
- host principal, the <acronym>KDC</acronym> end of the
+ server. This is the major difference between a server
+ providing <application>Kerberos</application> enabled daemons
+ and a workstation: the server must have a
+ <filename>keytab</filename>. This file 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 transferred to the server using
+ <command>kadmin</command>. This is handy because the host
+ principal, the <acronym>KDC</acronym> end of the
<filename>krb5.keytab</filename>, is also created using
<command>kadmin</command>.</para>
@@ -1308,17 +1304,17 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt
<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 can securely connect to the
+ lists. Instead of enabling remote <command>kadmin</command>
+ access, the administrator can 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> from the
- <application>Kerberos</application> server. This adds
- the server's host principal. Then, use <command>ext</command>
- to extract the server's host principal to its own keytab:</para>
+ <application>Kerberos</application> server. This adds the
+ server's host principal. Then, use <command>ext</command> to
+ extract the server's host principal to its own keytab:</para>
<screen>&prompt.root; <userinput>kadmin</userinput>
kadmin><userinput> add --random-key host/myserver.example.org</userinput>
@@ -1350,11 +1346,11 @@ kadmin><userinput> exit</userinput></
<para>At this point, the server can communicate with the
<acronym>KDC</acronym> using
- <filename>krb5.conf</filename> and it can prove its
- own identity with <filename>krb5.keytab</filename>. It is now
+ <filename>krb5.conf</filename> and it can prove its own
+ identity with <filename>krb5.keytab</filename>. It is now
ready for the <application>Kerberos</application> services to
- be enabled. For this example, the &man.telnetd.8; service
- is enabled in <filename>/etc/inetd.conf</filename> and
+ be enabled. For this example, the &man.telnetd.8; service is
+ enabled in <filename>/etc/inetd.conf</filename> and
&man.inetd.8; has been restarted with <command>service inetd
restart</command>:</para>
@@ -1376,36 +1372,34 @@ kadmin><userinput> exit</userinput></
<para>To configure a client to use
<application>Kerberos</application>, securely copy
- <filename>/etc/krb5.conf</filename>
- to the client computer from the
- <acronym>KDC</acronym>.</para>
+ <filename>/etc/krb5.conf</filename> to the client computer
+ from the <acronym>KDC</acronym>.</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 an existing ticket for the principal.
- <application>Kerberos</application> applications
- should also be able to connect to
+ <command>klist</command>, and <command>kdestroy</command> from
+ the client to obtain, show, and then delete an existing ticket
+ for the 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>.</para>
<para>When testing a Kerberized application, try using a packet
- sniffer such as <command>tcpdump</command> to confirm that the password
- is not sent in the clear.</para>
+ sniffer such as <command>tcpdump</command> to confirm that the
+ password is not sent in the clear.</para>
- <para>Various <application>Kerberos</application>
- client applications are available.
- &os; installs <command>telnetd</command> as the only
+ <para>Various <application>Kerberos</application> client
+ applications are available. &os; installs
+ <command>telnetd</command> as the only
<application>Kerberos</application> enabled service. The
Heimdal package or port installs
<application>Kerberos</application> enabled versions of
<command>ftpd</command>, <command>rshd</command>,
- <command>rcp</command>, <command>rlogind</command>, and
- a few other less common programs. The <acronym>MIT</acronym>
- port contains a full suite of
- <application>Kerberos</application> client
- applications.</para>
+ <command>rcp</command>, <command>rlogind</command>, and a few
+ other less common programs. The <acronym>MIT</acronym> port
+ contains a full suite of <application>Kerberos</application>
+ client applications.</para>
<indexterm>
<primary><filename>.k5login</filename></primary>
@@ -1429,8 +1423,8 @@ kadmin><userinput> exit</userinput></
<para>The <filename>.k5login</filename> and
<filename>.k5users</filename> files, placed in a user's home
directory, can be used to solve this problem. For example, if
- the following <filename>.k5login</filename> is
- placed in the home directory of <systemitem
+ the following <filename>.k5login</filename> is placed in the
+ home directory of <systemitem
class="username">webdevelopers</systemitem>, both principals
listed will have access to that account without requiring a
shared password.:</para>
@@ -1445,22 +1439,22 @@ jdoe at example.org</screen>
<sect2>
<title><acronym>MIT</acronym> Differences</title>
- <para>The major difference between the <acronym>MIT</acronym> and
- Heimdal implementations is that <command>kadmin</command> has a different, but
- equivalent, set of commands and uses a different protocol.
- If the <acronym>KDC</acronym> is <acronym>MIT</acronym>, the
- Heimdal version of <command>kadmin</command> cannot be used to administer
- the <acronym>KDC</acronym> remotely, and vice versa.</para>
+ <para>The major difference between the <acronym>MIT</acronym>
+ and Heimdal implementations is that <command>kadmin</command>
+ has a different, but equivalent, set of commands and uses a
+ different protocol. If the <acronym>KDC</acronym> is
+ <acronym>MIT</acronym>, the Heimdal version of
+ <command>kadmin</command> cannot be used to administer the
+ <acronym>KDC</acronym> remotely, and vice versa.</para>
<para>Client applications may also use slightly different
- command line options to accomplish the same tasks.
- Following the instructions at
- <application>Kerberos</application> <link
+ command line options to accomplish the same tasks. Following
+ the instructions at <application>Kerberos</application> <link
xlink:href="http://web.mit.edu/Kerberos/www/">http://web.mit.edu/Kerberos/www/</link>
is recommended. Be careful of path issues: the
<acronym>MIT</acronym> port installs into
- <filename>/usr/local/</filename> by default, and the
- &os; system applications run instead of the
+ <filename>/usr/local/</filename> by default, and the &os;
+ system applications run instead of the
<acronym>MIT</acronym> versions if <envar>PATH</envar> lists
the system directories first.</para>
@@ -1469,10 +1463,10 @@ jdoe at example.org</screen>
<package>security/krb5</package> port, be sure to read
<filename>/usr/local/share/doc/krb5/README.FreeBSD</filename>
installed by the port to understand why logins via
- <command>telnetd</command> and <command>klogind</command> behave
- somewhat oddly. Correcting the <quote>incorrect permissions
- on cache file</quote> behavior requires that the
- <command>login.krb5</command> binary be used for
+ <command>telnetd</command> and <command>klogind</command>
+ behave somewhat oddly. Correcting the <quote>incorrect
+ permissions on cache file</quote> behavior requires that
+ the <command>login.krb5</command> binary be used for
authentication so that it can properly change ownership for
the forwarded credentials.</para>
</note>
@@ -1494,12 +1488,12 @@ kadmind5_server_enable="YES"</programlis
<para>When configuring and troubleshooting
<application>Kerberos</application>, keep the following points
in mind:</para>
-
+
<itemizedlist>
<listitem>
- <para>When using either Heimdal or
- <acronym>MIT</acronym>
- <application>Kerberos</application>, ensure that the <envar>PATH</envar> lists the
+ <para>When using either Heimdal or <acronym>MIT</acronym>
+ <application>Kerberos</application>, ensure that the
+ <envar>PATH</envar> lists the
<application>Kerberos</application> versions of the
client applications before the system versions.</para>
</listitem>
@@ -1536,8 +1530,9 @@ kadmind5_server_enable="YES"</programlis
<acronym>KDC</acronym> do not set the permissions for
<command>ksu</command> to be setuid <systemitem
class="username">root</systemitem>. This means that
- <command>ksu</command> does not work. This is a permissions problem, not a
- <acronym>KDC</acronym> error.</para>
+ <command>ksu</command> does not work. This is a
+ permissions problem, not a <acronym>KDC</acronym>
+ error.</para>
</listitem>
<listitem>
@@ -1545,50 +1540,50 @@ kadmind5_server_enable="YES"</programlis
<application>Kerberos</application>, to allow a
principal to have a ticket life longer than the default
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
+ &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>
</listitem>
<listitem>
- <para>When running a packet sniffer on the
- <acronym>KDC</acronym> to aid in troubleshooting while
- running <command>kinit</command> from a workstation, the Ticket
- Granting Ticket (<acronym>TGT</acronym>) is sent
- immediately, even before the
- password is typed. This is because the
- <application>Kerberos</application> server freely
- transmits a <acronym>TGT</acronym> to any unauthorized
- request. However, every <acronym>TGT</acronym> is
- encrypted in a key derived from the user's password.
- When a user types their password, it is not sent to the
- <acronym>KDC</acronym>, it is instead used to decrypt
- the <acronym>TGT</acronym> that <command>kinit</command> already
- obtained. If the decryption process results in a valid
- ticket with a valid time stamp, the user has valid
- <application>Kerberos</application> credentials.
- These credentials include a session key for
- establishing secure communications with the
- <application>Kerberos</application> server in the
- future, as well as the actual <acronym>TGT</acronym>,
- which is encrypted with the
- <application>Kerberos</application> server's own key.
- This second layer of encryption allows the
- <application>Kerberos</application> server to verify
- the authenticity of each <acronym>TGT</acronym>.</para>
+ <para>When running a packet sniffer on the
+ <acronym>KDC</acronym> to aid in troubleshooting while
+ running <command>kinit</command> from a workstation, the
+ Ticket Granting Ticket (<acronym>TGT</acronym>) is sent
+ immediately, even before the password is typed. This is
+ because the <application>Kerberos</application> server
+ freely transmits a <acronym>TGT</acronym> to any
+ unauthorized request. However, every
+ <acronym>TGT</acronym> is encrypted in a key derived from
+ the user's password. When a user types their password, it
+ is not sent to the <acronym>KDC</acronym>, it is instead
+ used to decrypt the <acronym>TGT</acronym> that
+ <command>kinit</command> already obtained. If the
+ decryption process results in a valid ticket with a valid
+ time stamp, the user has valid
+ <application>Kerberos</application> credentials. These
+ credentials include a session key for establishing secure
+ communications with the
+ <application>Kerberos</application> server in the future,
+ as well as the actual <acronym>TGT</acronym>, which is
+ encrypted with the <application>Kerberos</application>
+ server's own key. This second layer of encryption allows
+ the <application>Kerberos</application> server to verify
+ the authenticity of each <acronym>TGT</acronym>.</para>
</listitem>
<listitem>
- <para>To use long ticket lifetimes when
- using <application>OpenSSH</application> to connect to the
+ <para>To use long ticket lifetimes when using
+ <application>OpenSSH</application> to connect to the
machine where the ticket is stored, make sure that
<application>Kerberos</application>
<option>TicketCleanup</option> is set to
<literal>no</literal> in
- <filename>/etc/ssh/sshd_config</filename>. Otherwise, tickets will be
- deleted at log out.</para>
+ <filename>/etc/ssh/sshd_config</filename>. Otherwise,
+ tickets will be deleted at log out.</para>
</listitem>
<listitem>
@@ -1614,104 +1609,106 @@ kadmind5_server_enable="YES"</programlis
</sect2>
<sect2>
- <title>Mitigating <application>Kerberos</application> Limitations</title>
+ <title>Mitigating <application>Kerberos</application>
+ Limitations</title>
<indexterm>
<primary>Kerberos5</primary>
<secondary>limitations and shortcomings</secondary>
</indexterm>
- <para>Since <application>Kerberos</application> is an all or
- nothing approach, every service enabled on the network must either be modified
- to work with <application>Kerberos</application> or be
- otherwise secured against network attacks. This is to prevent
- user credentials from being stolen and re-used. An example is when
- <application>Kerberos</application> is
- enabled on all remote shells but the non-Kerberized
- <acronym>POP3</acronym> mail server sends passwords in
- plain text.</para>
-
- <para><application>Kerberos</application> is intended for
- single-user workstations. In a multi-user environment,
- <application>Kerberos</application> is less secure as it
- stores the tickets in <filename>/tmp</filename>,
- which is readable by all users. If a user is sharing a
- computer, it is possible that the user's
- tickets can be stolen or copied by another user.</para>
-
- <para>This can be overcome with <command>kinit -c</command>
- or, preferably, the
- <envar>KRB5CCNAME</envar> environment variable. Storing
- the ticket in the user's home directory and using file
- permissions are commonly used to mitigate this
- problem.</para>
-
- <para>The <acronym>KDC</acronym> is a single point of failure. By design, the
- <acronym>KDC</acronym> must be as secure
- as its master password database. The <acronym>KDC</acronym>
- should have absolutely no other services running on it and
- should be physically secure. The danger is high because
- <application>Kerberos</application> stores all passwords
- encrypted with the same master key which is
- stored as a file on the <acronym>KDC</acronym>.</para>
-
- <para>A compromised master key is not quite as bad as one
- might fear. The master key is only used to encrypt the
- <application>Kerberos</application> database and as a seed
- for the random number generator. As long as access to the
- <acronym>KDC</acronym> is secure, an attacker cannot do much
- with the master key.</para>
-
- <para>If the <acronym>KDC</acronym> is
- unavailable, network services are unusable as authentication
- cannot be performed. This can be alleviated with a single
- master <acronym>KDC</acronym> and one or more slaves, and
- with careful implementation of secondary or fall-back
- authentication using <acronym>PAM</acronym>.</para>
-
- <para><application>Kerberos</application> allows users, hosts
- and services to authenticate between themselves. It does
- not have a mechanism to authenticate the
- <acronym>KDC</acronym> to the users, hosts, or services.
- This means that a trojanned <command>kinit</command> could record all
- user names and passwords. File system integrity checking
- tools like <package>security/tripwire</package> can
- alleviate this.</para>
+ <para>Since <application>Kerberos</application> is an all or
+ nothing approach, every service enabled on the network must
+ either be modified to work with
+ <application>Kerberos</application> or be otherwise secured
+ against network attacks. This is to prevent user credentials
+ from being stolen and re-used. An example is when
+ <application>Kerberos</application> is enabled on all remote
+ shells but the non-Kerberized <acronym>POP3</acronym> mail
+ server sends passwords in plain text.</para>
+
+ <para><application>Kerberos</application> is intended for
+ single-user workstations. In a multi-user environment,
+ <application>Kerberos</application> is less secure as it
+ stores the tickets in <filename>/tmp</filename>, which is
+ readable by all users. If a user is sharing a computer, it is
+ possible that the user's tickets can be stolen or copied by
+ another user.</para>
+
+ <para>This can be overcome with <command>kinit -c</command> or,
+ preferably, the <envar>KRB5CCNAME</envar> environment
+ variable. Storing the ticket in the user's home directory and
+ using file permissions are commonly used to mitigate this
+ problem.</para>
+
+ <para>The <acronym>KDC</acronym> is a single point of failure.
+ By design, the <acronym>KDC</acronym> must be as secure as its
+ master password database. The <acronym>KDC</acronym> should
+ have absolutely no other services running on it and should be
+ physically secure. The danger is high because
+ <application>Kerberos</application> stores all passwords
+ encrypted with the same master key which is stored as a file
+ on the <acronym>KDC</acronym>.</para>
+
+ <para>A compromised master key is not quite as bad as one might
+ fear. The master key is only used to encrypt the
+ <application>Kerberos</application> database and as a seed for
+ the random number generator. As long as access to the
+ <acronym>KDC</acronym> is secure, an attacker cannot do much
+ with the master key.</para>
+
+ <para>If the <acronym>KDC</acronym> is unavailable, network
+ services are unusable as authentication cannot be performed.
+ This can be alleviated with a single master
+ <acronym>KDC</acronym> and one or more slaves, and with
+ careful implementation of secondary or fall-back
+ authentication using <acronym>PAM</acronym>.</para>
+
+ <para><application>Kerberos</application> allows users, hosts
+ and services to authenticate between themselves. It does not
+ have a mechanism to authenticate the
+ <acronym>KDC</acronym> to the users, hosts, or services. This
+ means that a trojanned <command>kinit</command> could record
+ all user names and passwords. File system integrity checking
+ tools like <package>security/tripwire</package> can
+ alleviate this.</para>
</sect2>
<sect2>
- <title>Access Issues with Kerberos and <command>ssh</command></title>
+ <title>Access Issues with Kerberos and
+ <command>ssh</command></title>
<indexterm><primary>&man.ssh.1;</primary></indexterm>
- <para>Kerberos is an
- excellent authentication protocol, but there are bugs in the
- kerberized versions of <command>telnet</command> and <command>rlogin</command> that
+ <para>Kerberos is an excellent authentication protocol, but
+ there are bugs in the kerberized versions of
+ <command>telnet</command> and <command>rlogin</command> that
make them unsuitable for dealing with binary streams. By
default, Kerberos does not encrypt a session unless
- <option>-x</option> is used, whereas <command>ssh</command> encrypts
- everything.</para>
+ <option>-x</option> is used, whereas <command>ssh</command>
+ encrypts everything.</para>
- <para>While <command>ssh</command> works well, it forwards encryption keys
- by default. This introduces a security risk to a user who
- uses <command>ssh</command> to access an insecure machine from a secure
- workstation. The keys themselves are not exposed, but
- <command>ssh</command> installs a forwarding port for the duration of the
- login. If an attacker has broken
- <systemitem class="username">root</systemitem> on
- the insecure machine, he can utilize that port to gain access
- to any other machine that those keys unlock.</para>
-
- <para>It is recommended that <command>ssh</command> is used in combination
- with Kerberos whenever possible for staff logins as it
- can be compiled with Kerberos support. This
- reduces reliance on potentially exposed <acronym>SSH</acronym>
- keys while protecting passwords via Kerberos. Keys should
- only be used for automated tasks from secure machines as this
- is something that Kerberos is unsuited to. It is recommended
- to either turn off key-forwarding in the
- <acronym>SSH</acronym> configuration, or to make use
- of <literal>from=IP/DOMAIN</literal> in
+ <para>While <command>ssh</command> works well, it forwards
+ encryption keys by default. This introduces a security risk
+ to a user who uses <command>ssh</command> to access an
+ insecure machine from a secure workstation. The keys
+ themselves are not exposed, but <command>ssh</command>
+ installs a forwarding port for the duration of the login. If
+ an attacker has broken <systemitem
+ class="username">root</systemitem> on the insecure machine,
+ he can utilize that port to gain access to any other machine
+ that those keys unlock.</para>
+
+ <para>It is recommended that <command>ssh</command> is used in
+ combination with Kerberos whenever possible for staff logins
+ as it can be compiled with Kerberos support. This reduces
+ reliance on potentially exposed <acronym>SSH</acronym> keys
+ while protecting passwords via Kerberos. Keys should only be
+ used for automated tasks from secure machines as this is
+ something that Kerberos is unsuited to. It is recommended to
+ either turn off key-forwarding in the
+ <acronym>SSH</acronym> configuration, or to make use of
+ <literal>from=IP/DOMAIN</literal> in
<filename>authorized_keys</filename> to make the key only
usable to entities logging in from specific machines.</para>
</sect2>
More information about the svn-doc-all
mailing list