9.5. NFS Sichern
Die Art, wie NFS bei der gemeinsamen Verwendung ganzer Dateisysteme mit einer großen Anzahl bekannter Hosts arbeitet, ist gut zu durchschauen. Aus diesem Vorteil können sich jedoch auch eine Reihe potenzieller Sicherheitsprobleme ergeben.
Folgende Punkte sollten beim Exportieren von NFS-Dateisystemen auf einem Server oder beim Mounten auf einem Client beachtet werden. Dadurch können die Sicherheitsrisiken von NFS verringert und die Daten auf dem Server besser geschützt werden.
Eine kurze Auflistung von Schritten, die Administratoren zur Sicherung von NFS ausführen können, lesen Sie das Kapitel Server Security in der Red Hat Enterprise Linux Sicherheitshandbuch.
9.5.1. Host-Zugriff
Welche der NFS-Versionen Sie für die Implementierung geplant haben, hängt von Ihrer bestehenden Netzwerkumgebung und Ihren Sicherheitsbedenken ab. Die folgenden Abschnitte erklären die Unterschiede zwischen der Implementierung von Sicherheitsmaßnahmen mittels NFSv2, NFSv3 oder NFSv4. Falls möglich wird dabei die Verwendung von NFSv4 empfohlen.
9.5.1.1. NFSv2 oder NFSv3 benutzen
NFS steuert anhand des Hosts, der die Anfrage zum Mounten stellt, wer ein exportiertes Dateisystem mounten kann (und nicht anhand des Benutzers, der das Dateisystem tatsächlich verwendet). Die Hosts müssen über eine ausdrücklicheBerechtigung verfügen, exportierte Dateisysteme zu mounten. Für Benutzer ist keine Zugriffskontrolle möglich, mit Ausnahme der Berechtigungen für Dateien und Verzeichnisse. Mit anderen Worten, wenn ein Dateisystem via NFS exportiert wird, kann jeder Benutzer auf jedem Remote-Host, der mit dem NFS-Server verbunden ist, auf die gemeinsam verwendeten Daten zugreifen. Um die potentiellen Risiken zu limitieren, erlauben Administratoren oft nur schreibgeschützten Zugang oder quetschen Benutzer-Genehmigungen zu einer üblichen Benutzer- und Gruppen-ID zusammen. Leider verhindern diese Lösungen, dass das NFS-Share so genutzt wird, wie ursprünglich beabsichtigt.
Wenn ein Angreifer die Kontrolle über den DNS-Server erlangt, der vom System zum Exportieren des NFS-Dateisystems verwendet wird, kann das System, dem ein bestimmter Hostname oder der komplette Domain-Name zugeordnet ist, auf einen nicht autorisierten Computer hinweisen. An diesem Punkt ist dieser nicht autorisierte Computer das System, das das NFS-Share mounten kann, da keine Informationen über Benutzernamen oder Passwort ausgetauscht werden, um zusätzliche Sicherheit für den NFS-Mount zu garantieren.
Wildcards sollten nur sparsam verwendet werden, wenn Verzeichnisse über NFS exportiert werden, da sich der Wirkungsbereich der Wildcard über mehr Systeme als beabsichtigt ausdehnen kann.
Es ist auch möglich, den Zugang zum portmap Dienstmittels TCP-Wrapper einzuschränken. Der Zugang zu Ports, die portmap, rpc.mountd, und rpc.nfsd verwenden, kann ebenfalls eingeschränkt werden, indem mit iptables Firewall-Regeln aufgestellt werden.
Für weitere Informationen über das Sichern von NFS portmap siehe Kapitel Server Security in der Red Hat Enterprise Linux Sicherheitshandbuch. Zusätzliche Informationen über Firewalls finden Sie in Kapitel 18.
9.5.1.2. NFSv4 benutzen
Die Version NFSv4 revolutionierte die Authenfifizierung und Sicherheit in Hinsicht auf NFS-Exporte. NFSv4 veranlasst die Implementierung des RPCSEC_GSS Kernel-Moduls, des Kerberos Version 5 GSS-API Mechanismus, SPKM-3 und LIPKEY. Mit NFSv4 sind die zwingenden Sicherheitsmechanismen in Richtung Authenfizierung individueller Benutzer ausgerichtet und nicht so sehr in Bezug auf Client-Rechner wie im Falle von NFSv2 und NFSv3.
 | Anmerkung |
|---|---|
Es wird davon ausgegangen, dass ein Kerberos Ticket-Granting-Server (KDC) installiet und einwandfrei konfiguriert ist, bevor ein NFSv4-Server konfiguriert wird. |
NFSv4 beinhaltet ACL-Unterstützung basierend auf das Microsoft Windows NT Model und nicht dem POSIX Model, aufgrund dessen Features und dem weitverbreiteten Einsatz.NFSv2 und NFSv3 besitzen keine Unterstützung für ACL-Attribute.
Ein anderes wichtiges Sicherheitsmerkmal von NFSv4 ist dessen Entfernung des rpc.mountd-Daemon. Der rpc.mountd-Daemon stellte eine mögliche Sicherheitslücke dar, durch die Art, wie dieser mit Datei-Handlern umgeht.
Für weitere Informationen über das RPCSEC_GSS Framework und auch wie rpc.svcgssd und rpc.gssd interoperieren siehe http://www.citi.umich.edu/projects/nfsv4/gssd/.
9.5.2. Dateiberechtigungen
Wenn ein Remote-Host das NFS-Dateisystem im Read-Write-Modus gemountet hat, sind die Genehmigungen der einzige Schutz, den jede gemeinsame Datei hat.Zwei Benutzer, die die gleiche Benutzer-ID zum Mounten des gleichen NFS-Dateisystems verwenden, können ihre Dateien gegenseitig modifizieren. Jeder, der als Root angemeldet ist, kann den Befehl su - verwenden, um ein Benutzer zu werden und über das NFS-Share Zugang zu bestimmten Dateien zu erlangen. Mehr Information über Konflikte zwischen NSF und Benutzer-ID finden Sie im KapitelManaging User Accounts and Resource Access im Red Hat Enterprise Linux Einführung in die System-Administration.
Standardmäßig werden Zugangs-Unterstützungslisten (ACLs) von NFS unter Red Hat Enterprise Linux unterstützt. Es wird nicht empfohlen, diese Funktion zu deaktivieren. Mehr dazu finden Sie im Kapitel Network File System (NFS) in der Red Hat Enterprise Linux Handbuch zur System-Administration.
Standardmäßig wird beim Exportieren eines Dateisystems via NFS Root-Squashing verwendet. Dies setzt die Benutzer-ID von jedem, der auf die NFS-Share zugreift, auf dem jeweiligen lokalen Rechner auf einen Wert des nfsnobody-Accounts auf dem Server. Schalten Sie Root-Squashing niemals aus.
Wenn Sie eine NFS-Share als schreibgeschützt exportieren, verwenden Sie die Option all_squash, wodurch alle Benutzer, die auf Ihr exportiertes Dateisystem Zugriff haben, die Benutzer-ID nfsnobody erhalten.