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.
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.
