NFS-Exports absichern: Netzwerkbeschränkung, Squash-Optionen und sec=krb5 statt AUTH_SYS

Ziel

Reduzieren, was ein NFS-Export seinen Clients glaubt: welche Hosts sich verbinden dürfen, welche UID/GID eine Anfrage für sich beanspruchen darf und ob der Server einen kryptografischen Identitätsnachweis verlangen kann, statt sich auf die Angabe des Clients zu verlassen.

Voraussetzungen

Ein bestehender Export in /etc/exports. Für die Kerberos-Option: ein funktionierendes Kerberos-Realm, ein nfs/<fqdn>-Schlüssel in der Keytab des Servers, gssproxy (oder das ältere rpc.svcgssd) auf dem Server und rpc.gssd auf den Clients; das einzurichten liegt ausserhalb dieses Artikels.

Schritte

1. Nie an alle Hosts exportieren. Gemäss exports(5) kann ein Export auf einen einzelnen Host, ein Namensmuster oder ein ganzes Subnetz als address/netmask ausgerichtet werden; jeden Export auf das kleinste Netzwerk beschränken, das ihn benötigt.
2. root_squash beibehalten (Standardeinstellung): Die Option bildet Anfragen von uid/gid 0 auf die anonyme uid/gid ab, sodass ein Client, der sich als root ausgibt, auf den Dateien des Servers kein root erhält. Sie verhindert nicht, dass root des Clients zu einer beliebigen anderen UID wechselt und als dieser Benutzer handelt. no_root_squash nur für einen bestimmten, vertrauenswürdigen Verwaltungshost setzen, der es wirklich benötigt.
3. Für Exports, bei denen gar keiner vom Client gelieferten UID vertraut werden soll – etwa ein gemeinsames Ablageverzeichnis –, all_squash verwenden, damit jede Anfrage unabhängig von der angegebenen UID auf das anonyme Konto abgebildet wird.
4. Den Hintergrund verstehen: Die Sicherheitshinweise in nfs(5) besagen, dass NFS-Server den Zugriff auf Dateidaten steuern, für die Authentifizierung aber auf ihre RPC-Implementierung angewiesen sind; die traditionelle Implementierung repräsentiert jeden Benutzer durch eine einfache Zahl, die der Client selbst liefert – der Server prüft sie nicht unabhängig.
5. Wo die Daten es rechtfertigen, Export und Client-Mount auf sec=krb5 (nur Authentifizierung), krb5i (zusätzlich Integrität) oder krb5p (zusätzlich Verschlüsselung) umstellen. nfs(5) beschreibt sec= als durch Doppelpunkte getrennte Liste eines oder mehrerer Sicherheitsverfahren (Flavors) für den Dateizugriff auf dem Mount, wobei krb5, krb5i und krb5p zu den gültigen Werten gehören; die Export-Zeile erhält eine entsprechende sec=-Option, um dies zu erzwingen.
6. Mit exportfs -ra neu exportieren und das tatsächlich ausgehandelte Verfahren prüfen, indem auf dem Client die Optionen des Mounts angesehen werden (cat /proc/mounts oder nfsstat -m).

Erwartetes Ergebnis

Mounts von ausserhalb des konfigurierten Netzwerks werden abgewiesen; ein Client mit UID 0 wird bei Exports mit Squashing auf das anonyme Konto abgebildet; führt der Export nur sec=krb5*-Verfahren auf, wird der Zugriff ohne gültige Kerberos-Credentials abgelehnt (beim Mounten oder beim ersten Zugriff), statt auf AUTH_SYS zurückzufallen.

Grenzen und Prüfbasis

AUTH_SYS gewährt jedem Benutzer auf jedem zugelassenen Client den Zugriff, den die jeweilige UID impliziert; root_squash betrifft nur root, und all_squash passt nur für Exports, bei denen keine benutzerbezogenen Eigentumsverhältnisse nötig sind. Kerberos-gesichertes NFS setzt korrekte Zeitsynchronisation und eine sauber gepflegte Keytab voraus – ein defektes KDC lässt Mounts ausfallen, statt dass der Betrieb unbemerkt eingeschränkt weiterläuft; Änderungen daher in einem Wartungsfenster testen. Vor dem Verschärfen eine Kopie der bisherigen /etc/exports aufbewahren.