Ein Filesystem-Protokoll ist kein Multimedia-Codec: Admins mögen kein Versions-Gehopse mit unberechenbaren Folgen. Infrastruktur hat zu funktionieren, Schluss. Wenn aber das Sicherheitsniveau der eingesetzten Lösung unter die Grasnarbe sinkt, steht die Frage im Raum: Wann umsteigen auf NFS 4?

Das Wort “Urgestein” hat einen leicht abwertenden Unterton. Modernität wird Menschen und Dingen, denen dieses geologische Etikett anheftet, jedenfalls nicht unterstellt. Unter den vielen Protokollen, die Linux implementiert hat, gilt NFS bei Freund und Feind ganz sicher als Urgestein. Das Network File System, in den 80ern von Sun entwickelt und als Standard eingereicht, frisst trotzdem nicht das Gnadenbrot des Gerontofachs. Denn außer SMB/Samba hat das heute bei der IETF angesiedelte Protokoll im flächendeckenden Produktivbetrieb keine Konkurrenz.

Das sollte nicht verwundern, denn das Geschäft der verteilten Dateisysteme ist konservativ: Kein Admin operiert ohne Not am Rückgrat seiner IT-Infrastruktur, nur um ein paar Features zu gewinnen. Und ob sich versprochene Performancevorteile beim Betrieb realer Applikationen tatsächlich einstellen – wer kann das wissen? Genau so erklärt sich der Umstand, dass die erdrückende Mehrheit der NFS-Anwender auf Version 3 setzen (siehe Artikel ab Seite 30), deren Spezifikation seit 1995 verabschiedeter Standard ist. Wenn man Revue passieren lässt, was sich in dieser Zeit bei Linux so geändert hat, macht das die Felsformation in der Computerbrandung noch beeindruckender.

Aus dem wertkonservativen NFS-Ansatz zu folgern, dass die Unix- und Linux-Menschheit auf alle Zeit Version 3 frönen wird, ist falsch. Dafür krankt das Protokoll zu sehr an mindestens einer strukturbedingten Schwäche: Die hostbasierte Authentifizierung, die sich auf IP-Adressen stützt und dem Gegenüber blind vertraut. Sie stammt aus einer Zeit als sich lokale Rechner noch gegenseitig vertrauen durften – meist hatten alle denselben Admin, kein User kannte das Root-Passwort und fremde Geräte am Netz gab es sowieso nicht.

Ich bin schon drin

Mit billigen PCs, löchrigen Desktop-Betriebssystemen, bootfähigen DVDs, privat eingeschleppten Notebooks und allgegenwärtigen WLANs ist die Zeit der hostbasierten Authentifizierung abgelaufen. Für NFS 3 brennt daher der Boden (siehe Hacker-Artikel ab Seite 44). Es liegt nahe, dass Version 4 – eine fertige Linux-Implementation gibt es längst – diese Schwäche zuerst beseitigt und userbasierte und verschlüsselte Mounts einführt (Seite 38). Sinnvollerweise verzichtet NFS 4 auf die alte UDP-Marotte und setzt komplett auf TCP. Das hilft Firewall-Admins und verlagert Kontrollmechanismen an die Stelle, an die sie gehören: Ins Transportprotokoll und nicht in die Anwendungsschicht.

Der Benchmark-Artikel auf Seite 40 belegt, dass auch die Performance-Verbesserungen wirken. Weniger Round-Trips, intelligentes Caching, besseres Locking und Compound Procedures treiben den Server unter realer Last voran. Wer bei NFS 3 die Tücken von Lock- und Stat-Daemon scheut, darf sich freuen dass Version 4 diese Dienste direkt ins Protokoll integriert. Bei der Gelegenheit hat sich leider auch die Syntax der Konfigurationsdateien geändert sowie die Art, wie Exports funktionieren (Seite 36). Als Folge dieser Komplettsanierung sind NFS 3 und 4 leider inkompatibel.

Ob sich es sich lohnt, die Klippen eines Umstiegs zu nehmen, hängt am Einsatzbereich. Stehen NFS-Server und -Clients in einem geschützten Netz, etwa in einem Serverraum den Anwender und Angreifer weder physikalisch noch per LAN betreten können, sind die Sicherheitsprobleme von NFS 3 kein starkes Argument. Je größer die Firma, desto gefährlicher wird aber das antiquierte Sicherheitsmodell. Gleichzeitig locken die Performance, das modernisierte Protokoll und die enger integrierten Dienste des NFS-4-Jünglings. Soll der NFS-Mount gar über das Internet laufen, scheidet das altertümliche NFS 3 sowieso aus.