Date: Fri, 4 Apr 2014 15:48:10 +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: r44445 - head/en_US.ISO8859-1/books/handbook/security Message-ID: <201404041548.s34FmAal060793@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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@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@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@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404041548.s34FmAal060793>