Wenn mehrere Linux- oder Unix-Rechner via Netzwerk Daten tauschen sollen, gelingt das am einfachsten mit NFS.

Nach dem Neukauf eines PCs bleibt meist ein älteres Modell mehr oder weniger verwaist zurück. Das eignet sich in der Regel hervorragend, dem Heimnetz als Dateiserver zu dienen. Das von Sun bereits 1985 in der Version 2 veröffentlichte, mittlerweile von der IETF weiterentwickelte Netzwerkdateisystem NFS (Network File System) arbeitet nach dem Client/Server-Prinzip: Ein Server stellt Speicherplatz für die Clients bereit, die diesen ins lokale Dateisystem einhängen.

Die Entwickler bei Sun implementierten NFS mit Hilfe entfernter Funktionsaufrufe (RPC)[4]. Server und Client kommunizieren mit Hilfe von IP-Adresse und Port miteinander. NFS setzt sich aus mehreren RPC-basierten Diensten zusammen, die als einzelne Daemons laufen. Ein Dienst namens Portmapper verwaltet die Portnummern der laufenden RPC-Dienste, um zusätzlichen Konfigurationsaufwand durch die statische Vergabe von Portnummern zu vermeiden. Dieser Dienst lauscht auf dem Port 111.

Die Aufgabe eines NFS-Servers teilen sich der NFS-Daemon (rpc.nfsd), der auf Port 2049 lauscht und IO-Anfragen bearbeitet, sowie der Mount-Daemon (rpc.mountd), der beim Einhängen eines Dateisystems hilfreich zur Seite steht. Die weiteren Dienste Network Lock Manager (rpc.lockd) und Network Status Monitor (rpc.statd) handhaben Dateisperren. Zudem gibt es einen Quota-Dienst (rpc.rquotad im Paket quota).

Den eigentlichen NFS-Dienst gibt es in zwei Ausführungen: Als Kernel-Treiber oder als reines Userspace-Programm. Durchgesetzt hat sich der schnellere NFS-Kernel-Server. Der Userspace-Server unterstützt weder Dateien größer 2 GByte noch die genannten Dienste für Dateisperren.

Ping-Pong

Möchte ein Client ein entferntes Verzeichnis mounten, fragt er den Portmapper auf dem Server nach dem Port des Mount-Daemons. Der Portmapper liefert den Port und der Client schickt dem Mount-Daemon eine Mount-Anfrage. Dieser prüft, ob es den Export gibt und der Client die notwendigen Rechte besitzt, diesen zu mounten. Dabei prüft NFS v3 von Haus aus nur, ob die Liste der erlaubten IP-Adressen und Netzwerkbereiche auch die IP-Adresse des Clients enthält.

Ist der Client berechtigt, fragt der Mount-Daemon den NFS-Daemon nach dem Dateihandle für das entsprechende Verzeichnis. Der Mount-Daemon liefert das Handle, das der Client dann für weitere Anfragen verwendet, wie etwas das Auflisten von Verzeichnissen. Für jedes weitere Verzeichnis und jede weitere Datei, die er öffnet, enthält er vom Server ein zusätzliches Dateihandle.

NFS einrichten

Die Konfiguration eines NFS-v3-Servers fällt bei den gängigen Distributionen erfreulich leicht. Sie installieren die Pakete portmap und nfs-utils sowie – falls Sie Suse verwenden – yast-nfs-server und yast-nfs-client. Als Debian- oder Ubuntu-Anwender richten Sie die Pakete nfs-common und nfs-kernel-server ein.

Die Distributionskernel kommen in der Regel mit vollständigen NFS-v3-Support daher. Kompilieren Sie Ihren eigenen Kernel, so aktivieren Sie unter Filesystems | Network File Systems die entsprechenden Optionen (Abbildung 1).

NFS server support für den Server und NFS file system support für den Client.” width=”300″ height=”187″ /> Abbildung 1: Beim Übersetzen eigener Kernle aktivieren Sie für NFS die Optionen NFS server support für den Server und NFS file system support für den Client.

Gängige Distributionen starten die für NFS benötigten Dienste und Kernel-Module über Init-Skripte. Bei Debian heißen diese nfs-kernel-server und portmap, bei Suse nfs-utils und portmap. Unter Suse aktivieren Sie den Dienst am besten mit YaST unter Netzwerkdienste | NFS-Server und schalten ihn dabei auch gleich in der Personal Firewall frei (Abbildung 2). Debian und Ubuntu aktivieren die Dienste nach der Installation automatisch. Von Hand starten Sie sie durch Aufruf des Init-Skriptes: /etc/init.d/nfs-kernel-server start. Mit rpcinfo -p von portmap erhalten Sie eine Liste, welche Dienste auf welchen Ports laufen.

Abbildung 2: YaST bietet beim Starten des NFS-Servers praktischerweise gleich mit an, in der Firewall den passenden Port für den Dienst zu öffnen.

Für den Client brauchen Sie einen Kernel mit NFS filesystem support (siehe Abbildung 1). Der Befehl cat /proc/filesystems | grep nfs zeigt die Verfügbarkeit des Dateisystems, modprobe nfs lädt es gegebenenfalls nach. Installieren Sie zudem für Ubuntu oder Debian das Paket nfs-common und für Suse nfs-utils.

Exportieren, importieren

Für den ersten Test exportieren Sie mit dem Befehl exportfs -o rw,sync 192.168.1.0/8:/tmp das Verzeichnis /tmp an alle Clients im Netzwerk 192.168.1.0/24 für Lese- und Schreibzugriff (siehe Tabelle “Export-Optionen”).

Auf dem Client zeigt der Befehl showmount -e NFS-Server eine Liste der Exports. Mit mount -o intr NFS-Server:/tmp /mnt/nfs mounten Sie auf dem Client den Export /tmp des Servers NFS-Server im Verzeichnis /mnt/nfs mit der Option intr (siehe Tabelle “Mount-Optionen”). Geben Sie keine Optionen für das Einhängen an, so wählt Linux sinnvolle Vorgaben, die Sie nach dem Mounten mit cat /proc/mounts anzeigen.

Mit umount /mnt/nfs melden Sie das Dateisystem wieder ab, und mit exportfs -u 192.168.1.0/24:/tmp beenden Sie auf dem Server den Export.

Exporte automatisieren

Es ist umständlich, Verzeichnisse jedes Mal von Hand zu exportieren und zu mounten. Tragen Sie Exports daher in /etc/exports ein (oder verwenden Sie YaST). Der Aufbau der Exports-Datei folgt dem Muster VerzeichnisHostoderNetz(Export-Optionen)HostoderNetz(Export-Optionen) … (siehe Listing 1). Mit exportfs -ra informieren Sie den Server über angefallenene Änderungen.

# /etc/exports auf Server deepdance
#
# Verzeichnis für einen einzelnen Host
/srv/deepdance  deepdance(rw,sync,no_subtree_check)
# Austausch-Verzeichnis
/srv/tausch     192.168.1.0/24(rw,sync,no_subtree_check) 127.0.0.0/8(rw,sync,no_subtree_check)
# Nur-Lesen-Verzeichnis
/srv/lesen      192.168.1.0/24(ro,sync,no_subtree_check) *.local(ro,sync,no_subtree_check)

Der NFS-Kernel-Server setzt die Rechte zwischen Client und Server anhand der numerischen Benutzer- und Gruppen-ID eins zu eins um. Das auf dem Server exportierte Verzeichnis muss für den Benutzer auf dem Client beschreibbar sein, wenn Sie Dateien speichern und Verzeichnisse anlegen möchten.

Arbeiten Sie mit mehreren Benutzern und Gruppen gleichen Namens auf unterschiedlichen Maschinen, sollten diese jeweils die gleiche Benutzer- und Gruppen-ID haben. Für Gruppenverzeichnisse eignet sich das setgid-Recht (s) [7]. Für Root wählt NFS standardmäßig den Benutzer und die Gruppe nobody, um den direkten Root-Zugriff auf den NFS-Server zu vermeiden (root_squash).

Auf der Client-Seite bietet /etc/fstab die Möglichkeit zur NFS-Automatisierung [8]: In der ersten Spalte der Datei steht der Export, in der zweiten das lokale Verzeichnis, in Spalte 3 als Dateisystem nfs, in Spalte 4 die gewünschten Mount-Optionen und in den nächsten beiden Spalten jeweils “0”, da weder ein etwaiges Backup via dump noch ein Dateisystemcheck auf dem Client Sinn machen (siehe Listing 2). Eine grafische Oberfläche zu Einrichtung bietet YaST unter Netzwerkdienste | NFS-Client.

# /etc/fstab
…
### NFS-Importe von deepdance
# NFS zu Haus
deepdance:/srv/tausch  /mnt/nfs-tausch  nfs  user,noauto,intr,rsize=8192,wsize=8192  0 0
# Nur lesen
deepdance:/srv/lesen   /mnt/nfs-lesen   nfs  user,noauto,intr,rsize=8192,wsize=8192  0 0
# Beispiel für Homeverzeichnisse
#deepdance:/srv/homes  /home            nfs  intr,rsize=8192,wsize=8192              0 0
…

Und die Sicherheit?

Die Entwickler von NFS hatten zentrale, geschützte Netzwerke im Sinn. NFS v3 bietet daher von Haus kaum Sicherheitsfeatures. So erlaubt das Erraten des passenden Dateihandles einem NFS-Client, auf Dateien von Exports zuzugreifen, die auf dem Client gar nicht gemountet sind. Sie vermeiden dies mit dem fehleranfälligen subtree_check[5] – oder indem Sie jeden Export auf ein eigenes lokales Dateisystem legen.

Verwenden Sie daher NFS v3 von vorneherein nur in durch Firewalls geschützten lokalen Netzen und sperren Sie externe Zugriffe auf NFS-Ports. Am einfachsten ist es, aus dem Internet nur Pakete zuzulassen, die Antworten auf ausgehende Verbindungen darstellen. Das sollte heutzutage die Standard-Konfiguration der meisten DSL-Router sein. Auch Iptables bietet mit dem Connection Tracker eine entsprechende Möglichkeit ([9],[10]).

Andere Ansätze basieren darauf, die RPC-Dienste für NFS mit festen Ports laufen und Pakete an diese Ports ausfiltern zu lassen ([11],[12]). Läuft NFS wie bei NFSv3 standardmäßig mit TCP, sperren Sie zumindest den TCP-Port 2049 sowie den TCP- und UDP-Port 111 des Portmappers für Zugriffe von außen. Die Personal Firewall von Suse kennt nur ein “Ganz oder gar nicht” und eignet sich nicht für Router, da sie nur den lokalen Host schützt.

Steht Ihnen keine Firewall zur Verfügung, bringt das Einschränken der Dienste via TCP-Wrapper ein wenig zusätzliche Sicherheit. Dazu sperren Sie diese Dienste erst einmal über die Datei /etc/hosts.deny global und geben Sie dann für das lokale Netzwerk über /etc/hosts.allow wieder frei (siehe Listings 3 und 4).

# /etc/hosts.deny
…
# Alle für NFS notwendigen
# Dienste global sperren
portmap    : ALL
mountd     : ALL
lockd      : ALL
statd      : ALL
rquotad    : ALL
…

# /etc/hosts.allow
…
# Alle für NFS notwendigen Dienste
# für lokales Netzwerk freigeben
portmap    : 192.168.1.0/24
mountd     : 192.168.1.0/24
lockd      : 192.168.1.0/24
statd      : 192.168.1.0/24
rquotad    : 192.168.1.0/24
…

Dies macht bei den Diensten lockd und statd auch für die NFS-Clients Sinn. Prüfen Sie, ob der jeweilige Dienst mittels TCP-Wrapper geschützt ist. Liefert zum Beispiel strings /sbin/portmap | grep hosts mindestens hosts_ctl zurück, sollte es klappen. Der Befehl rpcinfo -p NFS-Server teilt bei fehlender Berechtigung dann schlicht mit, keine entfernten Programme gefunden zu haben. Mit Debian Sarge und Suse 10.1 funktionierte es, mit der aktuellen Ausgabe von Debian Testing (Etch) und portmap 5-21 hingegen nicht.