Changeset View
Changeset View
Standalone View
Standalone View
documentation/content/de/books/handbook/security/_index.adoc
Show First 20 Lines • Show All 817 Lines • ▼ Show 20 Lines | |||||
* Wenn Sie Heimdal- oder MIT-Kerberos benutzen, muss in der Umgebungsvariable `PATH` der Pfad zu den Kerberos-Programmen vor dem Pfad zu den Programmen des Systems stehen. | * Wenn Sie Heimdal- oder MIT-Kerberos benutzen, muss in der Umgebungsvariable `PATH` der Pfad zu den Kerberos-Programmen vor dem Pfad zu den Programmen des Systems stehen. | ||||
* Wenn die Clients im Realm ihre Uhrzeit nicht synchronisieren, schlägt vielleicht die Authentifizierung fehl. crossref:network-servers[network-ntp,“Die Uhrzeit mit NTP synchronisieren”] beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren. | * Wenn die Clients im Realm ihre Uhrzeit nicht synchronisieren, schlägt vielleicht die Authentifizierung fehl. crossref:network-servers[network-ntp,“Die Uhrzeit mit NTP synchronisieren”] beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren. | ||||
* 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 `HTTP/`-Prinzipal für Apaches package:www/mod_auth_kerb[]. | * 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 `HTTP/`-Prinzipal für Apaches package:www/mod_auth_kerb[]. | ||||
* Alle Rechner in einem Realm müssen vor- und rückwärts aufgelöst werden können. Entweder über DNS, zumindest aber über [.filename]#/etc/hosts#. CNAME-Einträge im DNS funktionieren, aber die entsprechenden A- und PTR-Einträge müssen vorhanden und richtig sein. Wenn sich Namen nicht auflösen lassen, ist die Fehlermeldung nicht gerade selbstsprechend: `Kerberos5 refuses authentication because Read req failed: Key table entry not found`. | * Alle Rechner in einem Realm müssen vor- und rückwärts aufgelöst werden können. Entweder über DNS, zumindest aber über [.filename]#/etc/hosts#. CNAME-Einträge im DNS funktionieren, aber die entsprechenden A- und PTR-Einträge müssen vorhanden und richtig sein. Wenn sich Namen nicht auflösen lassen, ist die Fehlermeldung nicht gerade selbstsprechend: `Kerberos5 refuses authentication because Read req failed: Key table entry not found`. | ||||
* Einige Betriebssysteme installieren `ksu` mit falschen Zugriffsrechten; es fehlt das Set-UID-Bit für `root`. Das hat zur Folge, dass `ksu` nicht funktioniert. Dies ist ein Fehler in den Zugriffsrechten und kein Fehler des KDCs. | * Einige Betriebssysteme installieren `ksu` mit falschen Zugriffsrechten; es fehlt das Set-UID-Bit für `root`. Das hat zur Folge, dass `ksu` nicht funktioniert. Dies ist ein Fehler in den Zugriffsrechten und kein Fehler des KDCs. | ||||
* Wenn Sie für einen Prinzipal unter MIT-Kerberos Tickets mit einer längeren Gültigkeit als der vorgegebenen zehn Stunden einrichten wollen, müssen Sie zwei Sachen ändern. Benutzen Sie `modify_principal` am Prompt von man:kadmin[8], um die maximale Gültigkeitsdauer für den Prinzipal selbst und den Prinzipal `krbtgt` zu erhöhen. Das Prinzipal kann dann mit `kinit -l` ein Ticket mit einer längeren Gültigkeit beantragen. | * Wenn Sie für einen Prinzipal unter MIT-Kerberos Tickets mit einer längeren Gültigkeit als der vorgegebenen zehn Stunden einrichten wollen, müssen Sie zwei Sachen ändern. Benutzen Sie `modify_principal` am Prompt von man:kadmin[8], um die maximale Gültigkeitsdauer für den Prinzipal selbst und den Prinzipal `krbtgt` zu erhöhen. Das Prinzipal kann dann mit `kinit -l` ein Ticket mit einer längeren Gültigkeit beantragen. | ||||
* 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 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. | * 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 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. | ||||
* 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. | * 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. | ||||
* Wenn Sie mit [.filename]#krb5.dict# die Verwendung schlechter Passwörter verhindern wollen, wie in man:kadmin[8] beschrieben, geht das nur mit Prinzipalen, denen eine Passwort-Policy zugewiesen wurde. Das Format von [.filename]#krb5.dict# enthält pro Zeile ein Wort. Sie können daher einen symbolischen Link auf [.filename]#/usr/shared/dict/words# erstellen. | * Wenn Sie mit [.filename]#krb5.dict# die Verwendung schlechter Passwörter verhindern wollen, wie in man:kadmin[8] beschrieben, geht das nur mit Prinzipalen, denen eine Passwort-Policy zugewiesen wurde. Das Format von [.filename]#krb5.dict# enthält pro Zeile ein Wort. Sie können daher einen symbolischen Link auf [.filename]#/usr/share/dict/words# erstellen. | ||||
=== Beschränkungen von Kerberos | === Beschränkungen von Kerberos | ||||
Kerberos muss ganzheitlich verwendet werden. Jeder über das Netzwerk angebotene Dienst muss mit Kerberos zusammenarbeiten oder auf anderen Wegen gegen Angriffe aus dem Netzwerk geschützt sein. Andernfalls können Berechtigungen gestohlen und wiederverwendet werden. Es ist beispielsweise nicht sinnvoll, für Remote-Shells Kerberos zu benutzen, dagegen aber POP3-Zugriff auf einem Mail-Server zu erlauben, da POP3 Passwörter im Klartext versendet. | Kerberos muss ganzheitlich verwendet werden. Jeder über das Netzwerk angebotene Dienst muss mit Kerberos zusammenarbeiten oder auf anderen Wegen gegen Angriffe aus dem Netzwerk geschützt sein. Andernfalls können Berechtigungen gestohlen und wiederverwendet werden. Es ist beispielsweise nicht sinnvoll, für Remote-Shells Kerberos zu benutzen, dagegen aber POP3-Zugriff auf einem Mail-Server zu erlauben, da POP3 Passwörter im Klartext versendet. | ||||
Das KDC ist verwundbar und muss daher genauso abgesichert werden, wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC sollten absolut keine anderen Dienste laufen und der Rechner sollte physikalisch gesichert sein. Die Gefahr ist groß, da Kerberos alle Passwörter mit einem Schlüssel, dem Haupt-Schlüssel, verschlüsselt. Der Haupt-Schlüssel wiederum wird in einer Datei auf dem KDC gespeichert. | Das KDC ist verwundbar und muss daher genauso abgesichert werden, wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC sollten absolut keine anderen Dienste laufen und der Rechner sollte physikalisch gesichert sein. Die Gefahr ist groß, da Kerberos alle Passwörter mit einem Schlüssel, dem Haupt-Schlüssel, verschlüsselt. Der Haupt-Schlüssel wiederum wird in einer Datei auf dem KDC gespeichert. | ||||
Ein kompromittierter Haupt-Schlüssel ist nicht ganz so schlimm wie allgemein angenommen. Der Haupt-Schlüssel wird nur zum Verschlüsseln der Passwort-Datenbank und zum Initialisieren des Zufallsgenerators verwendet. Solange der Zugriff auf das KDC abgesichert ist, kann ein Angreifer wenig mit dem Haupt-Schlüssel anfangen. | Ein kompromittierter Haupt-Schlüssel ist nicht ganz so schlimm wie allgemein angenommen. Der Haupt-Schlüssel wird nur zum Verschlüsseln der Passwort-Datenbank und zum Initialisieren des Zufallsgenerators verwendet. Solange der Zugriff auf das KDC abgesichert ist, kann ein Angreifer wenig mit dem Haupt-Schlüssel anfangen. | ||||
▲ Show 20 Lines • Show All 1,295 Lines • Show Last 20 Lines |