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.

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.