[[Vorlage(archiviert)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:sudo: Root-Rechte] }}} [[Inhaltsverzeichnis()]] [[Bild(Wiki/Icons/service.png, 48, align=left)]] Der Begriff Kerberos steht sowohl für ein Protokoll als auch dessen Implementierung und ermöglicht eine sichere Authentifizierung in einer unsicheren Umgebung. Der Name bezieht sich auf den [wikipedia:Kerberos_(Mythologie):Höllenhund], der in der griechischen Mythologie den Ein- bzw. den Ausgang der Unterwelt bewacht. Das Protokoll basiert auf dem [wikipedia:Needham-Schroeder-Protokoll:] von 1978 und beschreibt ein Verfahren zum Austausch von Schlüsseln zwischen gleichberechtigten Partnern (Client, Server) und einer dritten gesicherten Instanz, dem Kerberos Server (oder mehreren Servern). Das Protokoll unterscheidet bei der Authentifizierung zwischen Host, Dienst und Benutzer. Die aktuelle Kerberos Version 5 wurde 2005 als [http://tools.ietf.org/html/rfc4120:RFC RFC 4120] {en} veröffentlicht. Es existieren aktuell vier konkurrierende Implementierungen: * [http://web.mit.edu/Kerberos/ MIT Kerberos] {en} * [http://www.h5l.org/ Heimdal Kerberos] {en} * [http://www.gnu.org/s/shishi/ Shishi Kerberos] {en} * [wikipedia:Active_Directory:Active Directory] - diese umfasst nicht nur Kerberos Funktionalitäten, sondern implementiert auch LDAP {{{#!vorlage Hinweis Um den Artikel einfach zu halten, wird im Folgenden nur auf die MIT Kerberos Implementierung eingegangen. }}} = Voraussetzungen = Bevor ein Kerberos-Server in Betrieb genommen werden kann müssen zwei Voraussetzungen geschaffen werden. * NTP-Server: Kerberos arbeitet mit Tickets, welche ein absolutes "Verfallsdatum" haben. Driften die Uhren der beteiligten Verbindungspartner zu stark auseinander (MIT-Standard: 5 Min), kommt keine Verbindung zu Stande. * DNS-Server: Kerberos arbeitet mit [wikipedia:Domain#Fully_Qualified_Domain_Name_.28FQDN.29:FQDN] (z.B. `host1.realm.some.domain`). Alle beteiligten Verbindungspartner müssen sowohl im Forward- als auch im Reverse-Lookup aufgelöst werden können. = Installation - Server = {{{#!vorlage Warnung Die Sicherheit eines Kerberos-Netzwerkes basiert vollständig auf der Sicherheit des Kerberos-Servers. Erlangt ein Angreifer Root-Rechte bzw. -zugriff auf die Schlüssel-Datenbank des Kerberos, kann dieser beliebige Berechtigungen ausstellen, kennt die Schlüssel für eventuelle Verschlüsselungen usw. Dieser "Mangel" ist durch das Design bedingt. Das MIT empfiehlt als Gegenmaßnahme, den/die Kerberos Server entsprechend dieser Anforderung zu sichern. Dazu gehört: * Am besten nur dedizierte Kerberos Server, damit so wenig wie irgend möglich (weitere) Dienste auf dem Rechner laufen. Vor allem keine Dienste, die als Benutzer `root` laufen oder das Erlangen von Root-Rechten ermöglichen. * Das Gerät sollte physikalisch in einem gesicherten Bereich stehen. * Es sollten nur Accounts für den Kerberos-Admin geben. * Das OS sollte auf dem aktuellsten Patch-Stand sein (unter Ubuntu: keine Pakete aus `backports` oder `proposed`) Quellen: [http://www.ornl.gov/~jar/HowToKerb.html Kerberos installation help] {en} , [http://ikhaya.ubuntuusers.de/2011/11/23/erneute-warnung-vor-proposed-paketquellen/ Erneute Warnung vor „proposed“-Paketquellen] }}} {{{#!vorlage Paketinstallation krb5-kdc krb5-admin-server }}} Nach der Installation erfolgt ein geführter Konfigurationsdialog. Der übernimmt die wichtigsten Einstellungen. Die fertige Konfiguration findet sich dann unter '''/etc/krb5kdc/kdc.conf''' {{{ [kdcdefaults] kdc_ports = 750,88 [realms] my.realm.root = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3 default_principal_flags = +preauth } }}} {{{#!vorlage Hinweis Unter Ubuntu wird der MIT-Kerberos __ohne__ Standard-Benutzer/Admin angelegt. Man muss initial einen Realm-Admin anlegen. }}} Dies geschieht mit folgendem Befehl: {{{#!Vorlage Befehl sudo krb5_newrealm }}} Hier muss ein Passwort vergeben werden, das möglichst komplex sein sollte und das nicht vergessen werden darf. == Benutzer anlegen == Existiert noch kein Adminuser für einen Realm oder will man die Anmeldung am Kerberos umgehen (Password vergessen...), erlangt mit folgendem Befehl zugriff auf die Kerberos Admin Konsole. {{{#!Vorlage Befehl sudo kadmin.local }}} {{{#!vorlage Hinweis Der gezeigte Befehl kann __nur lokal__ an einem Kerberos-Server ausgeführt werden. Ein ordnungsgemäß konfigurierter Kerberos benötigt diese Möglichkeit zur Administration __nicht__. }}} Im Normalfall kann man von jedem Rechner, der sich dem Kerberos-Realm angeschlossen hat, wie folgt Zugriff auf die Admin-Konsole erlangen: {{{#!Vorlage Befehl kadmin -p principal-name }}} Einmal in der Admin-Konsole kann wie folgt ein Benutzer angelegt werden: {{{#!Vorlage Befehl addprinc simple_user #legt einen normalen Benutzer addprinc some_new_admin/admin #legt einen Admin-Benutzer an }}} {{{#!vorlage Experten Es kann prinzipiell jeder Name für einen Admin vergeben werden. Es hat sich jedoch als sinnvoll herausgestellt, alle Admins in eigene Instanzen (der Teil nach dem Slash) zu packen. Diese Instanz "/admin" kann dann als "Gruppe" gebraucht werden, um ihr über ACLs entsprechende Kerberos-Berechtigungen zuzuweisen. }}} Der Benutzer "some_new_admin/admin" besitzt noch keine Berechtigung auf dem Kerberos. Dies wird durch die Datei '''/etc/krb5kdc/kadm5.acl''' gesteuert. {{{ */admin@my.realm.root * #gewährt allen Benutzern der Instanz admin alle Rechte myadmin@my.realm.root * #gewährt dem Benutzer myadmin alle Rechte untrust@my.realm.root ADMCI #entzieht alle Rechter außer das Listing-Recht von Benutzer untrust }}} {{{#!vorlage Tabelle Mögliche ACL Rechte +++ Recht Beschreibung +++ `a` Erlaubt das Hinzufügen von Principals oder Policies. +++ `A` Verbietet das Hinzufügen von Principals oder Policies. +++ `d` Erlaubt das Löschen von Principals oder Policies. +++ `D` Verbietet das Löschen von Principals oder Policies. +++ `m` Erlaubt das Modifizieren von Principals oder pPolicies. +++ `M` Verbietet das Modifizieren von Principals oder Policies. +++ `c` Erlaubt das Ändern des Passworts für Principals. +++ `C` Verbietet das Ändern des Passworts für Principals. +++ `i` Erlaubt das Abfragen der Datenbank. +++ `I` Verbietet das Abfragen der Datenbank. +++ `l` Erlaubt das Auflisten aller Principals oder Policies. +++ `L` Verbietet das Auflisten aller Principals oder Policies. +++ `s` Erlaubt das explizite setzen eines Keys für einen Principal. +++ `S` Verbietet das explizite setzen eines Keys für einen Principal. }}} == Dienste anlegen == Neben einzelnen Benutzern verwaltet Kerberos auch Dienste. Diese werden ebenfalls über Principals abgebildet. Angelegt werden sie wie folgt: {{{#!Vorlage Befehl kadmin -p some_new_admin/admin addprinc -randkey nfs/server.my.realm.root addprinc -randkey cifs/server.my.realm.root addprinc -randkey nfs/client.my.realm.root addprinc -randkey cifs/client.my.realm.root addprinc -randkey nfs/some-other-client.my.realm.root addprinc -randkey cifs/some-other-client.my.realm.root }}} In diesem Beispiel sind am Kerberos nun Principals für den Dienst CIFS und NFS auf den Rechnern `server`, `client`, `some-other-client` hinterlegt. Welche Rollen diese Rechner später einnehmen, spielt für Kerberos keine Rolle. Es ist durchaus möglich, dass der Rechner `client.my.realm.root` einen CIFS-Server stellt und sich `server.my.realm.root` darauf verbindet. Dieses Erzeugen und Speichern der Keys hat auch im ersten Schritt keine sicherheitsrelevanten Konsequenzen. Erst wenn die Keys manuell auf dem entsprechenden Client hinterlegt werden, kann dieser die Keys auch benutzen. = Installation - Client = {{{#!vorlage Hinweis Wenn auf dem Kerberos Server auch Dienste laufen, die sich gegenüber Kerberos authentifizieren, wird auch die Client-Komponente benötigt. }}} {{{#!vorlage Paketinstallation krb5-user }}} Sollen sich an dem Client auch Benutzer über Kerberos authentifizieren, wird noch die PAM-Komponente benötigt. {{{#!vorlage Warnung Beim Einrichten von libpam-krb5 sollte man immer eine aktive "Notfall"-Konsole mit Admin-Rechten offen habe. Ist die Kerberos Server/Client-Konfiguration fehlerhaft, kann man sich u.U nicht mehr am System anmelden. }}} {{{#!vorlage Paketinstallation krb5-user libpam-krb5 }}} Sollte es sich bei dem Client um ein Gerät handeln, das nicht permanent den Kerberos-Server zur Verfügung hat, benötigt man noch das folgende Paket, um die User-Credentials lokal zu cachen. Dies ist ebenfalls im Fehlerfall nützlich, wenn der Kerberos-Server nicht verfügbar ist. {{{#!vorlage Paketinstallation libpam-ccreds }}} Nach der Installation wird abermals ein geführter Konfigurationsdialog ausgeführt. Dieser konfiguriert die '''/etc/krb5.conf''' so, dass eine Anmeldung mit Kerberos prinzipiell möglich sein sollte. In dieser Datei sind eine Reihe von Beispiel-Realms parametriert, die man bedenkenlos löschen kann. Eine aufgeräumte Konfiguration kann so aussehen. {{{ [libdefaults] default_realm = MY.REALM.ROOT krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true [realms] MY.REALM.ROOT = { kdc = KERBEROS-SERVER admin_server = KERBEROS-SERVER default_domain = my.realm.root } [domain_realm] [login] krb4_convert = false krb4_get_tickets = false [logging] kdc = SYSLOG:INFO:DAEMON admin_server = SYSLOG:INFO:DAEMON default = SYSLOG:INFO:DAEMON }}} Man sollte sich nun in einer zweiten Konsole mit einem Kerberos-Benutzer anmelden können. {{{#!vorlage Hinweis Kommt keine Benutzer/Gruppen-Synchronisation via LDAP zum Einsatz, muss der Administrator selber dafür Sorge tragen. Damit ein Benutzer über Kerberos authentifiziert werden kann, muss dieser auch in der lokalen '''/etc/passwd''' hinterlegt sein. Andernfalls kann sich der Benutzer nicht an dem Client anmelden. }}} Soll der Benutzer sich an dem Client nicht nur anmelden können, sondern auch Dienste benutzen, müssen die entsprechenden Keys hinterlegt werden. {{{#!Vorlage Befehl sudo kinit some_new_admin/admin ktadd cifs/client.my.realm.root ktadd nfs/client.my.realm.root }}} Ab diesem Moment ist es möglich, NFS und CIFS-Shares ohne User-Credentials einzubinden (mounten) und den Zugriff von jedem durch Kerberos authentifizierten Benutzer zu gestatten. == Sonderfall - automatische Anmeldung == Manchmal ist es nötig, einen Rechner ohne Authentifizierung zur Verfügung zu stellen. Als Beispiele sind HTPCs oder Terminal-Rechner in Ausstellungsräumen zu nennen. Für diesen Zweck gibt es diverse Mechanismen unter Ubuntu. Soll ein solcher Rechner auch in einem Kerberos Netz betrieben werden, kommt es darauf an, ob die benutze Login-Variante in den PAM-Prozess eingreift oder einfach ein gespeichertes Password durchreicht. Bei letzterer Variante ist kein Eingriff nötig, da der "User" gegenüber Kerberos wie jeder normale Benutzer authentifiziert wird (mit dem gespeicherten Passwort). Einige [:Displaymanager:] (z.B NoDM) umgehen bei einer automatischen Anmeldung einfach die PAM-Authentifizierung bzw. richten eine eigene PAM-Kette ein, die kein Passwort erfordert. Ist man sich nicht sicher, ob eine gültige Kerberos-Umgebung vorliegt, kann man das mittels folgendem Befehl prüfen: {{{#!Vorlage Befehl klist }}} Liefert dieser Befehl die Meldung "No credentials cache found", existiert keine gültige Kerberos Umgebung. Um eine Kerberos-Umgebung ohne Passwort zu bekommen, benötigt man den Schlüssel des Principals auf dem Client. Dieser sollte in einer benutzerbezogenen Keytab abgelegt werden, da die Datei '''/etc/krb5.keytab''' nur `root` zugänglich ist. {{{#!vorlage Warnung Mit den folgenden Befehlen legt man das Secret eines Benutzers auf einem "ungeschützten" Ort. Diese Information kann jeder extrahieren und zur Authentifizierung nutzen. }}} {{{#!Vorlage Befehl sudo -u autologinuser kadmin -p some_new_admin/admin addprinc -randkey autologinuser ktadd -k /home/autologinuser/.keytab autologinuser }}} Um eine Kerberos Umgebung zu initialisieren, führt muss man `kinit` mit der Keytab und dem Benutzernamen auf. {{{#!Vorlage Befehl /usr/bin/kinit -k -t /home/autologinuser/.keytab autologinuser@MY.REALM.ROOT }}} Dieser Befehl kann in einem Startskript (z.B. '''/home/autologinuser/.xsession''') hinterlegt werden. Soll das System sehr lange laufen, kann es passieren, dass die Tickets ablaufen. Standartmäßig ist der KDC auf 10 Stunden Ticket-Lebenzeit und maximal 7 Tage "Wiederbelebung" eingestellt. Entweder erhöht man diese Werte in der '''/etc/krb5kdc/kdc.conf''' oder man legt auf Clientseite einen Cronjob an, welchen eine Erneuerung der Tickets anstößt. Dazu einfach in der User-Crontab folgende Zeile anlegen: {{{ 0 * * * * /usr/bin/kinit -R }}} = Links = * [wikipedia:Kerberos_(Informatik):Kerberos] - Wikipedia * [ubuntu_doc:community/Kerberos:Ubuntu Community Documentation - Kerberos] {en} * [ubuntu_doc:lts/serverguide/kerberos.html:Ubuntu Serverguide Kerberos] {de} * Weitere Artikel zum Thema: * [:Kerberos/NFS_mit_Kerberos_sichern:Kerberos/NFS_mit_Kerberos_sichern] * [:Archiv/Kerberos/LDAP:Kerberos/LDAP] * [:Serverdienste:] {Übersicht} Übersichtsartikel # tag: Netzwerk, System, Sicherheit, Server