Network File System/Sicherheit

Network File System/Sicherheit

NFS 3

NFS Version 3 und früher

NFS wurde geschaffen, um in Unix-Netzen Dateisysteme über Rechnergrenzen hinweg zugänglich zu machen

• Zur Zeit der Entwicklung von NFS waren solche Netze fast ausschließlich zentral verwaltet und die Rechner wurden zentral administriert, entsprechend wurde das Sicherheitskonzept gestaltet

Die Entwickler von NFS bei Sun Microsystems hatten ursprünglich vorgesehen, die Sicherheit als Aufgabe der RPC-Schicht zu implementieren

• Dazu wird RPC durch Secure-RPC ersetzt
• Die NFS-Protokolle selbst bleiben davon unberührt
• Secure-RPC hat allerdings keine weite Verbreitung gefunden, die Verwendung ist auch nicht bei allen Implementierungen möglich

Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von root durch IP-Adressen festgelegt), d. h

• der root-User eines Clientrechners kann auf alle Dateien zugreifen, die der Server an den Client exportiert, unabhängig von deren Zugriffsrechten
• Die Zugriffsrechte (der Benutzer) werden von NFS an den Client mitübertragen und vom Betriebssystem des jeweiligen Rechners ausgewertet und gegenüber den Benutzern durchgesetzt
• Die Konsistenz der Benutzerdatenbank auf den beteiligten Rechnern wird dabei z. B
• durch NIS erreicht

Heute sind Rechnernetze häufig offen und nur bedingt zentral administriert, d. h

• ein Angreifer kann relativ einfach entweder einen Rechner übernehmen, dem der NFS-Server vertraut, indem er ihn z. B
• mit einem Live-System neu bootet oder einen zusätzlichen Laptop ins Netz hängt und die IP eines gerade nicht laufenden NFS-Clients annimmt
• In beiden Fällen kann der Angreifer, da er auf seinem System Rootrechte hat, auf alle an den Client exportierten Dateien zugreifen, unabhängig von deren Zugriffsrechten
• Somit ist NFS v3 ohne separat installiertes Kerberos immer nur so sicher wie das Netz und die beteiligten Rechner

Mit der Server-Option root_squash (unter FreeBSD mit der in der entsprechenden Zeile anzugebenden Option -maproot=<USER>) kann man das oben genannte Szenario unterbinden

• Damit werden Zugriffe durch Benutzer mit der UID 0 (meist root) als Zugriffe des anonymen Benutzers (UID=65534) gewertet, der dann u. U
• keinerlei Zugriffsrechte auf die freigegebenen Dateien hat
• Ein Angreifer muss nun beim Verbinden so lange unterschiedliche UIDs ausprobieren, bis er die UID des Benutzers oder der Gruppe erwischt, die berechtigt ist
• Da es nur $2^{16}$ (65536) UIDs gibt, bietet auch dieses Vorgehen keine echte Sicherheit

NFS 4

NFSv4 löst dieses Problem, indem z. B. Kerberos nun Bestandteil des Protokolls ist und eine Authentifizierung der Benutzer ermöglicht

• Zudem lässt sich mit einer ebenfalls optionalen Verschlüsselung auch die Vertraulichkeit sicherstellen

Verfügbare Sicherheitsmodi

Beim Verbinden kann einer der folgenden Mechanismen gewählt werden, um das Sicherheitsniveau (welches auch die Übertragungsgeschwindigkeit beeinflusst) festzulegen

Bezeichnung	Bedeutung	Mount-Option
sys	Benutzeridentifikation erfolgt nach dem Schema von NFS3 Dies bietet sehr wenig Sicherheit	sec=sys
krb5	Server und Client authentifizieren sich gegenseitig unter Benutzung der GSS-Schnittstelle mittels Kerberos Dies unterbindet das obige Angriffsszenario	sec=krb5
krb5i	Zusätzlich wird die Integrität der übertragenen Daten sichergestellt Dies verhindert eine Veränderung der Daten durch einen Man In The Middle	sec=krb5i
krb5p	Die Vertraulichkeit der übertragenen Daten wird zusätzlich zur Integrität gewährleistet Dies verhindert ein Mitlesen durch einen Angreifer im Netzwerk	sec=krb5p

Eine Freigabe kann mehrere Mechanismen anbieten, aus denen der Client einen durch die Mount-Option auswählen kann

Alternative zu Kerberos

Allerdings wird des Öfteren bemängelt, dass mit Kerberos eine enorm komplexe und in einigen Umgebungen unmögliche Voraussetzung besteht

• Daher wird anstelle der eingebauten Sicherheitsfunktionen von NFS oft eine zusätzliche Sicherheits-Schicht wie TLS genutzt