Workshop: Netzwerk-Dateisysteme auf dem Prüfstand

Navigieren im Datenmeer

,
Explosionsartig wachsende Datenbestände fordern von IT-Verantwortlichen ein Umdenken. Bei unternehmenskritischen Daten, die es zu nutzen und zu schützen gilt, steht und fällt beides oft mit dem Dateisystem. In unserem Workshop zeigen wir, was moderne verteilte Dateisysteme in dieser Hinsicht leisten.
Zum Jahresende dreht sich im IT-Administrator alles rund um das Thema 'Client- und Applikations-Virtualisierung'. So lesen Sie in der Dezember-Ausgabe, welche ... (mehr)

Die Wahl eines geeigneten Netzwerkdateisystems zählt zu den wichtigsten Entscheidungen beim Aufbau einer Netzwerktopologie. Die Datensicherheit, die Leistungsbereitschaft und die Wartungsfähigkeit der gesamten Infrastruktur stehen und fallen mit den Eigenschaften des verteilten Dateisystems. Da eine Datenmigration mit erheblichen Risiken verbunden ist, muss ein Netzwerkdateisystem den Anforderungen des jeweiligen Deployment-Szenarios auf lange Sicht gerecht werden.

Konzepte verteilter Dateisysteme

Ein Netzwerkdateisystem (Network File System, NFS) beziehungsweise ein verteiltes Dateisystem (Distributed File System, DFS) stellt den Zugriff auf Daten nicht auf Blockebene, sondern über Netzwerkprotokolle bereit, sodass ein oder mehrere Clients parallel auf gemeinsam vorgehaltene Datenbestände zugreifen können. Die Daten werden nach denselben Verfahren wie bei einem lokalen Dateisystem genutzt (etwa mounten/unmounten oder Verzeichnisse auflisten). Beispiele umfassen das quelloffene NFS von Sun/Oracle, CIFS (Microsofts Common Internet File System), Apache HA-HDFS und XtreemFS. Netzwerkdateisysteme sind allerdings weder die einzigen "verteilten" Dateisysteme noch die einzigen Dateisysteme, die via Netzwerk erreichbar sind.

Kann ein Dateisystem durch mehrere Server gleichzeitig gemountet werden, spricht man von einem Cluster-Dateisystem (Clustered File System). Ein Beispiel hierfür ist IBMs CNFS auf Basis von GPFS (General Parallel File System) mit der Fähigkeit, NFS-Shares bereitzustellen.

Ein paralleles Dateisystem ist ein Cluster-Dateisystem, das die Daten auf mehrere Speichernodes verteilt, um Datenredundanz mit verbesserter Performance zu verbinden. Beispiele für ein paralleles Dateisystem sind IBMs General Parallel File System (GPFS) [1], BeeGFS/FhGFS (Fraunhofer) [2], Lustre [3] und pNFS [4], eine optionale Erweiterung zu NFS 4.1. Um zu verhindern, dass verschiedene Server sich gegenseitig die Daten überschreiben, werden ihre Zugriffe gewöhnlich von einem Metadatenserver beaufsichtigt beziehungsweise ausgeführt.

Eine andere interessante Variante verteilter Dateisysteme stellen die sogenannten globalen Dateisysteme dar. Dabei handelt es sich um einen verteilten, virtuellen Adressbereich für die Datensicherung, der auf mehreren lokalen Dateisystemen aufsetzt, um den Clients transparente Zugriffe auf verteilte Daten, typischerweise auf Block-Ebene, zu gewähren. Ein Objekt in einem globalen Dateisystem hat ein und denselben Pfad – unabhängig davon, von welchem System der Zugriff stattfindet – und ist für laufende Applikationen vom lokalen Dateisystem in der Regel nicht zu unterscheiden (transparenter Zugriff). Moderne globale Dateisysteme binden inzwischen auch Unterstützung für Cloud-Speicher ein. Beispiele für ein globales Dateisystem sind das quelloffene GFS2 (Global File System 2) und FedFS (Federated File System) für unveränderte NFSv4/4.1-Clients. Als das beliebteste verteilte Dateisystem gilt bei Weitem das quelloffene NFS aus dem Hause Sun Microsystems/Oracle, das so genannte "Network File System".

Bei NFS kommt es auf die Version an

Bei NFS handelt es sich um ein quelloffenes Netzwerkdateisystem und Protokoll zum Zugriff auf entfernt vorgehaltene Datenbestände via Netzwerk auf der Basis von RPC-Aufrufen. Um ein Dateisystem von einem entfernten Rechner mittels NFS zu mounten, muss der betreffende Verzeichnisbaum oder das Volume zuvor von dem jeweiligen Host exportiert werden. Heute eine unverzichtbare Komponente einer jeden Linux-Distribution der Enterprise-Klasse, erblickte NFS das Licht der Welt im Jahre 1984 in den Computerlaboren von Sun Microsystems. Sun Microsystems setzte NFS anfangs allerdings nur intern ein. Erst mit der Version 2 ging das Produkt im Jahre 1989 an die breite Öffentlichkeit.

Die Version 3 folgte im Jahre 1995 und bot für die damaligen Verhältnisse außergewöhnliche Features wie die Unterstützung für Dateien jenseits von 2 GByte. Die aktuelle Version von NFS trägt die Nummer 4.1. Zwischen NFS 4.1 und seinem Vorgänger liegt ein ganzes Jahrzehnt Entwicklung, doch die Popularität von NFS 3 hat kaum nachgelassen.

Bild 2: Bei pNFS verarbeitet der Server die Metadaten, während autorisierte Clients direkt auf den Massenspeicher zugreifen.

In seiner viel beachteten Rede auf dem Red Hat Summit vor zwei Jahren ließ Steve Dickson die Alarmglocken läuten: Zwar weise NFS nach wie vor die größte Verbreitung unter verteilten Dateisystemen auf, doch die Mehrheit seiner Anwender würde ihre Daten und ihre Netzwerksicherheit unnötig gravierenden Risiken aussetzen, weil sie immer noch die Version 3 des Protokolls (RFC 1813) aus dem Jahre 1995 im Betrieb hätte. Trotz dieser Warnrufe blieb ein groß angelegter Umstieg auf NFS 4 und dann auf die Version 4.1 aus und so ist das Problem heute im Großen und Ganzen genau das Gleiche: Ausgiebig dokumentierte Schwachstellen von NFS 3 (und NFS 4.0) erleichtern Hackern die Zunft viel mehr als es sein müsste.

Die Zugriffskontrolle in NFS 3 verlässt sich ausschließlich auf Host-basierte Authentifizierung; personenbezogene Zugangsdaten werden überhaupt nicht berücksichtigt. Sollte ein Angreifer den DNS-Server manipulieren und sich mit einem auf der DNS-Ebene gefälschten FQDN-Namen als ein berechtigter Host ausgeben, bekommt er automatischen Zugriff auf alle Daten, die via NFS exportiert werden. In NFS 4 konnte diese kritische Sicherheitslücke beseitigt werden, indem die Umsetzung des RPCSEC_GSS-Kernelmoduls, der Sicherheitsvorkehrungen der Kerberos 5 GSS-API, SPKM-3 und LIPKEY ins Pflichtenheft geschrieben wurde. NFSv4 erzwingt demnach die Authentifizierung individueller Benutzer und nicht lediglich des NFS-Clients. Der kompromittierte rpc.mountd-Daemon wurde komplett eliminiert. Darüber hinaus debütierte NFSv4 mit nativer Unterstützung für Zugriffskontrolllisten (Access Control Lists, ACLs). Diese Implementierung basiert allerdings auf Microsofts Windows NT-Technologie und nicht auf dem POSIX-Modell.

Von den Schwachstellen in NFS 3 sind immer noch zahlreiche mittelständische Unternehmen betroffen, die das Upgrade aufgrund einer Knappheit an Fachpersonal hinausgezögert haben. Großunternehmen haben die Migration inzwischen längst vollzogen, aber sie standen ja auch kaum vor denselben Herausforderungen wie der Mittelstand. Dieser stellt damit sowohl eine deutlich interessantere als auch eine leichtere Beute für Hacker dar. Die vermeintlichen Kosteneinsparungen durch immer wieder aufgeschobene Upgrades erkaufen sich die betroffenen Anwender mit gravierenden Sicherheitslücken.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite