Kerberos ist ein Netzwerk-Protokoll, das Benutzer mithilfe eines sicheren Servers authentifiziert. Mit Risiken behaftete Dienste, wie das Anmelden an entfernten Systemen oder das Kopieren von Daten auf entfernte Systeme, werden durch Kerberos erheblich sicherer und lassen sich leichter steuern.
Kerberos hat 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 Daten einer Kommunikation können verschlüsselt werden, nachdem die Kommunikationspartner mit Kerberos ihre Identität geprüft haben.
Die folgenden Anweisungen beschreiben, wie Sie das mit FreeBSD gelieferte Kerberos einrichten. Eine vollständige Beschreibung des Systems entnehmen Sie bitte den entsprechenden Hilfeseiten.
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.
Das MIT entwickelte Kerberos, um Sicherheitsprobleme auf dem Netzwerk zu lösen. Das Kerberos-Protokoll verwendet starke Kryptographie, sodass ein Server die Identität eines Clients (der umgekehrte Vorgang ist auch möglich) über ein unsicheres Netzwerk feststellen kann.
Der Begriff Kerberos wird sowohl für das Protokoll als auch für Programme verwendet, die Kerberos benutzen (wie Kerberos-Telnet). Die aktuelle Protokollversion ist 5 und wird in RFC 1510 beschrieben.
Mehrere Implementierungen des Protokolls stehen frei
zur Verfügung und decken viele Betriebssysteme ab.
Das Massachusetts Institute of Technology
(MIT), an dem Kerberos
ursprünglich entwickelt wurde, entwickelt seine
Kerberos-Version weiter. In den
USA wird diese Version häufig
eingesetzt, unterlag aber Export-Beschränkungen,
da sie in den USA entwickelt wurde.
Die MIT-Version von
Kerberos befindet sich im Port
security/krb5
.
Heimdal ist eine weitere Implementierung der Protokollversion 5.
Sie wurde außerhalb der USA entwickelt
und unterliegt daher keinen Export-Beschränkungen.
Heimdal-Kerberos befindet sich
im Port security/heimdal
und das Basissystem von FreeBSD enthält eine minimale
Installation von Heimdal.
Um möglichst viele Benutzer anzusprechen, verwenden die folgenden Beispiele die in FreeBSD enthaltene Heimdal-Distribution.
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. Alle Mitglieder eines Kerberos-Realms vertrauen dem KDC, daher gelten für das KDC erhöhte Sicherheitsanforderungen.
Obwohl das KDC wenig Ressourcen eines Rechners benötigt, sollte es wegen der Sicherheitsanforderungen auf einem separaten Rechner installiert werden.
Das KDC wird in
/etc/rc.conf
wie folgt aktiviert:
Danach wird die Konfigurationsdatei von
Kerberos,
/etc/krb5.conf
, erstellt:
Diese Einstellungen setzen voraus, dass der voll
qualifizierte Name des KDCs
kerberos.example.org
ist.
Wenn Ihr KDC einen anderen Namen hat,
müssen Sie in der DNS-Zone einen Alias-Eintrag (CNAME-Record)
für das KDC hinzufügen.
Auf großen Netzwerken mit einem ordentlich konfigurierten BIND DNS-Server kann die Datei verkürzt werden:
Die Zonendatei von example.org
muss dann die folgenden Zeilen enthalten:
Damit Klienten die
Kerberos-Dienste benutzen
können, muss die Datei /etc/krb5.conf
entweder die vollständige Konfiguration enthalten
oder eine minimale Konfiguration enthalten
und zusätzlich ein DNS-Server
richtig eingerichtet sein.
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 nicht zu behalten, da ein davon abgeleiteter
Schlüssel in der Datei /var/heimdal/m-key
gespeichert wird. Den Schlüssel erstellen Sie, indem
Sie das Programm kstash
aufrufen und
ein Passwort eingeben.
Nachdem Sie den Schlüssel in
/var/heimdal/m-key
erstellt haben,
können Sie die Datenbank mit dem Kommando
kadmin
initialisieren. Verwenden
Sie hierbei die Option -l
(lokal). Mit
dieser Option wird die Datenbank lokal modifiziert. Normal
würde der kadmind
-Dienst benutzt,
der aber zu diesem Zeitpunkt noch nicht läuft. An
der Eingabeaufforderung von kadmin
können Sie mit dem Kommando init
die Datenbank des Realms einrichten.
Zuletzt erstellen Sie mit dem Kommando add
Ihren ersten Prinzipal. Benutzen Sie die voreingestellten
Optionen; Sie können die Einstellungen später
mit dem Kommando modify
ändern.
An der Eingabeaufforderung zeigt das Kommando
?
Hilfetexte an.
Zusammengefasst wird die Datenbank wie folgt eingerichtet:
#
kstash
Master key: xxxxxxxx
Verifying password - Master key: xxxxxxxx
#
kadmin -l
kadmin> init EXAMPLE.ORG
Realm max ticket life [unlimited]:
kadmin> add tillman
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
Password: xxxxxxxx
Verifying password - Password: xxxxxxxx
Jetzt kann das KDC gestartet werden.
Führen Sie zum Start der Dienste die Kommandos
/etc/rc.d/kerberos start
und
/etc/rc.d/kadmind start
aus. Obwohl
zu diesem Zeitpunkt noch keine kerberisierten Dienste
laufen, können Sie die Funktion des KDCs
schon überprüfen. Für den eben angelegten
Benutzer können Sie sich vom KDC
Tickets holen und diese Tickets anzeigen:
%
kinit tillman
tillman@EXAMPLE.ORG's Password:
%
klist
Credentials cache: FILE: /tmp/krb5cc_500
Principal: tillman@EXAMPLE.ORG
Issued Expires Principal
Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORGDieses Ticket kann, nachdem Sie Ihre Arbeit beendet haben, zurückgezogen werden:
%
kdestroy
Alle Rechner, die kerberisierte Dienste anbieten,
müssen eine Kopie der
Kerberos-Konfigurationsdatei
/etc/krb5.conf
besitzen. Sie
können die Datei einfach vom KDC
kopieren.
Anschließend müssen Sie die Datei
/etc/krb5.keytab
erzeugen. Im
Gegensatz zu normalen Workstations benötigt jeder
Server eine keytab
.
Diese Datei enthält den Schlüssel des
Servers, mit dem sich der Server und das
KDC gegenseitig authentifizieren
können. Die Datei muss sicher auf den Server
transportiert werden (beispielsweise mit scp(1)
oder einer Diskette). Unter keinen Umständen
darf die Datei im Klartext, zum Beispiel mit
FTP, übertragen werden,
da sonst die Sicherheit des Servers gefährdet
ist.
Sie können die keytab
auch
mit dem Programm kadmin
übertragen.
Da Sie mit kadmin
sowieso einen Host-Prinzipal
für den Server einrichten müssen, ist das ganz
praktisch.
Sie müssen allerdings schon ein Ticket
besitzen und berechtigt sein, kadmin
auszuführen. Die Berechtigung erhalten Sie durch
einen Eintrag in der Zugriffskontrollliste
kadmind.acl
. Weitere Informationen
über Zugriffskontrolllisten erhalten Sie in den
Heimdal-Info-Seiten (info heimdal
)
im Abschnitt „Remote administration“. Wenn
der Zugriff auf kadmin
von entfernten
Maschinen verboten ist, müssen Sie sich sicher
auf dem KDC anmelden (lokale Konsole,
ssh(1) oder kerberisiertes Telnet) und die
keytab
lokal mit
kadmin -l
erzeugen.
Nachdem Sie die Datei /etc/krb5.conf
installiert haben, können Sie das Kommando
kadmin
benutzen. An der Eingabeaufforderung
von kadmin
erstellt das Kommando
add --random-key
den Host-Prinzipal
und das Kommando ext
extrahiert den
Schlüssel des Prinzipals in eine Datei:
#
kadmin
kadmin> add --random-key host/myserver.example.org
Max ticket life [unlimited]:
Max renewable life [unlimited]:
Attributes []:
kadmin> ext host/myserver.example.org
kadmin> exit
Das Kommando ext
(von
extract) speichert den
extrahierten Schlüssel in der Datei
/etc/krb5.keytab
.
Wenn auf dem KDC, vielleicht aus
Sicherheitsgründen, kadmind
nicht läuft, können Sie das Kommando
kadmin
von entfernten Rechnern nicht
benutzen. In diesem Fall legen Sie den Host-Prinzipal
host/myserver.EXAMPLE.ORG
direkt
auf dem KDC an. Den Schlüssel
extrahieren Sie in eine temporäre Datei (damit
die Datei /etc/krb5.keytab
nicht
überschrieben wird):
#
kadmin
kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org
kadmin> exit
Anschließend müssen Sie die erzeugte
example.keytab
sicher auf den
Server kopieren (mit scp
oder
mithilfe einer Diskette). Geben Sie auf jeden Fall
einen anderen Namen für die keytab
an, weil sonst die keytab
des
KDCs überschrieben würde.
Wegen 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 wir kerberisierte Dienste aktivieren.
Für telnet
muss die folgende
Zeile in /etc/inetd.conf
eingefügt
werden:
Ausschlaggebend ist, dass die Authentifizierungs-Methode
mit -a
auf user
gesetzt
wird. Weitere Details entnehmen Sie bitte der Hilfeseite
telnetd(8).
Nachdem sie die Zeile in /etc/inetd.conf
eingefügt haben, starten Sie inetd(8) mit
dem Kommando /etc/rc.d/inetd restart
durch.
Ein Client lässt sich leicht einrichten.
Sie benötigen nur die
Kerberos-Konfigurationsdatei
/etc/krb5.conf
. Kopieren Sie
die Konfigurationsdatei einfach vom KDC
auf den Client.
Sie können jetzt mit kinit
Tickets anfordern, mit klist
Tickets
anzeigen und mit kdestroy
Tickets
löschen. Sie können mit
Kerberos-Anwendungen kerberisierte
Server ansprechen. Wenn das nicht funktioniert,
Sie aber Tickets anfordern können, hat wahrscheinlich
der kerberisierte Server ein Problem und nicht der
Client oder das KDC.
Wenn Sie eine Anwendung wie telnet
testen, können Sie mit einem Paket-Sniffer
(beispielsweise tcpdump(1)) überprüfen,
dass Passwörter verschlüsselt übertragen
werden. Probieren Sie auch die Option -x
von telnet
, die den gesamten Datenverkehr
verschlüsselt (analog zu ssh
).
Zu Heimdal gehören noch weitere Anwendungen.
Allerdings enthält das FreeBSD-Basissystem nur eine
minimale Heimdal-Installation mit nur einer
kerberisierten Anwendung: telnet
.
Der Heimdal-Port enthält noch mehr kerberisierte
Anwendungen wie ftp
, rsh
,
rcp
und rlogin
.
Der MIT-Port enthält ebenfalls
weitere kerberisierte Anwendungen.
Normalerweise wird ein
Kerberos-Prinzipal wie
tillman@EXAMPLE.ORG
auf ein lokales
Benutzerkonto, beispielsweise tillman
,
abgebildet. Daher benötigen Client-Anwendungen (zum
Beispiel telnet
) keinen Benutzernamen.
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
Benutzerkontos gewähren Zugriffe ähnlich wie
die Dateien .hosts
und
.rhosts
. Um den Prinzipalen
tillman@example.org
und
jdoe@example.org
auf das Konto
webdevelopers
zu geben, wird im
Heimatverzeichnis von webdevelopers
die Datei .k5login
mit folgendem
Inhalt angelegt:
Die angegebenen Prinzipale haben nun ohne ein gemeinsames Passwort Zugriff auf das Konto.
Einzelheiten entnehmen Sie bitte den Hilfeseiten
zu diesen Dateien. Die Datei .k5users
wird in der Hilfeseite des Kommandos ksu
beschrieben.
Wenn Sie den Heimdal-Port oder den
MIT-Port benutzen, muss in der
Umgebungsvariable PATH
der Pfad zu
den Programmen des Ports vor dem Pfad zu den
Kerberos-Programmen des Systems
stehen.
Sind die Uhrzeiten der Systeme synchronisiert? Wenn nicht, schlägt vielleicht die Authentifizierung fehl. Abschnitt 30.10, „Die Uhrzeit mit NTP synchronisieren“ beschreibt, wie Sie mithilfe von NTP die Uhrzeiten synchronisieren.
Die MIT- und Heimdal-Systeme
arbeiten bis auf kadmin
gut zusammen.
Für kadmin
wurde das Protokoll
nicht normiert.
Wenn Sie den Namen eines Rechners ändern,
müssen Sie auch den host/
-Prinzipal
ändern und die Datei keytab
aktualisieren. Dies betrifft auch spezielle Einträge
wie den Prinzipal für Apaches www/mod_auth_kerb
.
Die Rechnernamen müssen vor- und
rückwärts aufgelöst werden (im
DNS oder in
/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 mag aus Sicherheitsgründen richtig sein,
doch funktioniert ksu
dann nicht.
Dies ist 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 das modify_principal
von
kadmin
, um die maximale
Gültigkeitsdauer für den Prinzipal selbst
und den Prinzipal krbtgt
zu erhöhen.
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
Ticket-Granting-Ticket. Das Ticket-Granting-Ticket
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
(beispielsweise einer Woche) benutzen, setzen Sie die Option
TicketCleanup
in der Datei
sshd_config
auf no
.
Ansonsten werden Ihre Tickets gelöscht, wenn Sie
sich abmelden.
Host-Prinzipale können ebenfalls 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,
geht das nur mit Prinzipalen, denen eine Passwort-Policy
zugewiesen wurde. Die Hilfeseite von
kadmind
beschreibt kurz, wie
krb5.dict
verwendet wird. Das
Format von krb5.dict
ist
einfach: Die Datei enthält pro Zeile ein Wort.
Sie können daher einen symbolischen Link auf
/usr/share/dict/words
erstellen.
Der Hauptunterschied zwischen
MIT-Kerberos
und Heimdal-Kerberos
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 bitte der Anleitung auf der
Kerberos-Seite
(http://web.mit.edu/Kerberos/www/) des
MITs. Achten Sie besonders auf den
Suchpfad für Anwendungen. Der MIT-Port
wird 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 den MIT-Port
security/krb5
verwenden,
erscheint bei der Anmeldung mit telnetd
und klogind
die Fehlermeldung
incorrect permissions on cache file.
Lesen Sie dazu bitte die im Port enthaltene Datei
/usr/local/share/doc/krb5/README.FreeBSD
.
Wichtig ist, dass zur Authentifizierung die Binärdatei
login.krb5
verwendet wird, die
für durchgereichte Berechtigungen die Eigentümer
korrekt ändert.
In der Datei rc.conf
müssen
folgende Zeilen aufgenommen werden:
Diese Zeilen sind notwendig, weil die Anwendungen
von MIT-Kerberos Binärdateien
unterhalb von /usr/local
installieren.
Jeder über das Netzwerk angebotetene 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
Anmeldungen mit rsh
und
telnet
Kerberos
zu benutzen, dagegen aber POP3-Zugriff
auf einen Mail-Server zu erlauben, da POP3
Passwörter im Klartext versendet.
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 gestohlen werden.
Dieses Problem können Sie lösen, indem Sie mit
der Kommandozeilenoption -c
oder besser
mit der Umgebungsvariablen KRB5CCNAME
einen
Ort für die Tickets vorgeben. Diese Vorgehensweise
wird leider selten benutzt. Es reicht, die Tickets
im Heimatverzeichnis eines Benutzers zu speichern und
mit Zugriffsrechten zu schützen.
Das KDC muss genauso abgesichert werden wie die auf ihm befindliche Passwort-Datenbank. Auf dem KDC dürfen 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, vielleicht wegen eines Denial-of-Service Angriffs oder wegen eines Netzwerkproblems, ist eine Authentifizierung unmöglich. Damit können die Netzwerk-Dienste nicht benutzt werden; das KDC ist also ein optimales Ziel für einen Denial-of-Service Angriff. Sie können diesem Angriff ausweichen, indem Sie mehrere KDCs (einen Master und einen oder mehrere Slaves) verwenden. Der Rückfall auf ein sekundäres KDC oder eine andere Authentifizierungs-Methode (dazu ist PAM bestens geeignet) 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>.