| FreeBSD Handbuch | ||
|---|---|---|
| Zurück | Kapitel 10. Sicherheit | Nach vorne |
Kerberos ist ein zusätzliches Netzwerkprotokoll, das es Benutzern erlaubt, sich über einen sicheren Server zu authentifizieren. Dienste wie rlogin, rcp oder das sichere Kopieren von Dateien zwischen Systemen und andere risikoreiche Tätigkeiten werden durch Kerberos erheblich sicherer und kontrollierbarer.
Die folgende Anleitung kann nur als Wegweiser dazu dienen, wie Sie Kerberos für FreeBSD konfigurieren. Für eine komplette Beschreibung des Systems, sollten Sie sich auf jeden Fall die entsprechenden Manualpage ansehen.
Kerberos ist eine optionale Komponente von FreeBSD. Am leichtesten installieren Sie die Software, wenn Sie bei der ersten Installation von FreeBSD in sysinstall die Distribution 'krb4' oder 'krb5' auswählen. Damit installieren Sie entweder die 'eBones' (KerberosIV) oder 'Heimdal' (Kerberos5) Version von Kerberos. Beide Versionen werden mit FreeBSD ausgeliefert, da sie außerhalb von den USA oder Kanada entwickelt werden. Sie unterliegen deshalb auch nicht den restriktiven Exportbeschränkungen der USA und sind auch für Bewohner anderer Länder zugänglich.
Als Alternative steht die MIT Variante von Kerberos in der Ports-Kollektion unter security/krb5 zur Verfügung.
Die folgenden Schritte werden nur auf dem Kerberos-Server durchgeführt. Stellen Sie bitte vorher sicher, dass keine alten Kerberos-Datenbanken mehr vorhanden sind. Im Verzeichnis /etc/kerberosIV sollten sich nur die folgenden Dateien befinden:
# cd /etc/kerberosIV
# ls
README krb.conf krb.realms
Wenn noch andere Dateien, wie principal.* oder master_key, existieren, müssen Sie die alte Kerberos-Datenbank mit kdb_destroy löschen. Wenn Kerberos nicht läuft, können Sie die Dateien auch einfach löschen.
Sie sollten nun die Dateien krb.conf und krb.realms editieren, um Ihr Kerberos-Realm zu definieren. Das folgende Beispiel zeigt dies für das Realm EXAMPLE.COM auf dem Server grunt.example.com. krb.conf sollte wie folgt aussehen:
# cat krb.conf
EXAMPLE.COM
EXAMPLE.COM grunt.example.com admin server
CS.BERKELEY.EDU okeeffe.berkeley.edu
ATHENA.MIT.EDU kerberos.mit.edu
ATHENA.MIT.EDU kerberos-1.mit.edu
ATHENA.MIT.EDU kerberos-2.mit.edu
ATHENA.MIT.EDU kerberos-3.mit.edu
LCS.MIT.EDU kerberos.lcs.mit.edu
TELECOM.MIT.EDU bitsy.mit.edu
ARC.NASA.GOV trident.arc.nasa.gov
Die zusätzlich aufgeführten Realms brauchen Sie nicht anzulegen. Sie zeigen hier nur, wie man Kerberos dazu bringt, andere Realms zu erkennen. Sie können Sie also auch weglassen.
Die erste Zeile benennt das Realm, in dem das System arbeitet. Die anderen Zeilen enthalten Realm/Host Paare. Der erste Wert jeder Zeile ist das Realm, der zweite Teil ein Host, der in diesem Realm ``Key Distribution Center'' ist. Die Schlüsselwörter admin server nach einem Hostnamen bedeuten, dass dieser Host auch einen administrativen Datenbankserver zur Verfügung stellt. Weitere Erklärungen zu diesen Begriffen finden Sie in den Kerberos Manualpages.
Als nächstes muss grunt.example.com in das Realm EXAMPLE.COM aufgenommen werden. Des Weiteren erstellen wir einen Eintrag, der alle Rechner der Domäne .example.com in das Realm EXAMPLE.COM aufnimmt. krb.realms sollte danach so aussehen:
# cat krb.realms
grunt.example.com EXAMPLE.COM
.example.com EXAMPLE.COM
.berkeley.edu CS.BERKELEY.EDU
.MIT.EDU ATHENA.MIT.EDU
.mit.edu ATHENA.MIT.EDU
Die zusätzlichen Realms sind hier wieder als Beispiel gedacht. Sie können sie der Einfachheit halber auch weglassen.
Die erste Zeile nimmt ein einzelnes System in das Realm auf. Die anderen Zeilen zeigen, wie bestimmte Subdomänen einem bestimmten Realm zugeordnet werden.
Das folgende Kommando muss nur auf dem Kerberos-Server (oder ``Key Distribution Center'') laufen. Mit kdb_init können wir die Datenbank anlegen:
# kdb_init
Realm name [default ATHENA.MIT.EDU ]: EXAMPLE.COM
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master key:
Anschließend muss der Schlüssel gespeichert werden, damit Server auf der lokalen Maschine darauf zugreifen können. Dies geschieht mit kstash:
# kstash
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Das verschlüsselte Master-Passwort wurde in /etc/kerberosIV/master_key gesichert.
Für jedes System, das mit Kerberos gesichert werden soll, müssen zwei Prinzipale in die Datenbank eingetragen werden. Ihre Namen sind kpasswd und rcmd. Beide Prinzipale müssen für jedes System angelegt werden, wobei die Instanz der Name des jeweiligen Systems ist.
Die Dæmonen kpasswd und rcmd erlauben es anderen Systemen, Kerberos-Passwörter zu ändern und Kommandos wie rcp, rlogin und rsh laufen zu lassen.
Beide Einträge werden im Folgenden angelegt:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: passwd
Instance: grunt
<Not found>, Create [y] ? y
Principal: passwd, Instance: grunt, kdc_key_ver: 1
New Password: <---- geben Sie hier Zufallswerte ein
Verifying password
New Password: <---- geben Sie hier Zufallswerte ein
Random password [y] ? y
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: rcmd
Instance: grunt
<Not found>, Create [y] ?
Principal: rcmd, Instance: grunt, kdc_key_ver: 1
New Password: <---- geben Sie hier Zufallswerte ein
Verifying password
New Password: <---- geben Sie hier Zufallswerte ein
Random password [y] ?
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- geben Sie nichts an, um das Programm zu verlassen
Wir müssen nun für jede Maschine die Instanzen, die Dienste definieren, aus der Datenbank mit ext_srvtab extrahieren. Die erstelle Datei muss auf einem sicheren Weg in das /etc/kerberosIV Verzeichnis jedes Clients kopiert werden. Die Datei muss auf jedem Server und auf jedem Client vorhanden sein und ist unabdingbar für Kerberos.
# ext_srvtab grunt
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Generating 'grunt-new-srvtab'....
Das Kommando erzeugt Dateien mit einem temporären Namen, der es anderen Servern erlaubt, ihre Datei abzuholen. Die Datei muss auf dem entsprechenden System in srvtab umbenannt werden. Auf dem originalen System können Sie mv benutzen, um die Datei umzubenennen:
# mv grunt-new-srvtab srvtab
Wenn die Datei für ein Client-System bestimmt ist und das Netzwerk nicht sicher ist, kopieren Sie die Datei auf ein bewegliches Medium und transportieren sie physikalisch. Kopieren Sie die Datei auf den Client in das Verzeichnis /etc/kerberosIV. Benennen Sie die Datei in srvtab um und setzen Sie schließlich noch die Berechtigungen auf 600:
# mv grumble-new-srvtab srvtab
# chmod 600 srvtab
Wir können nun Benutzer in der Datenbank anlegen. Mit kdb_edit legen wir zuerst die Benutzerin jane an:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jane
Instance:
<Not found>, Create [y] ? y
Principal: jane, Instance: , kdc_key_ver: 1
New Password: <---- geben Sie ein sicheres Passwort ein
Verifying password
New Password: <---- wiederholen Sie die Eingabe
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- geben Sie nichts an, um das Programm zu verlassen
Zuerst müssen die Kerberos-Dæmonen gestartet sein. Wenn Sie /etc/rc.conf richtig angepasst haben, passiert das automatisch, wenn Sie booten. Dieser Schritt ist nur auf dem Kerberos-Server notwendig, die Clients bekommen alles was sie brauchen aus dem /etc/kerberosIV Verzeichnis.
# kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: EXAMPLE.COM
# kadmind -n &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Jetzt können wir mit kinit versuchen, ein Ticket für die ID jane, die wir oben angelegt haben, zu erhalten:
% kinit jane
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane"
Password:
Mit klist können Sie sich vergewissern, dass Sie die Tickets auch erhalten haben:
% klist
Ticket file: /tmp/tkt245
Principal: jane@EXAMPLE.COM
Issued Expires Principal
Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EXAMPLE.COM@EXAMPLE.COM
Versuchen Sie nun das Passwort mit passwd zu ändern, um zu überprüfen, dass der kpasswd Dæmon auch auf der Kerberos-Datenbank autorisiert ist:
% passwd
realm EXAMPLE.COM
Old password for jane:
New Password for jane:
Verifying password
New Password for jane:
Password changed.
Mit Kerberos kann jedem Benutzer, der root-Privilegien braucht, ein eigenes Passwort für su zugewiesen werden. Dies wird dadurch erreicht, dass die Instanz eines Prinzipals root ist. Mit kbd_edit legen wir nun den Eintrag jane.root in der Kerberos-Datenbank an:
# kdb_edit
Opening database...
Enter Kerberos master key:
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jane
Instance: root
<Not found>, Create [y] ? y
Principal: jane, Instance: root, kdc_key_ver: 1
New Password: <---- geben Sie ein sicheres Passwort ein
Verifying password
New Password: <---- geben Sie das Passwort erneut ein
Principal's new key version = 1
Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- Keep this short!
Attributes [ 0 ] ?
Edit O.K.
Principal name: <---- geben Sie nichts an, um das Programm zu verlassen
Versuchen Sie nun, für diesen Prinzipal Tickets zu bekommen:
# kinit jane.root
MIT Project Athena (grunt.example.com)
Kerberos Initialization for "jane.root"
Password:
Als nächstes fügen wir den Prinzipal in .klogin von root ein:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Jetzt benutzen wir su:
% su
Password:
und kontrollieren, welche Tickets wir haben:
# klist
Ticket file: /tmp/tkt_root_245
Principal: jane.root@EXAMPLE.COM
Issued Expires Principal
May 2 20:43:12 May 3 04:43:12 krbtgt.EXAMPLE.COM@EXAMPLE.COM
In einem der Beispiele haben wir einen Prinzipal mit dem Namen jane und der Instanz root angelegt. Der Prinzipal entstand aus einem Benutzer mit dem gleichen Namen. Unter Kerberos ist es Standard, dass ein principal.instance der Form username.root es dem Benutzer username erlaubt, mit su root zu werden, wenn die entsprechenden Einträge in .klogin von root existieren:
# cat /root/.klogin
jane.root@EXAMPLE.COM
Das gilt auch für die .klogin-Datei im Heimatverzeichnis eines Benutzers:
% cat ~/.klogin
jane@EXAMPLE.COM
jack@EXAMPLE.COM
Die Einträge erlauben jedem, der sich im Realm EXAMPLE.COM als jane oder jack mit kinit authentifiziert hat, über rlogin, rsh oder rcp Zugriff auf den Account jane und dessen Dateien.
Im folgenden Beispiel meldet sich jane mit Kerberos auf grunt an:
% kinit
MIT Project Athena (grunt.example.com)
Password:
% rlogin grunt
Last login: Mon May 1 21:14:47 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
Im folgenden Beispiel wurde der Prinzipal jack mit einer Instanz null angelegt. Mit der obigen .klogin-Datei kann er sich nun auf derselben Maschine als jane anmelden:
% kinit
% rlogin grunt -l jane
MIT Project Athena (grunt.example.com)
Password:
Last login: Mon May 1 21:16:55 from grumble
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
| Zurück | Zum Anfang | Nach vorne |
| S/Key | Nach oben | Firewalls |
Wenn Sie Fragen zu FreeBSD haben,
schicken Sie eine EMail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie
eine Email an <de-bsd-translators@de.FreeBSD.org>.