From owner-svn-doc-all@freebsd.org Sat Jun 18 13:38:24 2016 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EB1FA7801C; Sat, 18 Jun 2016 13:38:24 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A24C2C88; Sat, 18 Jun 2016 13:38:23 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u5IDcNOQ062308; Sat, 18 Jun 2016 13:38:23 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u5IDcNwG062307; Sat, 18 Jun 2016 13:38:23 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201606181338.u5IDcNwG062307@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Sat, 18 Jun 2016 13:38:23 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2016 13:38:24 -0000 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 --> Sicherheit @@ -188,9 +188,9 @@ Fragen Sie im Zweifelsfall das Sicherheitspersonal. 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. @@ -465,9 +465,9 @@ Enter new password: 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: - security/rkhunter. + dazu, sehr gut versteckt zu sein. Dieser Abschnitt zeigt das + Werkzeug security/rkhunter, mit dem + Rootkits erkannt werden können. 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: läuft, für die er verantwortlich ist. Werkzeuge von Drittanbietern, wie rkhunter oder sysutils/lsof, sowie native Befehle wie - netstat oder - ps, können eine große Menge an - Informationen über das System anzeigen. Machen Sie sich - Notizen darüber, was normal 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. + netstat oder ps, können + eine große Menge an Informationen über das System anzeigen. + Machen Sie sich Notizen darüber, was normal + 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. @@ -1244,6 +1243,14 @@ sendmail : PARANOID : deny + Unter Kerberos werden Benutzer + und Dienste als Prinzipale bezeichnet, die + innerhalb einer administrativen Domäne, dem sogenannten + Realm enthalten sind. Ein typisches + Benutzer-Prinzipal hätte das Format + user@REALM + (Realms sind traditionell in Großbuchstaben). + Die folgenden Anweisungen beschreiben, wie Sie das mit &os; gelieferte Heimdal-Kerberos einrichten. @@ -1286,10 +1293,12 @@ sendmail : PARANOID : denyKDC). Das KDC verteilt Tickets, mit denen ein Dienst die Identität eines Benutzers feststellen kann. - Alle Mitglieder eines Kerberos-Realms - vertrauen dem KDC, daher gelten für - das KDC erhöhte - Sicherheitsanforderungen. + Weil alle Mitglieder eines + Kerberos-Realms dem + KDC vertrauen, gelten für das + KDC erhöhte Sicherheitsanforderungen. + Der direkte Zugriff auf das KDC sollte + daher eingeschränkt sein. Obwohl der Kerberos-Server wenig Ressourcen benötigt, sollte das KDC @@ -1299,8 +1308,8 @@ sendmail : PARANOID : denyDas KDC wird in /etc/rc.conf wie folgt aktiviert: - kerberos5_server_enable="YES" -kadmind5_server_enable="YES" + kdc_enable="YES" +kadmind_enable="YES" Danach wird /etc/krb5.conf wie folgt bearbeitet: @@ -1319,20 +1328,21 @@ kadmind5_server_enable="YES"KDCs kerberos.example.org ist. - Wenn das KDC einen anderen Namen hat, - muss in der DNS-Zone ein Alias-Eintrag - (CNAME-Record) für das - KDC hinzugefügt werden. + Der Rechnername des KDC muss im + DNS auflösbar sein. In großen Netzwerken mit einem ordentlich konfigurierten DNS-Server kann die Datei aus dem obigen Beispiel verkürzt werden: [libdefaults] - default_realm = EXAMPLE.ORG + default_realm = EXAMPLE.ORG +[domain_realm] + .example.org = EXAMPLE.ORG - Die Zonendatei von example.org - muss dann die folgenden Zeilen enthalten: + Die Zonendatei von example.org muss dann + die folgenden Zeilen enthalten: _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. @@ -1343,7 +1353,7 @@ _kerberos IN TXT Damit die Clients die Kerberos-Dienste benutzen - können, muss das KDC entweder eine + können, muss sie entweder eine vollständig konfigurierte /etc/krb5.conf enthalten, oder eine minimale Konfiguration und zusätzlich @@ -1357,22 +1367,23 @@ _kerberos IN TXT /var/heimdal/m-key - gespeichert wird. Um den Schlüssel zu erstellen, rufen Sie - kstash auf und geben Sie ein Passwort - ein: + 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 kstash + auf und geben Sie ein Passwort ein: &prompt.root; kstash -Master key: xxxxxxxx -Verifying password - Master key: xxxxxxxx +Master key: xxxxxxxxxxxxxxxxxxxxxxx +Verifying password - Master key: xxxxxxxxxxxxxxxxxxxxxxx - Nachdem der Schlüssel erstellt wurde, intitialisieren Sie - die Datenbank mit kadmin -l. Die Option - weist kadmin 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 kadmin kann - mit init die Datenbank des Realms - initialisiert werden: + Nachdem der Schlüssel erstellt wurde, sollte die Datenbank + initialisiert werden. Das + Kerberos-Werkzeug &man.kadmin.8; + kann die Datenbank mit kadmin -l direkt + bearbeiten, ohne dabei den Netzwerkdienst &man.kadmind.8; zu + benutzen. An der Eingabeaufforderung von + kadmin kann mit init die + Datenbank des Realms initialisiert werden: &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG @@ -1393,23 +1404,25 @@ Password: xxxxxx Verifying password - Password: xxxxxxxx Jetzt können die KDC-Dienste mit - service kerberos start und + service kdc start und service kadmind start gestartet werden. Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste laufen, kann die Funktion des KDCs - schon überprüft werden. Für den eben angelegten - Benutzer können Sie sich vom KDC - Tickets holen und anzeigen lassen: + schon überprüft werden, indem Sie für den eben angelegten + Benutzer ein Ticket anfordern: &prompt.user; kinit tillman -tillman@EXAMPLE.ORG's Password: +tillman@EXAMPLE.ORG's Password: + + Überprüfen Sie, ob das Ticket erfolgreich ausgestellt + wurde: -&prompt.user; klist -Credentials cache: FILE: /tmp/krb5cc_500 + &prompt.user; klist +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 + Issued Expires Principal +Aug 27 15:37:58 2013 Aug 28 01:37:58 2013 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG Nachdem der Test abgeschlossen ist, kann das temporäre Ticket zurückgezogen werden: @@ -1431,7 +1444,7 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt zuerst sichergestellt werden, dass /etc/krb5.conf richtig konfiguriert ist. Die Datei kann entweder vom KDC kopiert, - oder auf dem neuen System regeneriert werden. + oder auf dem neuen System generiert werden. Als nächstes muss auf dem Server die /etc/krb5.keytab erzeugt werden. Dies @@ -1493,6 +1506,8 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: +Principal expiration time [never]: +Password expiration time [never]: Attributes []: kadmin> ext_keytab host/myserver.example.org kadmin> exit @@ -1514,10 +1529,10 @@ kadmin> exitAnschließ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 KDCs überschrieben würde. + einen anderen Namen für die keytab an, um unnötige Schlüssel + in der keytab des Systems zu vermeiden. - Wegen der Datei krb5.conf kann + Mit Hilfe der Datei krb5.conf kann der Server nun mit dem KDC kommunizieren und seine Identität mithilfe der Datei krb5.keytab nachweisen. Jetzt @@ -1676,8 +1691,9 @@ kadmind5_server_enable="YES"Wenn Sie den Namen eines Rechners ändern, müssen Sie auch den host/-Prinzipal ändern und - die keytab aktualisieren. Dies - betrifft auch spezielle Einträge wie den Prinzipal für + die keytab aktualisieren. Dies + betrifft auch spezielle Einträge wie den HTTP/-Prinzipal für Apaches www/mod_auth_kerb. @@ -1722,51 +1738,37 @@ kadmind5_server_enable="YES" - Mit einem Packet-Sniffer können Sie feststellen, - dass Sie sofort nach dem Aufruf von kinit - eine Antwort vom KDC - bekommen – noch bevor Sie überhaupt ein - Passwort eingegeben haben! Das ist in Ordnung: - Das KDC händigt - ein Ticket-Granting-Ticket (TGT) - auf Anfrage aus, da es durch einen vom Passwort - des Benutzers abgeleiteten Schlüssel - geschützt ist. Wenn das Passwort + Mit einem Packet-Sniffer können Sie feststellen, dass + Sie sofort nach dem Aufruf von kinit + eine Antwort vom KDC bekommen – + noch bevor Sie überhaupt ein Passwort eingegeben haben! + Das ist in Ordnung: Das KDC händigt ein + Ticket-Granting-Ticket (TGT) 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 KDC - gesendet, sondern zum Entschlüsseln der - Antwort des KDCs benutzt, die - kinit 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 + KDCs benutzt, die + kinit 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 KDC und das TGT. Das TGT wiederum ist mit dem Schlüssel des KDCs - verschlüsselt. Diese Verschlüsselung ist - für den Benutzer völlig transparent und - erlaubt dem KDC, - die Echtheit jedes einzelnen TGT - zu prüfen. - - - - Wenn Sie OpenSSH verwenden - und Tickets mir einer langen Gültigkeit benutzen, setzen - Sie in - /etc/ssh/sshd_config auf - no. Ansonsten werden die Tickets - gelöscht, wenn Sie sich abmelden. + verschlüsselt. Diese Verschlüsselung ist für den Benutzer + völlig transparent und erlaubt dem KDC, + die Echtheit jedes einzelnen TGT zu + prüfen. - 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-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. + funktioniert der Ticket-Cache nicht wie erwartet. Im + Cache befindet sich dann ein abgelaufenes Ticket des + Host-Prinzipals. @@ -1803,22 +1805,6 @@ kadmind5_server_enable="YES"POP3 Passwörter im Klartext versendet. - Kerberos ist für - Einbenutzer-Systeme gedacht. In Mehrbenutzer-Umgebungen ist - Kerberos unsicherer als in - Einbenutzer-Umgebungen, da die Tickets im für alle - lesbaren Verzeichnis /tmp gespeichert - werden. Wenn ein Rechner von mehreren Benutzern verwendet - wird, ist es möglich, dass Tickets von einem anderen Benutzer - gestohlen oder kopiert werden. - - Dieses Problem können Sie lösen, indem Sie mit - kinit -c oder besser mit der - Umgebungsvariablen KRB5CCNAME einen Ort für die - Tickets vorgeben. Es reicht, die Tickets im Heimatverzeichnis - eines Benutzers zu speichern und mit Zugriffsrechten zu - schützen. - Das KDC ist verwundbar und muss daher genauso abgesichert werden, wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC sollten @@ -1883,7 +1869,7 @@ kadmind5_server_enable="YES" - RFC 1510, + RFC 4120, The Kerberos Network Authentication Service (V5)