Kerberos ist ein Netzwerk-Authentifizierungsprotokoll, das ursprünglich am Massachusetts Institute of Technology (MIT) entwickelt wurde. Es bietet die Möglichkeit zur sicheren Authentifizierung über ein potentiell unsicheres Netzwerk. Das Kerberos-Protokoll benutzt eine starke Kryptographie, um die Identität von Clients und Servern nachweisen zu können. Dabei werden keine unverschlüsselten Daten über das Netzewrk gesendet. Kerberos kann als eine Art Proxy zur Identitätsprüfung, oder als vertrauenswürdiges Authentifizierungssystem betrachtet werden.
Kerberos hat nur eine Aufgabe: Die sichere Prüfung der Identität eines Benutzers (Authentifizierung) über das Netzwerk. Das System überprüft weder die Berechtigungen der Benutzer (Autorisierung), noch verfolgt es die durchgeführten Aktionen (Audit). Daher sollte Kerberos zusammen mit anderen Sicherheits-Systemen eingesetzt werden, die diese Funktionen bereitstellen.
Die aktuelle Version des Protokolls ist Version 5, die in RFC 4120 beschrieben ist. Es existieren mehrere freie Implementierungen dieses Protokolls für eine Reihe von Betriebssystemen. Das MIT entwickelt auch weiterhin seine Kerberos-Version weiter. Es wird in den vereinigten Staaten als Kryptographie-Produkt eingesetzt und unterlag in der Vergangenheit US-Exportbeschränkungen. In FreeBSD ist MIT-Kerberos als Port oder Paket security/krb5 verfügbar. Die Kerberos-Implementation von Heimdal wurde außerhalb der USA entwickelt und unterliegt daher keinen Export-Beschränkungen. Heimdal-Kerberos ist im Basissystem von FreeBSD enthalten. Mit security/heimdal aus der Ports-Sammlung steht eine weitere Distribution, mit mehr konfigurierbaren Optionen zur Verfügung.
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
(Realms sind traditionell in Großbuchstaben).user
@REALM
Die folgenden Anweisungen beschreiben, wie Sie das mit FreeBSD gelieferte Heimdal-Kerberos einrichten.
Die Beschreibung der Kerberos-Installation benutzt folgende Namensräume:
Die DNS-Domain („Zone“)
heißt example.org
.
Das Kerberos-Realm
heißt EXAMPLE.ORG
.
Benutzen Sie echte Domain-Namen, wenn Sie Kerberos einrichten. Damit vermeiden Sie DNS-Probleme und stellen die Zusammenarbeit mit anderen Kerberos-Realms sicher.
Kerberos authentifiziert Benutzer an einer zentralen Stelle: dem Key Distribution Center (KDC). Das KDC verteilt Tickets, mit denen ein Dienst die Identität eines Benutzers feststellen kann. 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 wegen der Sicherheitsanforderungen auf einem separaten Rechner installiert werden.
Installieren Sie zunächst das Paket security/heimdal wie folgt:
#
pkg install heimdal
Als nächstes aktualisieren Sie
/etc/rc.conf
mittels
sysrc
:
#
sysrc kdc_enable=yes
#
sysrc kadmind_enable=yes
Danach wird /etc/krb5.conf
wie folgt bearbeitet:
[libdefaults] default_realm =EXAMPLE.ORG
[realms]EXAMPLE.ORG
= { kdc =kerberos.example.org
admin_server =kerberos.example.org
} [domain_realm].example.org
=EXAMPLE.ORG
Diese Einstellungen setzen voraus, dass der voll
qualifizierte Name des KDCs
kerberos.example.org
ist.
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
[domain_realm].example.org
=EXAMPLE.ORG
Die Zonendatei von example.org
muss dann die
folgenden Zeilen enthalten:
_kerberos._udp IN SRV 01 00 88kerberos.example.org
. _kerberos._tcp IN SRV 01 00 88kerberos.example.org
. _kpasswd._udp IN SRV 01 00 464kerberos.example.org
. _kerberos-adm._tcp IN SRV 01 00 749kerberos.example.org
. _kerberos IN TXTEXAMPLE.ORG
Damit die Clients die
Kerberos-Dienste benutzen
können, muss sie entweder eine
vollständig konfigurierte
/etc/krb5.conf
enthalten, oder eine
minimale Konfiguration und zusätzlich
ein richtig konfigurierter
DNS-Server.
Im nächsten Schritt wird die
Kerberos-Datenbank eingerichtet.
Die Datenbank enthält die Schlüssel aller Prinzipale
und ist mit einem Passwort geschützt. Dieses Passwort
brauchen Sie sich nicht merken, da ein davon abgeleiteter
Schlüssel in /var/heimdal/m-key
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:
#
kstash
Master key:Verifying password - Master key:
xxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxx
Nachdem der Schlüssel erstellt wurde, sollte die Datenbank
initialisiert werden. Das
Kerberos-Werkzeug kadmin(8)
kann die Datenbank mit kadmin -l
direkt
bearbeiten, ohne dabei den Netzwerkdienst kadmind(8) zu
benutzen. An der Eingabeaufforderung von
kadmin
kann mit init
die
Datenbank des Realms initialisiert werden:
#
kadmin -l
kadmin>init
Realm max ticket life [unlimited]:EXAMPLE.ORG
Zuletzt wird in kadmin
mit
add
das erste Prinzipal erstellt.
Benutzen Sie vorerst die voreingestellten Optionen für das
Prinzipal. Die Optionen können später mit
modify
verändert werden. An der
Eingabeaufforderung von kadmin(8) zeigt
?
die verfügbaren Optionen an.
kadmin>add tillman
Max ticket life [unlimited]: Max renewable life [unlimited]: Principal expiration time [never]: Password expiration time [never]: Attributes []: Password:Verifying password - Password:
xxxxxxxx
xxxxxxxx
Jetzt können die KDC-Dienste wie folgt gestartet werden:
#
service kdc start
#
service kadmind start
Obwohl zu diesem Zeitpunkt noch keine kerberisierten Dienste laufen, kann die Funktion des KDC schon überprüft werden, indem Sie für den eben angelegten Benutzer ein Ticket anfordern:
%
kinit
tillman@EXAMPLE.ORG's Password:tillman
Überprüfen Sie, ob das Ticket erfolgreich ausgestellt wurde:
%
klist
Credentials cache: FILE: /tmp/krb5cc_1001 Principal: tillman@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:
%
kdestroy
Bei der Konfiguration eines Servers für die
Kerberos-Authentifizierung muss
zuerst sichergestellt werden, dass
/etc/krb5.conf
richtig konfiguriert ist.
Die Datei kann entweder vom KDC kopiert,
oder auf dem neuen System generiert werden.
Als nächstes muss auf dem Server die
/etc/krb5.keytab
erzeugt werden. Dies
ist der Hauptbestandteil um Dienste zu
„kerberisieren“ und entspricht der Erzeugung
eines geheimen Schlüssels zwischen dem Dienst und dem
KDC. Das Geheimnis ist ein
kryptographischer Schlüssel, der in einem
keytab
> abgelegt wird. Diese Datei
enthält den Schlüssel des Servers, mit dem sich der Server und
das KDC gegenseitig authentifizieren
können. Sie muss in einer sicheren Art und Weise an den
Server übertragen werden, da ansonsten die Sicherheit des
Servers gefährdet ist, wenn z.B. die Schlüssel öffentlich
werden. In der Regel wird die keytab
auf
einem vertrauenswürdigen Rechner mit kadmin
erzeugt und anschließend sicher auf den Server übertragen,
beispielsweise mit scp(1). Wenn die
Sicherheitsrichtlinien es erlauben, kann die Datei auch direkt
auf dem Server erzeugt werden. Es ist sehr wichtig, dass die
keytab
auf sichere Weise auf den Server
übertragen wird. Wenn der Schlüssel einer anderen Partei
bekannt wird, kann sich diese Partei den Benutzern als
Server ausgeben! Da der Eintrag für das Host-Prinzipal für
die KDC-Datenbank auch mit
kadmin
erstellt wird, ist es praktisch,
kadmin
direkt auf dem Server zu
benutzen.
Natürlich ist auch kadmin
ein
kerberisierter Dienst: ein
Kerberos-Ticket ist erforderlich,
um sich gegenüber dem Netzwerkdienst zu authentifizieren und
um sicherzustellen, dass der Benutzer, der
kadmin
ausführt, tatsächlich vorhanden ist.
kadmin
wird nach dem Passwort fragen, um
ein neues Ticket zu generieren. Das Prinzipal, das sich mit
dem kadmin-Dienst authentifiziert, muss über die
Zugriffskontrollliste /var/heimdal/kadmin.acl
dazu
berechtigt sein. Weitere Informationen über
Zugriffskontrolllisten finden Sie in den Heimdal-Info-Seiten
(info heimdal
) im Abschnitt
„Remote administration“. Wenn der Zugriff auf
kadmin
von entfernten Rechnern verboten
ist, kann sich der Administrator entweder über die lokale
Konsole oder über ssh(1) mit dem KDC
verbinden, um die lokale Administration mit
kadmin -l
durchzuführen.
Nach der Installation von
/etc/krb5.conf
, können Sie das Kommando
add --random-key
in
kadmin
ausführen, um das Host-Prinzipal in
die Datenbank zu schreiben. Das Kommando
ext
extrahiert den Schlüssel des Prinzipals
in eine eigene keytab:
#
kadmin
kadmin>add --random-key
Max ticket life [unlimited]: Max renewable life [unlimited]: Principal expiration time [never]: Password expiration time [never]: Attributes []: kadmin>host/myserver.example.org
ext_keytab
kadmin>host/myserver.example.org
exit
Beachten Sie, dass ext_keytab
den
extrahierten Schlüssel standardmäßig in
/etc/krb5.keytab
speichert. Das ist
gut, wenn das Kommando auf dem kerberisierten Server
ausgeführt wird, ansonsten sollte das Argument
--keytab
benutzt werden, wenn die keytab an einen anderen Ort
extrahiert wird:pfad/zur/datei
#
kadmin
kadmin>ext_keytab --keytab=/tmp/example.keytab
kadmin>host/myserver.example.org
exit
Anschließend kann die erzeugte keytab sicher mit scp(1) auf Server oder auf einen Wechseldatenträger kopiert werden. Geben Sie auf jeden Fall einen anderen Namen für die keytab an, um unnötige Schlüssel in der keytab des Systems zu vermeiden.
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
können die kerberisierten Dienste aktiviert werden. Einer der
gebräuchlichsten Dienste ist sshd(8), der
Kerberos über
GSS-API unterstützt. Fügen Sie folgende
Zeile in /etc/ssh/sshd_config
ein:
GSSAPIAuthentication yes
Nach dieser Änderung muss sshd(8) mit
service sshd restart
neu gestartet werden,
damit die neue Konfiguration wirksam wird.
Genau wie der Server, benötigt auch der Client eine
Konfiguration in /etc/krb5.conf
.
Kopien Sie die Datei (sicher) vom KDC
auf den Client, oder schreiben Sie die Datei bei Bedarf
einfach neu.
Testen Sie den Client, indem Sie mit
kinit
Tickets anfordern, mit
klist
Tickets anzeigen und mit
kdestroy
Tickets löschen.
Kerberos-Anwendungen sollten auch
kerberisierte Server ansprechen können. Wenn das nicht
funktioniert, Sie aber Tickets anfordern können, hat
wahrscheinlich der kerberisierte Server ein Problem und nicht
der Client oder das KDC. Im Falle eines
kerberisierten ssh(1) ist GSS-API in
der Voreinstellung deaktiviert. Testen Sie daher mit
ssh -o GSSAPIAuthentication=yes
.hostname
Wenn Sie die kerberisierten Anwendungen testen, können Sie
einen Paket-Sniffer wie tcpdump
benutzen,
um sicherzustellen, dass keine sensiblen Informationen im
Klartext übertragen werden.
Es stehen verschiedene Kerberos-Anwendungen zur Verfügung. Die Anwendungen, die SASL benutzen, können dann auch GSS-API benutzen. Viele Arten von Anwendungen können Kerberos zur Authentifizierung verwenden, vom Jabber-Client bis zum IMAP-Client.
Normalerweise wird ein
Kerberos-Prinzipal auf ein lokales
Benutzerkonto abgebildet. Manchmal wird aber Zugriff auf ein
lokales Benutzerkonto benötigt, zu dem es keinen passenden
Kerberos-Prinzipal gibt.
Der Prinzipal tillman@EXAMPLE.ORG
bräuchte
beispielsweise Zugriff auf das Konto webdevelopers
. Ebenso könnten
andere Prinzipale auf dieses Konto zugreifen wollen.
Die Dateien .k5login
und
.k5users
im Heimatverzeichnis eines
Benutzers können verwendet werden, um dieses Problem zu lösen.
Mit der folgenden .k5login
im
Heimatverzeichnis des Benutzers webdevelopers
haben beide
Prinzipale auch ohne das gemeinsame Passwort Zugriff auf das
Konto:
tillmann@example.org jdoe@example.org
Weitere Informationen zu .k5users
finden Sie in ksu(1).
Der Hauptunterschied zwischen der MIT-
und der Heimdal-Implementation ist das Kommando
kadmin
. Die Befehlssätze des Kommandos
(obwohl funktional gleichwertig) und das verwendete Protokoll
unterscheiden sich in beiden Varianten. Das
KDC lässt sich nur mit dem
kadmin
Kommando der passenden
Kerberos-Variante verwalten.
Für dieselbe Funktion können auch die
Client-Anwendungen leicht geänderte Kommandozeilenoptionen
besitzen. Folgen Sie der Anleitung auf
http://web.mit.edu/Kerberos/www/
. Achten Sie
besonders auf den Suchpfad für Anwendungen. Der
MIT-Port wird unter FreeBSD standardmäßig in
/usr/local/
installiert. Wenn die
Umgebungsvariable PATH
zuerst die
Systemverzeichnisse enthält, werden die Systemprogramme
anstelle der MIT-Programme
ausgeführt.
Wenn Sie
MIT-Kerberos
verwenden, sollten Sie außerdem folgende Änderungen an
/etc/rc.conf
vornehmen:
kdc_program="/usr/local/sbin/kdc" kadmind_program="/usr/local/sbin/kadmind" kdc_flags="" kdc_enable="YES" kadmind_enable="YES"
Während der Konfiguration und bei der Fehlersuche sollten die folgenden Punkte beachtet werden:
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. Abschnitt 29.11, „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 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
/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.
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
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.
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 krb5.dict
die
Verwendung schlechter Passwörter verhindern wollen, wie
in kadmin(8) beschrieben, geht das nur mit
Prinzipalen, denen eine Passwort-Policy zugewiesen wurde.
Das Format von krb5.dict
enthält pro
Zeile ein Wort. Sie können daher einen symbolischen Link
auf /usr/share/dict/words
erstellen.
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.
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.
Wenn das KDC nicht zur Verfügung steht, sind auch die Netzwerkdienste nicht benutzbar, da eine Authentifizierung nicht durchgeführt werden kann. Das KDC ist also ein optimales Ziel für einen Denial-of-Service Angriff. Sie können diesem Angriff entgegenwirken, indem Sie einen KDC-Master und einen oder mehrere Slaves verwenden. Der Rückfall auf ein sekundäres KDC mittels PAM-Authentifizierung muss sorgfältig eingerichtet werden.
Mit Kerberos können sich
Benutzer, Rechner und Dienste gegenseitig authentifizieren.
Allerdings existiert kein Mechanismus, der das
KDC gegenüber Benutzern, Rechnern oder
Diensten authentifiziert. Ein verändertes
kinit
könnte beispielsweise alle
Benutzernamen und Passwörter abfangen. Die von veränderten
Programmen ausgehende Gefahr können Sie lindern, indem Sie die
Integrität von Dateien mit Werkzeugen wie
security/tripwire prüfen.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.