ubuntuusers.de

Du betrachtest eine alte Revision dieser Wikiseite.

NFS mit Kerberos sichern

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png NFS wurde ursprünglich für "vertrauenswürdige" Netzwerke entwickelt. Es bietet von sich aus keinen Mechanismus, um Benutzer zu authentifizieren. Der NFS-Server überlässt die Zugangskontrolle komplett den Clients. Ein Benutzer, der Root-Rechte an einem Client erlangen kann, ist somit in der Lage, Zugriff auf jede beliebige Datei im NFS-Share zu bekommen (im Zweifelsfall, in dem er sich mit su oder sudo als richtiger Benutzer ausgibt). Dieses grundlegende Vertrauen wurde als Designfehler "identifiziert" und war lange Zeit ein Grund, NFS nicht einzusetzen.

Mit NFS4 wurde dieses Problem durch die Möglichkeit der Kerberos-Authentifizierung behoben.

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.

  • Ein Kerberos Server muss vorhanden sein und auf den Clients muss die Kerberos-Authentifizierung aktiviert sein. Am Client 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.

Kerberos - Konfiguration

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 müssen 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.

Vergleichstest

Hinweis:

Alle Messungen erfolgten zwischen einem 3.0 GHz Core2Duo (Client, Bonnie++) und einem 2.5Ghz Core2Duo (Server, verschlüsseltes RAID, Nettoleistung 120MB/s) und Netzwerk Gigabit-LAN (max. Durchsatz theoretisch: 128 MB/s). Auffällig ist der extreme Leistungsabfall bei krb5p. Dieses Verhalten sollte aber besser werden, sobald man eine NFS-Version einsetzt, die AES unterstützt, da die AES-Kernel-Implementierung mittlerweile multicore-fähig ist.

Quelle: Launchpad Bugreport 🇬🇧

Verfügbare sec-Modi
Modus Beschreibung Anmerkung Durchsatz
krb5 Server und Client werden bei jedem RPC-Call gegeneinander authentifiziert. Es findet keine Verschlüsselung statt. Dieser Modus dient rein zur Authentifizierung. Ein Angreifer kann Datenpakete verändern bzw. einschleusen. Er kann zusätzlich den kompletten Datenstrom mitlesen. 95.1 MB/s
krb5i Neben der Kerberos-Authentifizierung wird ein MD5-Hash über das komplette RPC-Paket gebildet (RPC-Methode und NFS-Parameter / -Rückgabe). Ein Angreifer kann keine Datenpakete verändern oder einschleusen, kann jedoch immer noch "mitlesen". 94,5 MB/s
krb5p Jedes Paket wird authentifiziert und signiert. Zusätzlich werden die NFS-Parameter / -Rückgabewerte noch verschlüsselt. Ein Angreifer kann zwar immer noch ermitteln, welche RPC-Operationen ausgeführt werden, jedoch nicht mehr, welche Parameter übergeben werden. 23.8 MB/s

Will man dem Client die Wahl der Integrität überlassen, kann man auch mehrere Modi zur Auswahl stellen.

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

Im gezeigten Fall kann jeder Client entscheiden, ob der Mount mit krb5i oder krb5p hergestellt werden soll.

NFS - Konfiguration - Client

Hinweis:

Bis zur Verwendung von Ubuntu 18.04 gelten folgende Schritte

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 

Hinweis:

Ab Ubuntu 18.04 muss man wie folgt vorgehen.

Systemd sollte eigentlich alle nötigen Dienste eigenständig starten. Deshalb ist das Init-Script nfs-common und der Service nfs-common totgelegt. Der rpc-gssd Service setzt jedoch die Datei /etc/krb5.keytab vorraus. Nach dem erstellen dieser Datei kann man den rpc-gssd starten.

sudo service rpc-gssd 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 

Diese Revision wurde am 3. Mai 2021 07:25 von frustschieber erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Server, Netzwerk, System, Internet, Sicherheit, ungetestet