Sicherheitskonzept¶

Wird Kerberos zur Authentifizierung eingesetzt, müssen folgende Bedingungen erfüllt sein, dass eine NFS-Operation ausgeführt werden kann:

1. Der NFS-Server muss gegenüber Kerberos authentifiziert sein (nicht benutzerbezogen).

2. Ein Client muss gegenüber dem Kerberos Server authentifiziert sein (nicht benutzerbezogen).

3. Der Benutzer, der am Client angemeldet ist, muss gegenüber Kerberos authentifiziert sein.

Zu diesem Zweck werden auf dem NFS-Server als auch auf dem Client Kerberos-Keys hinterlegt, die beglaubigen, dass der Rechner für eine Aufgabe freigeschaltet ist (ähnlich dem Konzept einer CA). So kann sowohl der Client als auch der Server zu seinen Partnern vertrauenswürdig identifiziert werden.

Meldet sich ein Benutzer am Client über Kerberos an, wird diesem ein Ticket zugewiesen. Bei der ersten Kommunikation mit dem NFS-Server (das muss nicht unbedingt ein Mount sein) wird diesem Benutzer-Ticket ein Task-Ticket des NFS-Servers zugewiesen. Umgekehrt wird dem NFS-Server ein Task-Ticket des Clients zugewiesen. Diese Tickets/Keys werden dann von NFS zur Authentifizierung und ggf. Verschlüsselung genutzt. Somit werden gleich eine Reihe von Angriffen ausgeschlossen. Von dem einfachen "unbekannten Client", der sich einfach mit dem NFS-Share verbindet, bis hin zu Man-In-The-Middle Attacken.

Da beim Einsatz des IDMAP-Daemons (muss in der NFS-Konfig aktiviert werden) nicht mehr direkt mit UIDs zwischen Client und Server gearbeitet wird, sind Angriffsszenarien mit wechselnder UID unterbunden. Die Kerberos-Benutzernamen werden auf Serverseite in UIDs gemapt. So kann ein "Superuser" am Client keine Möglichkeit, seine UID zu verändern. Einzige Ausnahme ist das Übernehmen einer bestehenden Kerberos-Sitzung. Ein Beispielszenario um das zu verdeutlichen:

• An einer Workstation sind drei Benutzer angemeldet: A, C und D. Einer vierter User B ist aktuell nicht angemeldet aber prinzipiell zur Anmeldung auf dem Rechner berechtigt.

• Benutzer A ist gegenüber Kerberos authentifiziert.

• Benutzer C ist lokaler Admin. Ein Benutzer mit gleicher UID existiert aber am NFS-Server.

• Benutzer D ist gegenüber Kerberos authentifiziert und lokaler Admin.

Wird ein NFS-Share mit Kerberos-Authentifizierung gemounted, kann Benutzer A und B darauf zugreifen. Benutzer C wird unabhängig von seinen lokalen Rechten keinen Zugriff erhalten, da er kein gültiges Ticket und somit auch keine Schlüssel besitzt.

Benutzer D kann hingegen ebenfalls auf das NFS-Share zugreifen, jedoch ungeachtet seiner "lokalen" Rechte. Der Kerberos-Benutzername wird zum Server übertragen und dort in eine UID gemapt. Auch die Gruppenberechtigung wird am Server geprüft, selbst wenn sich Benutzer D lokal als Mitglied aller Gruppen hinterlegt hat.

Beide Superuser können sich jedoch in den Kontext des Benutzers A setzen und dessen Session mitnutzen. Dazu müssen sie wissen, welchen Kerberos-Ticket-Cache Benutzer A gerade nutzt (im Zweifelsfall durchprobieren) und setzen anschließend diesen Cache als eigene Environment-Variable oder kopieren sich den Cache. Ab diesem Zeitpunkt können sich Benutzer C und D als Benutzer A ausgeben – jedoch nur so lange, wie die Tickets gültig sind. Zum Erneuern der Tickets wird der Schlüssel von Benutzer A benötigt. Meldet sich dieser ab, verfällt der Zugriff.

Voraussetzungen¶

Der Kombination NFS - Kerberos (LDAP) wird häufig vorgeworfen, komplizierter in der Einrichtung zu sein als das Pendant Samba. Dies stimmt auf den ersten Blick. Es werden schlicht mehr Dienste zum sicheren Betrieb von NFS benötigt als bei Samba. Dies relativiert sich jedoch, sobald man NFS in ein bestehendes Netzwerk einbringt. Die Dienste (DNS, Kerberos, LDAP, NTP), die benötigt werden, sind meist sowieso vorhanden.

Bevor man jedoch NFS an Kerberos anbinden kann, sollten folgenden Rahmenbedingen erfüllt sein:

• Das Netzwerk muss einen DNS-Server besitzen, der für alle Clients und Server einen "Reverse Lookup" bereit hält. Kerberos verlässt sich stark auf ein funktionierendes DNS. Siehe Bind.

• Ein Kerberos Server muss vorhanden sein und auf den Clients muss die Kerberos-Authentifizierung aktiviert sein. Am Clients sollte man sich mit Kerberos anmelden können.

• Das Kerberos-Protokoll setzt voraus, dass auf allen Rechnern die Uhren synchronisiert sind. Das kann unter Ubuntu durch das NTP-Protokoll erfolgen. Siehe Network Time Protocol

• Ein NFS-Server sollte existieren und zum Test ein Verzeichnis exportieren. Es ist einfacher, ein bereits funktionierendes NFS-Share auf Kerberos umzustellen als den Server komplett neu aufzusetzen. Siehe NFS

• Unter Umständen benötigt man LDAP zum Abgleich der Benutzernamen und Gruppen. Das kann man in kleinen Netzen auslassen. Dort kann man die Gruppen manuell synchron halten. Siehe OpenLDAP ab Precise

Kerberos - Konfiguration¶

  [libdefaults]
  allow_weak_crypto = true

Als erstes muss man sowohl für die NFS-Clients als auch die NFS-Server Tasks anlegen. Das kann auf einem beliebigen Kerberos-Client ohne Root-Rechte erfolgen.

kadmin -p some-kerberos-admin/admin
addprinc -randkey nfs/nfs-server1.example.com
addprinc -randkey nfs/nfs-server2.example.com
addprinc -randkey nfs/nfs-client1.example.com
addprinc -randkey nfs/nfs-client2.example.com
addprinc -randkey nfs/nfs-client3.example.com 

Anschließend auf jedem Client und Server die Task/Keys hinterlegt werden. Dazu muss man mit Root-Rechten eine Kerberos-Umgebung initialisieren und die Task hinterlegen. Die Root-Rechte werden benötigt, da die Keys in der Datei /etc/krb5.keytab hinterlegt werden und dort nur Root Schreibzugriff hat. Auf dem Server nfs-server1.example.com erfolgt das wie folgt:

sudo kinit some-kerberos-admin/admin
sudo kadmin -p some-kerberos-admin/admin
ktadd nfs/nfs-server1.example.com 

Auf allen Clients wird gleichermaßen vorgegangen:

sudo kinit some-kerberos-admin/admin
sudo kadmin -p some-kerberos-admin/admin
ktadd nfs/nfs-cient1.example.com 

Wichtig ist, dass die Domainnamen korrekt zu den Client-IPs aufgelöst werden und umgekehrt. Anschließend kann man prüfen, ob die Task/Keys korrekt hinterlegt wurden.

sudo klist -e -k /etc/krb5.keytab 

Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   5 nfs/nfs-server1.example.com@REALM (ArcFour with HMAC/md5) 
   5 nfs/nfs-server1.example.com@REALM (DES cbc mode with CRC-32) 
   5 nfs/nfs-server1.example.com@REALM (AES-256 CTS mode with 96-bit SHA-1 HMAC) 
   5 nfs/nfs-server1.example.com@REALM (Triple DES cbc mode with HMAC/sha1)

NFS - Konfiguration - Server¶

Die NFS Konfiguration ist wesentlich simpler. Auf Serverseite müssen folgende Dateien angepasst werden:

• /etc/default/nfs-kernel-server - Dort muss der GSS-Daemon aktiviert werden.

  NEED_SVCGSSD=yes 

• /etc/default/nfs-common - Hier muss der IDMAP-Daemon aktiviert werden, der die Gruppen zwischen Server und Client mapt.

  NEED_IDMAPD=yes

• /etc/exports - Anschließend muss man die Exports auf Kerberos-Authentifizierung umstellen.

  /export        10.0.0.0/24(sec=krb5,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)
  /export/Share1 10.0.0.0/24(sec=krb5,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)
  /export/Share2 10.0.0.0/24(sec=krb5,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)

  Experten-Info:

  Es existiert auch folgende Schreibweise:

  /export       gss/krb5(rw,fsid=0, secure, no_subtree_check,async,no_all_squash)

  Diese ist jedoch als "depreciated" markiert und sollte nicht mehr verwendet werden.

/export       10.0.0.0/24(sec=krb5i:krb5p,rw,fsid=0, secure, no_subtree_check,async,no_all_squash)

NFS - Konfiguration - Client¶

Auf Clientseite ist die Anpassung trivial. Man bearbeitet die Datei /etc/default/nfs-common. Hier werden wieder der IDMAP-Daemon und der GSS-Daemon aktiviert.

NEED_IDMAPD=yes
NEED_GSSD=yes 

Danach muss man den Rechner durchstarten oder manuell die beiden Dienste starten.

sudo service gss start
sudo service idmap start 

Anschließend kann man ein Share mounten, wenn man sich in einer gültigen Kerberos-Umgebung befindet:

mount -t nfs4 -o sec=krb5i,async,soft nfs-server1.example.com:/Share1 /mnt/nfs-share 

Links¶

• NFS4 Howto

• Dokumentation NFSv4/Kerberos

• NFS-Sicherheitsmodel

• NFSv4 Features-Liste

• Manpage NFSSEC

• Stronger security for NFS

• Kerberos - Grundlagenartikel

• Serverdienste Übersichtsartikel