NFS-Server

Dieser Artikel ist Teil der Artikelserie über NFS. NFS steht für Network File System und dies ist ein bei Linux und anderen Arten von Unix gebräuchliches Protokoll für den Austausch von Dateien über das Netzwerk. Für technische Details und Grundlagen siehe die Übersichten^[1]^[2].

Dieser Artikel behandelt Themen, die ein Verwalter eines NFS-Servers kennen, beachten und bei der Konfiguration seines Servers beachten sollte, damit der Spitzname von NFS als "Nightmare File System" nicht ein weiteres Mal Realität wird.

Installation¶

Siehe Artikel: ▶ NFS

Konfiguration¶

Die Konfiguration erfolgt über einfache Textdateien in den Ordnern /etc/, /etc/nfs.conf.d/ und /etc/exports.d/. Die Konfigurationsdateien können mit einem Editor mit Root-Rechten^[6] bearbeitet werden. Alle Konfigurationsdateien müssen root als Eigentümer und Gruppe gehören und die Dateiberechtigungen 0644 haben bzw. 0755 für die genannten Ordner.

Jede Zeile muss mit einem Zeilenumbruch (ASCII 10) enden. Um das sicherzustellen, sollte man jede Konfigurationsdatei mit einer Leerzeile oder einem Kommentar beenden.

Die zulässigen Inhalte und weitere Details kann man den Manpages oder den auszugsweise den hier folgenden Abschnitten entnehmen:

man nfs.conf

man exports

Nach jeder Änderung der Konfiguration die Freigaben aktualisieren und den NFS-Server neu starten^[4]^[5]^[6]:

sudo exportfs -alr

systemctl restart nfs-server.service

Eigenschaften des Servers¶

Die Konfiguration eines NFS-Servers – ausgenommen die Freigaben – erfolgt über mehrere Dateien:

Die Datei /etc/nfs.conf enthält die primäre Konfiguration, die zuerst gelesen und dann durch weitere Konfigurationsdateien ergänzt oder überschrieben werden kann. Man kann in dieser Datei selbst Änderungen vornehmen, es wird jedoch empfohlen, eigene Konfigurationen nur in den sekundären Konfigurationsdateien vorzunehmen.
Im Ordner /etc/nfs.conf.d/ enthaltene Dateien mit Namensschema *.conf sind die sekundären Konfigurationen, die nach der primären gelesen werden. Abgesehen davon gibt es keinen Mechanismus zur Steuerung der Reihenfolge des Lesens.

Diese Konfigurationsdateien sind im bekannten INI-Format strukurierte Textdateien. Zulässige Zeilen sind:

Überschriften für Sektionen in eckigen Klammern, beispielsweise: [nfsd]
Initialisierungsdaten in der Form: Schlüssel = Wert
Kommentarzeilen, die in der ersten Spalte mit dem Zeichen # oder mit ; beginnen. Kommentare werden ignoriert. Zeilenendkommentare sich aber nicht erlaubt.
Leerzeilen, die entweder gar nichts oder nur Leerzeichen und Tabulatoren enthalten. Lehrzeilen werden auch ignoriert.

Die aktuelle Konfiguration kann man sich bequem anzeigen lassen:

nfsconf --dump

Beispielausgabe:

[general]
 pipefs-directory = /run/rpc_pipefs

[mountd]
 manage-gids = y

Freigaben¶

Die Freigaben ("exports") definiert man in folgenden Dateien:

Datei /etc/exports
Ordner /etc/exports.d/ mit Dateien im Namensschema *.exports: Solche Dateien kann man optional zusätzlich verwenden. Ihr Name darf nicht mit einem Punkt beginnen.

In Konfigurationsdateien für Freigaben zulässig sind Kommentarzeilen, Leerzeilen und Datenzeilen. Jede Datenzeile besteht aus mindestens zwei Feldern, die durch Whitespace (Leerzeichen und/oder Tabulator) voneinander getrennt sind; innerhalb eines Feldes ist Whitespace unzulässig:

Das erste Feld enthält den freizugebenden Ordner als absoluten Pfad aus Sicht des Betriebssystems.
Das zweite und optional folgende Felder enthalten jeweils eine Spezifikation für einen Rechner oder eine Gruppe von Rechnern, welche auf die Freigabe im ersten Feld zugreifen dürfen, sowie optional eine Liste von Optionen, welche die Art des Zugriffs beschreiben.

Beispiel für eine Konfigurationsdatei für Freigaben:

/srv/nfs	-rw,subtree_check,insecure	FD00::/8    *.fritz.box
/home		-no_subtree_check,insecure      fd00::/8    *.fritz.box(mp)

Dieses Beispiel illustriert auch die mit Bindestrich eingeleitete Definition gemeinsamer Optionen für alle Rechnerspezifikationen.

Rechner spezifizieren¶

Die zum Zugriff berechtigten Rechner (Client) kann man mit folgenden Methoden angeben:

Rechnername, beispielsweise: tusnelda
DNS-Name, beispielsweise: tusnelda.fritz.box oder tusnelda.local oder tusnelda.example.com
DNS-Name mit Jokerzeichen *, beispielsweise: *.fritz.box oder *.local oder *.example.com

Voraussetzung für die Funktion vorstehender Methoden: Der Server muss die IP-Adresse aus der Anfrage zurück in einen DNS-Namen übersetzen können (dazu benötigt man PTR-Records im DNS-Server) und so ermittelten Namen müssen der Spezifikation entsprechen. Während des Hochlaufs des Rechners funktioniert manchmal die Namensauflösung noch nicht. Wenn man bereits in dieser frühen Phase den NFS-Server starten möchte, verwendet man daher besser IP-Adressen zur Identifizierung:

IPv4-Adresse
IPv6-Adresse: Diese dürfen nicht in eckigen Klammern [] stehen.
Adressbereiche, also IP-Adresse mit Netzmaske, beispielsweise: 10.0.0.0/255.240.0.0 oder 192.168.0.0/16 oder fd00::/8

Der Client erhält Zugriff, wenn er eine IP-Adresse aus den genannten Bereichen benutzt.

Weitere Methoden:

Eine Netzgruppe (netgroup), die man in der Datei /etc/netgroup spezifiziert hat. Es wird aus den Tripeln jeweils nur die erste Komponente ausgewertet.
Das Zeichen *: Damit erlaubt man weltweit jedem Rechner den Zugriff. Effektiv schalten man damit die Prüfung ab, ob ein Rechner zum Zugriff berechtigt ist.
Das Zeichen - (Bindestrich), gefolgt von einer (nicht in Klammern stehenden!) Liste von Optionen: Damit selektiert man zunächst keinen zum Zugriff berechtigten Rechner, sondern Vorgaben für die darauf folgenden Rechner.

Optionsliste¶

Dies ist eine mit Kommata getrennte Liste von Optionen aus folgender Tabelle 1. Man muss die Liste in runde Klammern () setzen und ohne trennendes Leerzeichen an die Spezifikation des Rechners anhängen.

Tabelle 1: Ausgewählte Optionen für Freigaben per NFSv4
Option		Beschreibung
Vorgabe	Alternative	Beschreibung
ro	rw	Normalerweise werden Ordner schreibgeschützt freigegeben. Wenn man Erstellung/Änderung/Löschen von Dateien und Ordnern erlauben möchte, muss man den Schutz mit `rw` ausschalten; dann gelten für tatsächliches Schreiben die jeweiligen Dateirechte von Unix sowie ggf. die aus POSIX- und NFSv4-ACLs.
sync	async	Mit der Vorgabe `sync` (ab Version 1.0.0) beantwortet der Server die Anfrage eines Clients erst nachdem alle damit verbundenen Änderungen auch tatsächlich gespeichert wurden. Dieses sichere Verhalten kann man mit `async` abschalten und damit die Performance von Schreibvorgängen auf Kosten der Sicherheit steigern. So etwas sollte man natürlich nur bei unwichtigen Daten erlauben.
secure	insecure	Die Vorgabe `secure` bedeutet, dass der Client einen privilegierten Port (d.h. in der Regel einen unter 1024) benutzen muss. Das kann man man mit `insecure` ausschalten. Der Name dieser Option kann in die Irre führen, tatsächlich wird ein NFS-Server in der Praxis durch Verwendung von `insecure` nicht unsicherer, als er es ohnehin schon ist.
no_subtree_check	subtree_check	Schaltet den sog. "subtree check" aus oder ein. Abhängig von der konkreten Nutzung der Freigabe kann beides gut oder schlecht sein. Konsultiere die Manpage für weitere Details. Vorgabe ist `no_subtree_check` ab Version 1.0.0, man muss aber eine der beiden Möglichkeiten explizit angeben, um nervige Fehlermeldungen zu vermeiden.
root_squash	no_root_squash	Normalerweise wird jede von einem Benutzer mit UID=0 stammende Anfrage so umgesetzt, als wenn sie von einem Benutzer mit der über `anonuid` spezifizierten UID und mit `anongid` spezifizierten GID stammen würde. Also ein `root` auf dem Client wird zu einem `nobody` auf dem Server und hat somit keine Sonderrechte auf dem Server. Man kann dieses Sicherheitsfeature ("root squashing") mit `no_root_squash` abschalten, was in den allermeisten Fällen eine sehr schlechte Idee ist.
no_all_squash	all_squash	Normalerweise wird eine von einem Benutzer mit UID≠0 stammende Anfrage nicht umgesetzt, d.h. jeder Benutzer agiert auf dem Server mit derselben UID und GID wie auf dem anfragendem Rechner. Dies ist nur dann sinnvoll, wenn auf beiden Rechnern die numerische UID auch dieselbe Person bzw. GID dieselbe Benutzergruppe identifiziert; dies trifft in der Regel ohne besondere Maßnahmen meist nicht zu. Mit der Option `all_sqash` kann man eine Umsetzung auf die mit `anonuid` bzw. `anongid` angegebene UID bzw. GID erzwingen.
anonuid=65534	anonuid=GANZZAHL	Definition der Zielperson bei Squash. 0 ≤ GANZZAHL < 2³²
anongid=65534	anongid=GANZZAHL	Definition der Zielgruppe bei Squash. 0 ≤ GANZZAHL < 2³²
sec=sys	sec=krb5p:krb5i:krb5:sys	Auswahl der Sicherheitsstufe(n): Der Wert der Option ist eine mit Doppelpunkten getrennte Liste von Sicherheitsstufen. Die Option kann mehrmals angegeben werden und man kann für jede Sicherheitsstufe danach unterschiedliche Werte für `ro/rw`, `root_squash` und `all_squash` angeben. Details siehe Manpage und nachfolgende Diskussion im Kapitel Sicherheit.
wdelay	no_wdelay	Diese Optionen kann man zwar bei einem NFSv4-Server definieren, sie sind aber hier entweder wirkungslos oder von geringem Nutzen. Details siehe Manpage.
hide	nohide
nocrossmnt	crossmnt
	nordirplus
auth_nlm secure_locks	no_auth_nlm no_secure_locks	Normalerweise verlangt ein moderner NFS-Server bei der Anforderung einer Dateisperre eine Authentifizierung des Clients. Früher war das nicht erforderlich und es gibt noch viele Clients, die das nicht beherrschen, daher kann man es beim Server abschalten. Besser als dieser Notbehelf ist natürlich Verwendung eines modernen Clients.
	mountpoint mp mountpoint=PFAD mp=PFAD	Der freizugebende Ordner wird nur dann exportiert, wenn er auch ein Einbindepunkt ist bzw. wenn genau das angegebene Dateisystem hier eingebunden wurde. Details siehe nachfolgende Diskussion im Kapitel Sicherheit.

Weitere Optionen: fsid, refer, replicas, pnfs, security_label

Sicherheit¶

NFS ist unsicher, außer man tut etwas dagegen. Als ersten Schritt sollte man sich über die Nachteile von NFS informieren, und dabei will dieser Artikel unterstützen.

Daten-Integrität¶

Die Manpage nfs erläutert, dass beim Austausch von Dateien bei Verwendung des Protokollstacks

NFS in UDP in IP über Gigabit-Ethernet

es zwangsläufig zu Fragmentierung der Pakete auf der Ebene IP kommt, und wegen der großen Anzahl der in kurzer Zeit übertragbaren Fragmente der Zähler für Fragmente überläuft, und damit kommt es zwangsläufig zum falschen Zusammenbau der Pakete auf Empfängerseite. Die übertragenen Dateien werden also beschädigt. Außerdem verringert natürlich die Fragmentierung die Performance.

Gegenmaßnahmen:

⚓︎ Man verzichtet auf das Protokoll NFSv3 und erst recht auf noch ältere Versionen und betreibt einen reinen NFSv4-Server. NFSv4 verwendet nur TCP, bei dem das beschriebene fehlerhafte Verhalten nicht auftreten kann.
- Das ist technisch einfach über eine Konfigurationsdatei auf dem Server machbar:
```
[nfsd]
vers2 = off
vers3 = off
```
- In der Praxis ist es nicht ganz so einfach, weil viele Client-Programme das Protokoll NFSv4 gar nicht oder nur unvollständig oder nur fehlerhaft beherrschen. Viele Benutzer werden sich mit Supportanfragen melden.
⚓︎ Man verzichtet auf UDP.
- Konfigurationsdatei:
```
[nfsd]
UDP = off
```
- Dies erzwingt beim Protokoll NFSv3 die Verwendung von TCP und ändert nichts bei NFSv4, das ohnehin niemals UDP verwendet.
Man verwendet auf der Ebene Ethernet Jumbo-Frames und reduziert damit die Fragmentierung auf Ebene IP.

Vertraulichkeit¶

Das Protokoll NFS, auch NFSv4, überträgt Daten standardmäßig im Klartext und bietet damit keinerlei Schutz gegen Abhören. Vertrauliche Informationen sollte man daher nur dann per NFS übertragen, wenn das Netzwerk auf andere Weise (z.B. VPN) gegen Abhören gesichert wurde und Unbefugte keinen Zugang zum Netzwerk haben. Der letzte Punkt lässt sich bei Verwendung eines WLANs nicht realisieren.

⚓︎ NFSv4 bietet aber Möglichkeiten, durch zusätzlichen Aufwand die Vertraulichkeit zu verbessern. Die Standardmethode hierzu ist die Verwendung eines separaten Kerberos-Servers zur Identifizierung und Authentifizierung und Bereitstellung einer Infrastruktur zur Verschlüsselung des Datenverkehrs. ▶ NFS mit Kerberos sichern

⚓︎ Einrichtung und kompetenter Betrieb eines Kerberos-Servers ist allerdings eine herausfordernde Aufgabe, die in der Regel Privatanwender und kleine Unternehmen überfordern kann. Eine einfach einzurichtende Alternative kann sein, den NFSv4-Verkehr über SSH zu tunneln. Erst bei NFSv4 ist wegen dessen Beschränkung auf einen Port diese Technik einfach zu nutzen, obwohl sie auch früher schon möglich war. ▶ Howto/NFSv4 mit SSH sichern

Zugriffsschutz¶

Das Protokoll NFS, auch NFSv4, bietet selber keinen heutigen Ansprüchen entsprechenden Schutz vor dem Zugriff durch Unbefugte:

IP-Adressen lassen sich leicht fälschen.
DNS-Namen können durch Manipulation von DNS-Servern Unbefugten die Nutzung bestimmter IP-Adressen ermöglichen.
Kennungen für Benutzer und Gruppen sind leicht fälschbar.

Diese Angriffe erfordern entsprechende technische Kenntnisse und Mittel, die zwar nicht jedem zur Verfügung stehen, aber es gilt als sicher, dass kriminelle Hacker und in staatlichem Auftrag handelnde Angreifer darüber verfügen.

Wegen der leichten Fälschbarkeit von Benutzer-Kennungen hat ein Angreifer, der bereits regulären Zugriff auf eine Freigabe hat, damit auch Zugriff auf jeden Ordner und jede Datei, die nicht root gehört – und wenn man "root squashing" abgeschaltet hat, dann auch auf diese.

Der Zugriff auf fremde Dateien kann auch unabsichtlich ermöglicht werden, wenn Client und Server UID oder dieselbe GID unterschiedlichen Personen zugeordnet haben.

Schließlich ist bei NFS aus technischen Gründen unmöglich, nur Teile eines Dateisystems freizugeben. Man kann so etwas zwar in den Exports definieren, aber nicht wirksam verhindern, dass ein Benutzer mit Hackern bekannten Techniken aus dem regulär exportierten Bereich ausbrechen und auf nicht exportierte Dateien im betreffenden Dateisystem zugreifen. Dieses unerwünschte Verhalten kann man mit der Option subtree_check etwas abmildern, aber nicht vollständig unterbinden. Aus diesem Grund geben Profis grundsätzlich immer nur vollständige Dateisysteme frei, die sie auf die exportierten Order einbinden ("mounten") und sichern über die Option mountpoint ab, dass die Einbindung auch tatsächlich erfolgreich erfolgte.

Für viele der vorstehend genannten Probleme ist bei NTFSv4 die Verwendung eines zusätzlich Kerberos-Servers die etablierte Standardlösung; für kleine Aufgaben können auch SSH-Tunnel helfen.

Checkliste¶

Das Protokoll UDP für NFS sperren.
Nach Möglichkeit nur die Version 4 des NFS-Protokolls benutzen.
Die zum Zugriff berechtigten Clients so weit wie möglich einschränken. Am besten zur Spezifikation der Rechner nur einzelne IP-Adressen verwenden.
Auf Server und allen berechtigten Clients müssen die Kennungen für Benutzer und Gruppen dieselben Bedeutung haben. Das ist in der Regel meist nicht der Fall und nur mit großem Aufwand erreichbar.
Die standardmäßig aktivierte Vorsichtsmaßnahme "root squashing" nicht abschalten.
Den Zugriff auf den Server nur aus als sicher geltenden Netzwerken erlauben. Falls dies nicht möglich ist:
- VLAN / VPN / IPSec verwenden,
- oder Verkehr tunneln über SSH (▶ NFSv4 mit SSH sichern) / Wireguard / Stunnel,
- oder zukünftig TLS nach RFC9289 verwenden, sobald es als Software verfügbar ist,
- oder Kerberos mit den Sicherheitsstufen krb5i oder krb5p benutzen (▶ NFS mit Kerberos sichern
Nach Möglichkeit Dateisysteme vollständig freigeben, d.h. der jeweilige Export ist die Wurzel des auf den Export eingebundenen Dateisystems; dies mit der Option mountpoint absichern. Wenn dies nicht möglich ist, unbedingt die Option subtree_check verwenden.
Optional dem NFS-Server eine Firewall vorschalten. Diese ist bei NFSv4 im Vergleich zu älteren Versionen drastisch vereinfacht, da nur noch der Port 2049/tcp abgesichert werden muss.