Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jun 2016 13:38:23 +0000 (UTC)
From:      Bjoern Heidotting <bhd@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r48947 - head/de_DE.ISO8859-1/books/handbook/security
Message-ID:  <201606181338.u5IDcNwG062307@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: bhd
Date: Sat Jun 18 13:38:23 2016
New Revision: 48947
URL: https://svnweb.freebsd.org/changeset/doc/48947

Log:
  Update to r44840:
  
  Technical review of the Kerberos chapter
  
  Many of the statements in this chapter were just plain wrong.
  
  Apply some major modernization, in particular the current Kerberos RFC is
  4120, not 1510.  Kerberized telnet, rlogin, ftp and similar are no longer
  recommended -- use ssh and scp instead.
  
  The heimdal in base is no longer crippled so as to be a minimal installation;
  it is fully functional.  The heimdal in ports does offer the option to install
  some additional features such as KCM and PKINIT.
  
  Add a bit more introduction to Kerberos terminology and conventions.
  
  Make the sample output closer to the current reality.
  
  Don't imply that eight characters is a particularly strong password.
  
  security/krb5 does not install ktelnetd, klogind, and friends anymore,
  so there's no need to mention its README.FreeBSD here (especially since
  these things are disrecommended anyway).
  
  www/mod_auth_kerb uses the HTTP/ principal, not the www/ principal.
  
  Kerberized ssh uses GSSAPI these days, so the Kerberos-specific options
  are not worth mentioning.
  
  Kerberos works just fine on multiuser machines; the permissions of
  credentials cache files are set to 0600.
  
  Remove the section on access issues with kerberos and ssh; it is very
  confused.  (It seems to be talking about ssh keys and ssh-agent, but
  in a very unclear and inaccurate fashion.)
  
  There is still more to be done here, but this should get us most of the way.

Modified:
  head/de_DE.ISO8859-1/books/handbook/security/chapter.xml

Modified: head/de_DE.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/de_DE.ISO8859-1/books/handbook/security/chapter.xml	Sat Jun 18 11:58:10 2016	(r48946)
+++ head/de_DE.ISO8859-1/books/handbook/security/chapter.xml	Sat Jun 18 13:38:23 2016	(r48947)
@@ -5,7 +5,7 @@
 
      $FreeBSD$
      $FreeBSDde: de-docproj/books/handbook/security/chapter.xml,v 1.178 2012/04/30 17:07:41 bcr Exp $
-     basiert auf: r44719
+     basiert auf: r44840
 -->
 <chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
   <info><title>Sicherheit</title>
@@ -188,9 +188,9 @@
       Fragen Sie im Zweifelsfall das Sicherheitspersonal.</para>
 
     <para>Der übrige Teil dieser Einführung beschreibt, wie einige
-      dieser grundlegenden Sicherheitskonfigurationen auf einem
-      &os;-System durchgeführt werden.  Der Rest dieses Kapitels
-      beschreibt einige spezifische Werkzeuge, die verwendet werden
+      grundlegende Sicherheitskonfigurationen auf einem
+      &os;-System durchgeführt werden.  Der Rest des Kapitels
+      zeigt einige spezifische Werkzeuge, die verwendet werden
       können, um eine Sicherheitsrichtlinie auf einem &os;-System zu
       implementieren.</para>
 
@@ -465,9 +465,9 @@ Enter new password:</screen>
       <para>Wird ein Rootkit erkannt, ist dies bereits ein Zeichen
 	dafür, dass das System an einem bestimmten Zeitpunkt
 	kompromittiert wurde.  Meist neigen diese Art von Anwendungen
-	dazu, sehr gut versteckt zu sein.  Dieser Abschnitt zeigt ein
-	Werkzeug, mit dem Rootkits erkannt werden können:
-	<package>security/rkhunter</package>.</para>
+	dazu, sehr gut versteckt zu sein.  Dieser Abschnitt zeigt das
+	Werkzeug <package>security/rkhunter</package>, mit dem
+	Rootkits erkannt werden können.</para>
 
       <para>Nach der Installation dieses Ports oder Pakets kann das
 	System mit dem folgenden Kommando überprüft werden.  Das
@@ -492,13 +492,12 @@ Enter new password:</screen>
 	läuft, für die er verantwortlich ist.  Werkzeuge von
 	Drittanbietern, wie <application>rkhunter</application> oder
 	<package>sysutils/lsof</package>, sowie native Befehle wie
-	<application>netstat</application> oder
-	<application>ps</application>, können eine große Menge an
-	Informationen über das System anzeigen.  Machen Sie sich
-	Notizen darüber, was <quote>normal</quote> ist, und fragen Sie
-	nach, wenn Ihnen etwas suspekt erscheint.  Eine
-	Beeinträchtigung zu verhindern ist ideal, aber die Erkennung
-	einer Beeinträchtigung ist ein Muss.</para>
+	<command>netstat</command> oder <command>ps</command>, können
+	eine große Menge an Informationen über das System anzeigen.
+	Machen Sie sich Notizen darüber, was <quote>normal</quote>
+	ist, und fragen Sie nach, wenn Ihnen etwas suspekt erscheint.
+	Eine Beeinträchtigung zu verhindern ist ideal, aber die
+	Erkennung einer Beeinträchtigung ist ein Muss.</para>
     </sect2>
 
     <sect2 xml:id="security-ids">
@@ -1244,6 +1243,14 @@ sendmail : PARANOID : deny</programlisti
       der Ports-Sammlung steht eine weitere Distribution, mit mehr
       konfigurierbaren Optionen zur Verfügung.</para>
 
+    <para>Unter <application>Kerberos</application> werden Benutzer
+      und Dienste als <quote>Prinzipale</quote> bezeichnet, die
+      innerhalb einer administrativen Domäne, dem sogenannten
+      <quote>Realm</quote> enthalten sind.  Ein typisches
+      Benutzer-Prinzipal hätte das Format
+      <literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal>
+      (Realms sind traditionell in Großbuchstaben).</para>
+
     <para>Die folgenden Anweisungen beschreiben, wie Sie das mit
       &os; gelieferte Heimdal-<application>Kerberos</application>
       einrichten.</para>
@@ -1286,10 +1293,12 @@ sendmail : PARANOID : deny</programlisti
 	Center (<acronym>KDC</acronym>).  Das <acronym>KDC</acronym>
 	verteilt <firstterm>Tickets</firstterm>, mit denen ein
 	Dienst die Identität eines Benutzers feststellen kann.
-	Alle Mitglieder eines <application>Kerberos</application>-Realms
-	vertrauen dem <acronym>KDC</acronym>, daher gelten für
-	das <acronym>KDC</acronym> erhöhte
-	Sicherheitsanforderungen.</para>
+	Weil alle Mitglieder eines
+	<application>Kerberos</application>-Realms dem
+	<acronym>KDC</acronym> vertrauen, gelten für das
+	<acronym>KDC</acronym> erhöhte Sicherheitsanforderungen.
+	Der direkte Zugriff auf das <acronym>KDC</acronym> sollte
+	daher eingeschränkt sein.</para>
 
       <para>Obwohl der <application>Kerberos</application>-Server
 	wenig Ressourcen benötigt, sollte das <acronym>KDC</acronym>
@@ -1299,8 +1308,8 @@ sendmail : PARANOID : deny</programlisti
       <para>Das <acronym>KDC</acronym> wird in
         <filename>/etc/rc.conf</filename> wie folgt aktiviert:</para>
 
-      <programlisting>kerberos5_server_enable="YES"
-kadmind5_server_enable="YES"</programlisting>
+      <programlisting>kdc_enable="YES"
+kadmind_enable="YES"</programlisting>
 
       <para>Danach wird <filename>/etc/krb5.conf</filename>
 	wie folgt bearbeitet:</para>
@@ -1319,20 +1328,21 @@ kadmind5_server_enable="YES"</programlis
 	qualifizierte Name des <acronym>KDC</acronym>s
 	<systemitem
 	  class="fqdomainname">kerberos.example.org</systemitem> ist.
-	Wenn das <acronym>KDC</acronym> einen anderen Namen hat,
-	muss in der <acronym>DNS</acronym>-Zone ein Alias-Eintrag
-	(<acronym>CNAME</acronym>-Record) für das
-	<acronym>KDC</acronym> hinzugefügt werden.</para>
+	Der Rechnername des <acronym>KDC</acronym> muss im
+	<acronym>DNS</acronym> auflösbar sein.</para>
 
 	<para>In großen Netzwerken mit einem ordentlich
 	  konfigurierten <acronym>DNS</acronym>-Server kann die Datei
 	  aus dem obigen Beispiel verkürzt werden:</para>
 
         <programlisting>[libdefaults]
-      default_realm = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
+      default_realm = <replaceable>EXAMPLE.ORG</replaceable>
+[domain_realm]
+    <replaceable>.example.org</replaceable> = <replaceable>EXAMPLE.ORG</replaceable></programlisting>
 
-	<para>Die Zonendatei von <systemitem class="fqdomainname">example.org</systemitem>
-	  muss dann die folgenden Zeilen enthalten:</para>
+	<para>Die Zonendatei von <systemitem
+	    class="fqdomainname">example.org</systemitem> muss dann
+	  die folgenden Zeilen enthalten:</para>
 
 	<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>.
@@ -1343,7 +1353,7 @@ _kerberos           IN  TXT     <replace
       <note>
 	<para>Damit die Clients die
 	  <application>Kerberos</application>-Dienste benutzen
-	  können, muss das <acronym>KDC</acronym> entweder eine
+	  können, <emphasis>muss</emphasis> sie entweder eine
 	  vollständig konfigurierte
 	  <filename>/etc/krb5.conf</filename> enthalten, oder eine
 	  minimale Konfiguration <emphasis>und</emphasis> zusätzlich
@@ -1357,22 +1367,23 @@ _kerberos           IN  TXT     <replace
 	und ist mit einem Passwort geschützt.  Dieses Passwort
 	brauchen Sie sich nicht merken, da ein davon abgeleiteter
 	Schlüssel in <filename>/var/heimdal/m-key</filename>
-	gespeichert wird.  Um den Schlüssel zu erstellen, rufen Sie
-	<command>kstash</command> auf und geben Sie ein Passwort
-	ein:</para>
+	gespeichert wird.  Es wäre durchaus sinnvoll, ein 45-stelliges
+	Zufallspasswort für diesen Zweck zu benutzten.  Um den
+	Schlüssel zu erstellen, rufen Sie <command>kstash</command>
+	auf und geben Sie ein Passwort ein:</para>
 
       <screen>&prompt.root; <userinput>kstash</userinput>
-Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput>
-Verifying password - Master key: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
+Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
+Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
 
-      <para>Nachdem der Schlüssel erstellt wurde, intitialisieren Sie
-	die Datenbank mit <command>kadmin -l</command>.  Die Option
-	weist <command>kadmin</command> an, die lokale Datenbank
-	direkt zu bearbeiten, anstatt den zu diesem Zeitpunkt noch
-	nicht laufenden  Netzwerkdienst &man.kadmind.8; zu benutzen.
-	An der Eingabeaufforderung von <command>kadmin</command> kann
-	mit <command>init</command> die Datenbank des Realms
-	initialisiert werden:</para>
+      <para>Nachdem der Schlüssel erstellt wurde, sollte die Datenbank
+	initialisiert werden.  Das
+	<application>Kerberos</application>-Werkzeug &man.kadmin.8;
+	kann die Datenbank mit <command>kadmin -l</command> direkt
+	bearbeiten, ohne dabei den Netzwerkdienst &man.kadmind.8; zu
+	benutzen.  An der Eingabeaufforderung von
+	<command>kadmin</command> kann mit <command>init</command> die
+	Datenbank des Realms initialisiert werden:</para>
 
       <screen>&prompt.root; <userinput>kadmin -l</userinput>
 kadmin&gt; <userinput>init <replaceable>EXAMPLE.ORG</replaceable></userinput>
@@ -1393,23 +1404,25 @@ Password: <userinput><replaceable>xxxxxx
 Verifying password - Password: <userinput><replaceable>xxxxxxxx</replaceable></userinput></screen>
 
       <para>Jetzt können die <acronym>KDC</acronym>-Dienste mit
-	<command>service kerberos start</command> und
+	<command>service kdc start</command> und
 	<command>service kadmind start</command> gestartet werden.
 	Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste
 	laufen, kann die Funktion des <acronym>KDC</acronym>s
-	schon überprüft werden.  Für den eben angelegten
-	Benutzer können Sie sich vom <acronym>KDC</acronym>
-	Tickets holen und anzeigen lassen:</para>
+	schon überprüft werden, indem Sie für den eben angelegten
+	Benutzer ein Ticket anfordern:</para>
 
       <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
-tillman@EXAMPLE.ORG's Password:
+tillman@EXAMPLE.ORG's Password:</screen>
+
+      <para>Überprüfen Sie, ob das Ticket erfolgreich ausgestellt
+	wurde:</para>
 
-&prompt.user; <userinput>klist</userinput>
-Credentials cache: FILE: /tmp/krb5cc_500
+      <screen>&prompt.user; <userinput>klist</userinput>
+Credentials cache: FILE: /tmp/krb5cc_1001
         Principal: tillman@EXAMPLE.ORG
 
-  Issued           Expires          Principal
-Aug 27 15:37:58  Aug 28 01:37:58  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
+  Issued                Expires               Principal
+Aug 27 15:37:58 2013  Aug 28 01:37:58 2013  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG</screen>
 
       <para>Nachdem der Test abgeschlossen ist, kann das temporäre
 	Ticket zurückgezogen werden:</para>
@@ -1431,7 +1444,7 @@ Aug 27 15:37:58  Aug 28 01:37:58  krbtgt
 	zuerst sichergestellt werden, dass
 	<filename>/etc/krb5.conf</filename> richtig konfiguriert ist.
 	Die Datei kann entweder vom <acronym>KDC</acronym> kopiert,
-	oder auf dem neuen System regeneriert werden.</para>
+	oder auf dem neuen System generiert werden.</para>
 
       <para>Als nächstes muss auf dem Server die
 	<filename>/etc/krb5.keytab</filename> erzeugt werden.  Dies
@@ -1493,6 +1506,8 @@ Aug 27 15:37:58  Aug 28 01:37:58  krbtgt
 kadmin&gt; <userinput>add --random-key <replaceable>host/myserver.example.org</replaceable></userinput>
 Max ticket life [unlimited]:
 Max renewable life [unlimited]:
+Principal expiration time [never]:
+Password expiration time [never]:
 Attributes []:
 kadmin&gt; <userinput>ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput>
 kadmin&gt; <userinput>exit</userinput></screen>
@@ -1514,10 +1529,10 @@ kadmin&gt; <userinput>exit</userinput></
       <para>Anschließend kann die erzeugte keytab sicher mit
 	&man.scp.1; auf Server oder auf einen
 	Wechseldatenträger kopiert werden.  Geben Sie auf jeden Fall
-	einen anderen Namen für die keytab an, weil sonst die keytab
-	des <acronym>KDC</acronym>s überschrieben würde.</para>
+	einen anderen Namen für die keytab an, um unnötige Schlüssel
+	in der keytab des Systems zu vermeiden.</para>
 
-      <para>Wegen der Datei <filename>krb5.conf</filename> kann
+      <para>Mit Hilfe der Datei <filename>krb5.conf</filename> kann
 	der Server nun mit dem <acronym>KDC</acronym> kommunizieren
 	und seine Identität mithilfe der Datei
 	<filename>krb5.keytab</filename> nachweisen.  Jetzt
@@ -1676,8 +1691,9 @@ kadmind5_server_enable="YES"</programlis
 	  <para>Wenn Sie den Namen eines Rechners ändern,
 	    müssen Sie auch den <systemitem
 	      class="username">host/</systemitem>-Prinzipal ändern und
-	    die <filename>keytab</filename> aktualisieren.  Dies
-	    betrifft auch spezielle Einträge wie den Prinzipal für
+	    die keytab aktualisieren.  Dies
+	    betrifft auch spezielle Einträge wie den <systemitem
+	      class="username">HTTP/</systemitem>-Prinzipal für
 	    Apaches <package>www/mod_auth_kerb</package>.</para>
 	</listitem>
 
@@ -1722,51 +1738,37 @@ kadmind5_server_enable="YES"</programlis
 	</listitem>
 
 	<listitem>
-	  <para>Mit einem Packet-Sniffer können Sie feststellen,
-	    dass Sie sofort nach dem Aufruf von <command>kinit</command>
-	    eine Antwort vom <acronym>KDC</acronym>
-	    bekommen &ndash; noch bevor Sie überhaupt ein
-	    Passwort eingegeben haben!  Das ist in Ordnung:
-	    Das <acronym>KDC</acronym> händigt
-	    ein Ticket-Granting-Ticket (<acronym>TGT</acronym>)
-	    auf Anfrage aus, da es durch einen vom Passwort
-	    des Benutzers abgeleiteten Schlüssel
-	    geschützt ist.  Wenn das Passwort
+	  <para>Mit einem Packet-Sniffer können Sie feststellen, dass
+	    Sie sofort nach dem Aufruf von <command>kinit</command>
+	    eine Antwort vom <acronym>KDC</acronym> bekommen &ndash;
+	    noch bevor Sie überhaupt ein Passwort eingegeben haben!
+	    Das ist in Ordnung: Das <acronym>KDC</acronym> händigt ein
+	    Ticket-Granting-Ticket (<acronym>TGT</acronym>) auf
+	    Anfrage aus, da es durch einen vom Passwort des Benutzers
+	    abgeleiteten Schlüssel geschützt ist.  Wenn das Passwort
 	    eingegeben wird, wird es nicht zum <acronym>KDC</acronym>
-	    gesendet, sondern zum Entschlüsseln der
-	    Antwort des <acronym>KDC</acronym>s benutzt, die
-	    <command>kinit</command> schon erhalten hat.
-	    Wird die Antwort erfolgreich entschlüsselt,
-	    erhält der Benutzer einen Sitzungs-Schlüssel
-	    für die künftige verschlüsselte
+	    gesendet, sondern zum Entschlüsseln der Antwort des
+	    <acronym>KDC</acronym>s benutzt, die
+	    <command>kinit</command> schon erhalten hat.  Wird die
+	    Antwort erfolgreich entschlüsselt, erhält der Benutzer
+	    einen Sitzungs-Schlüssel für die künftige verschlüsselte
 	    Kommunikation mit dem <acronym>KDC</acronym> und das
 	    <acronym>TGT</acronym>.  Das <acronym>TGT</acronym>
 	    wiederum ist mit dem Schlüssel des <acronym>KDC</acronym>s
-	    verschlüsselt.  Diese Verschlüsselung ist
-	    für den Benutzer völlig transparent und
-	    erlaubt dem <acronym>KDC</acronym>,
-	    die Echtheit jedes einzelnen <acronym>TGT</acronym>
-	    zu prüfen.</para>
-	</listitem>
-
-	<listitem>
-	  <para>Wenn Sie <application>OpenSSH</application> verwenden
-	    und Tickets mir einer langen Gültigkeit benutzen, setzen
-	    Sie <option>TicketCleanup</option> in
-	    <filename>/etc/ssh/sshd_config</filename> auf
-	    <literal>no</literal>.  Ansonsten werden die Tickets
-	    gelöscht, wenn Sie sich abmelden.</para>
+	    verschlüsselt.  Diese Verschlüsselung ist für den Benutzer
+	    völlig transparent und erlaubt dem <acronym>KDC</acronym>,
+	    die Echtheit jedes einzelnen <acronym>TGT</acronym> zu
+	    prüfen.</para>
 	</listitem>
 
 	<listitem>
-	  <para>Host-Prinzipale können Tickets mit
-	    längerer Gültigkeit besitzen.  Wenn der
-	    Prinzipal eines Benutzers über ein Ticket verfügt,
-	    das eine Woche gültig ist, das Ticket des
+	  <para>Host-Prinzipale können Tickets mit längerer Gültigkeit
+	    besitzen.  Wenn der Prinzipal eines Benutzers über ein
+	    Ticket verfügt, das eine Woche gültig ist, das Ticket des
 	    Host-Prinzipals aber nur neun Stunden gültig ist,
-	    funktioniert der Ticket-Cache nicht wie erwartet.
-	    Im Cache befindet sich dann ein abgelaufenes Ticket
-	    des Host-Prinzipals.</para>
+	    funktioniert der Ticket-Cache nicht wie erwartet.  Im 
+	    Cache befindet sich dann ein abgelaufenes Ticket des
+	    Host-Prinzipals.</para>
 	</listitem>
 
 	<listitem>
@@ -1803,22 +1805,6 @@ kadmind5_server_enable="YES"</programlis
 	erlauben, da <acronym>POP3</acronym> Passwörter im Klartext
 	versendet.</para>
 
-      <para><application>Kerberos</application> ist für
-	Einbenutzer-Systeme gedacht.  In Mehrbenutzer-Umgebungen ist
-	<application>Kerberos</application> unsicherer als in
-	Einbenutzer-Umgebungen, da die Tickets im für alle
-	lesbaren Verzeichnis <filename>/tmp</filename> gespeichert
-	werden.  Wenn ein Rechner von mehreren Benutzern verwendet
-	wird, ist es möglich, dass Tickets von einem anderen Benutzer
-	gestohlen oder kopiert werden.</para>
-
-      <para>Dieses Problem können Sie lösen, indem Sie mit
-	<command>kinit -c</command> oder besser mit der
-	Umgebungsvariablen <envar>KRB5CCNAME</envar> einen Ort für die
-	Tickets vorgeben.  Es reicht, die Tickets im Heimatverzeichnis
-	eines Benutzers zu speichern und mit Zugriffsrechten zu
-	schützen.</para>
-
       <para>Das <acronym>KDC</acronym> ist verwundbar und muss daher
 	genauso abgesichert werden, wie die auf ihm befindliche
 	Passwort-Datenbank.  Auf dem <acronym>KDC</acronym> sollten
@@ -1883,7 +1869,7 @@ kadmind5_server_enable="YES"</programlis
 	</listitem>
 
 	<listitem>
-	  <para><link xlink:href="http://www.ietf.org/rfc/rfc1510.txt?number=1510">RFC 1510,
+	  <para><link xlink:href="http://www.ietf.org/rfc/rfc4120.txt?number=4120">RFC 4120,
 	    The <application>Kerberos</application> Network
 	    Authentication Service (V5)</link></para>
 	</listitem>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201606181338.u5IDcNwG062307>