Date: Fri, 4 Apr 2014 15:21:37 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44444 - head/en_US.ISO8859-1/books/handbook/security Message-ID: <201404041521.s34FLb5f051560@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Fri Apr 4 15:21:36 2014 New Revision: 44444 URL: http://svnweb.freebsd.org/changeset/doc/44444 Log: Finish editorial review of Kerberos chapter. 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:16:08 2014 (r44443) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:21:36 2014 (r44444) @@ -1366,23 +1366,24 @@ kadmin><userinput> exit</userinput></ </sect2> <sect2> - <title><application>Kerberos</application> Enabling a Client - with Heimdal</title> + <title>Configuring a Client to use + <application>Kerberos</application></title> <indexterm> <primary>Kerberos5</primary> <secondary>configure clients</secondary> </indexterm> - <para>Setting up a client computer is easy as only - <filename>/etc/krb5.conf</filename> is needed. Securely copy - this file over to the client computer from the + <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> - <para>Test the client by attempting to use &man.kinit.1;, - &man.klist.1;, and &man.kdestroy.1; from the client to obtain, - show, and then delete a ticket for the principal created - above. <application>Kerberos</application> applications + <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 <application>Kerberos</application> enabled servers. If that does not work but obtaining a ticket does, the problem is @@ -1390,26 +1391,21 @@ kadmin><userinput> exit</userinput></ <acronym>KDC</acronym>.</para> <para>When testing a Kerberized application, try using a packet - sniffer such as &man.tcpdump.1; to confirm that the password + sniffer such as <command>tcpdump</command> to confirm that the password is not sent in the clear.</para> - <para>Various non-core <application>Kerberos</application> - client applications are available. The <quote>minimal</quote> - installation in &os; installs &man.telnetd.8; as the only - <application>Kerberos</application> enabled service.</para> - - <para>The Heimdal port installs + <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 - &man.ftpd.8;, &man.rshd.8;, &man.rcp.1;, &man.rlogind.8;, and + <command>ftpd</command>, <command>rshd</command>, + <command>rcp</command>, <command>rlogind</command>, and a few other less common programs. The <acronym>MIT</acronym> - port also contains a full suite of + port contains a full suite of <application>Kerberos</application> client applications.</para> - </sect2> - - <sect2> - <title>User Configuration Files: <filename>.k5login</filename> - and <filename>.k5users</filename></title> <indexterm> <primary><filename>.k5login</filename></primary> @@ -1433,7 +1429,7 @@ 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 - <filename>.k5login</filename> with the following contents is + 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 @@ -1447,15 +1443,63 @@ jdoe@example.org</screen> </sect2> <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>Client applications may also use slightly different + 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 + <acronym>MIT</acronym> versions if <envar>PATH</envar> lists + the system directories first.</para> + + <note> + <para>With the &os; <acronym>MIT</acronym> + <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 + authentication so that it can properly change ownership for + the forwarded credentials.</para> + </note> + + <para>The following edits should also be made to + <filename>rc.conf</filename>:</para> + + <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc" +kadmind5_server="/usr/local/sbin/kadmind" +kerberos5_server_flags="" +kerberos5_server_enable="YES" +kadmind5_server_enable="YES"</programlisting> + </sect2> + + <sect2> <title><application>Kerberos</application> Tips, Tricks, and Troubleshooting</title> + <para>When configuring and troubleshooting + <application>Kerberos</application>, keep the following points + in mind:</para> + <itemizedlist> <listitem> - <para>When using either the Heimdal or + <para>When using either Heimdal or <acronym>MIT</acronym> - <application>Kerberos</application><indexterm><primary>Kerberos5</primary><secondary>troubleshooting</secondary></indexterm> - ports, ensure that the <envar>PATH</envar> lists the + <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> @@ -1468,12 +1512,6 @@ jdoe@example.org</screen> </listitem> <listitem> - <para><acronym>MIT</acronym> and Heimdal interoperate - except for &man.kadmin.8;, which is not - standardized.</para> - </listitem> - - <listitem> <para>If the hostname is changed, the <systemitem class="username">host/</systemitem> principal must be changed and the keytab updated. This also applies to @@ -1485,7 +1523,7 @@ jdoe@example.org</screen> <listitem> <para>All hosts in the realm must be both forward and reverse resolvable in <acronym>DNS</acronym> or, at a - minimum, in <filename>/etc/hosts</filename>. CNAMEs + minimum, exist in <filename>/etc/hosts</filename>. CNAMEs will work, but the A and PTR records must be correct and in place. The error message for unresolvable hosts is not intuitive: <errorname>Kerberos5 refuses authentication @@ -1496,31 +1534,30 @@ jdoe@example.org</screen> <listitem> <para>Some operating systems that act as clients to the <acronym>KDC</acronym> do not set the permissions for - &man.ksu.1; to be setuid <systemitem + <command>ksu</command> to be setuid <systemitem class="username">root</systemitem>. This means that - &man.ksu.1; does not work. This is not a + <command>ksu</command> does not work. This is a permissions problem, not a <acronym>KDC</acronym> error.</para> </listitem> <listitem> <para>With <acronym>MIT</acronym> - <application>Kerberos</application>, in order to allow a + <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 maxlife of both 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. Then - the principal can use <command>kinit -l</command> to + 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> - <note> <para>When running a packet sniffer on the <acronym>KDC</acronym> to aid in troubleshooting while - running &man.kinit.1; from a workstation, the Ticket + running <command>kinit</command> from a workstation, the Ticket Granting Ticket (<acronym>TGT</acronym>) is sent - immediately upon running &man.kinit.1;, even before the + immediately, even before the password is typed. This is because the <application>Kerberos</application> server freely transmits a <acronym>TGT</acronym> to any unauthorized @@ -1528,7 +1565,7 @@ jdoe@example.org</screen> 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 &man.kinit.1; already + 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. @@ -1541,17 +1578,16 @@ jdoe@example.org</screen> This second layer of encryption allows the <application>Kerberos</application> server to verify the authenticity of each <acronym>TGT</acronym>.</para> - </note> </listitem> <listitem> - <para>To use long ticket lifetimes, such as a week, when + <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>sshd_config</filename> or else tickets will be + <filename>/etc/ssh/sshd_config</filename>. Otherwise, tickets will be deleted at log out.</para> </listitem> @@ -1578,106 +1614,45 @@ jdoe@example.org</screen> </sect2> <sect2> - <title>Differences with the <acronym>MIT</acronym> - Port</title> - - <para>The major difference between <acronym>MIT</acronym> and - Heimdal relates to &man.kadmin.8; which 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 &man.kadmin.8; cannot be used to administer - the <acronym>KDC</acronym> remotely, and vice versa.</para> - - <para>The client applications may also use slightly different - command line options to accomplish the same tasks. - Following the instructions on the <acronym>MIT</acronym> - <application>Kerberos</application> <link - xlink:href="http://web.mit.edu/Kerberos/www/">web - site</link> is recommended. Be careful of path issues: the - <acronym>MIT</acronym> port installs into - <filename>/usr/local/</filename> by default, and the - <quote>normal</quote> system applications run instead of - <acronym>MIT</acronym> versions if <envar>PATH</envar> lists - the system directories first.</para> - - <note> - <para>With the &os; <acronym>MIT</acronym> - <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 - &man.telnetd.8; 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> - - <para>The following edits should also be made to - <filename>rc.conf</filename>:</para> - - <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc" -kadmind5_server="/usr/local/sbin/kadmind" -kerberos5_server_flags="" -kerberos5_server_enable="YES" -kadmind5_server_enable="YES"</programlisting> - - <para>This is done because the applications for - <acronym>MIT</acronym> Kerberos installs binaries in the - <filename>/usr/local</filename> hierarchy.</para> - </sect2> - - <sect2> - <title>Mitigating Limitations Found in - <application>Kerberos</application></title> + <title>Mitigating <application>Kerberos</application> Limitations</title> <indexterm> <primary>Kerberos5</primary> <secondary>limitations and shortcomings</secondary> </indexterm> - <sect3> - <title><application>Kerberos</application> is an All or - Nothing Approach</title> - - <para>Every service enabled on the network must be modified - to work with <application>Kerberos</application>, or be - otherwise secured against network attacks, or else the - user's credentials could be stolen and re-used. An example - of this would be <application>Kerberos</application> - enabling all remote shells but not converting the - <acronym>POP3</acronym> mail server which sends passwords in + <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> - </sect3> - - <sect3> - <title><application>Kerberos</application> is Intended for - Single-User Workstations</title> - <para>In a multi-user environment, - <application>Kerberos</application> is less secure. This is - because it stores the tickets in <filename>/tmp</filename>, + <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 with other users, it is possible that the user's + computer, it is possible that the user's tickets can be stolen or copied by another user.</para> - <para>This can be overcome with the <literal>-c</literal> - command-line option or, preferably, the + <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> - </sect3> - <sect3> - <title>The KDC is a Single Point of Failure</title> - - <para>By design, the <acronym>KDC</acronym> must be as secure + <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 <quote>master</quote> key which is + 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 @@ -1687,56 +1662,49 @@ kadmind5_server_enable="YES"</programlis <acronym>KDC</acronym> is secure, an attacker cannot do much with the master key.</para> - <para>Additionally, if the <acronym>KDC</acronym> is + <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> - </sect3> - - <sect3> - <title><application>Kerberos</application> - Shortcomings</title> <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 &man.kinit.1; could record all + <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> - </sect3> </sect2> <sect2> - <title>Access Issues with Kerberos and &man.ssh.1;</title> + <title>Access Issues with Kerberos and <command>ssh</command></title> <indexterm><primary>&man.ssh.1;</primary></indexterm> - <para>There are a few issues with both Kerberos and &man.ssh.1; - that need to be addressed if they are used. Kerberos is an + <para>Kerberos is an excellent authentication protocol, but there are bugs in the - kerberized versions of &man.telnet.1; and &man.rlogin.1; that + 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 &man.ssh.1; encrypts + <option>-x</option> is used, whereas <command>ssh</command> encrypts everything.</para> - <para>While &man.ssh.1; works well, it forwards encryption keys + <para>While <command>ssh</command> works well, it forwards encryption keys by default. This introduces a security risk to a user who - uses &man.ssh.1; to access an insecure machine from a secure + uses <command>ssh</command> to access an insecure machine from a secure workstation. The keys themselves are not exposed, but - &man.ssh.1; installs a forwarding port for the duration of the + <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 &man.ssh.1; is used in combination - with Kerberos whenever possible for staff logins and - &man.ssh.1; can be compiled with Kerberos support. This + <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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404041521.s34FLb5f051560>