[[Vorlage(Fortgeschritten ) ]] [[Vorlage(Getestet, noble, ) ]] {{{#!vorlage Wissen [:Serverdienste:] {Übersicht} [:NFS:] [:Pakete installieren: Installation von Programmen] [:Programme_starten: Starten von Programmen] [:Terminal: Ein Terminal öffnen] [:mit Root-Rechten arbeiten:] }}} Dieser Artikel ist Teil der [#Links Artikelserie über NFS]. NFS steht für '''N'''etwork '''F'''ile '''S'''ystem und dies ist ein bei Linux und anderen Arten von Unix gebräuchliches Protokoll für den Austausch von Dateien über das Netzwerk. Für technische Details und Grundlagen siehe die Übersichten[1][2]. [[Inhaltsverzeichnis]] Dieser Artikel behandelt Themen, die ein Verwalter eines NFS-Servers kennen, beachten und bei der Konfiguration seines Servers beachten sollte, damit der Spitzname von NFS als ''"Nightmare File System"'' nicht ein weiteres Mal Realität wird. = Installation = Siehe Artikel: :arrow: [:NFS:] = Konfiguration = Die Konfiguration erfolgt über einfache Textdateien in den Ordnern '''/etc/''', '''/etc/nfs.conf.d/''' und '''/etc/exports.d/'''. Die Konfigurationsdateien können mit einem [:Editor:] mit Root-Rechten[6] bearbeitet werden. Alle Konfigurationsdateien müssen `root` als Eigentümer und Gruppe gehören und die Dateiberechtigungen `0644` haben bzw. `0755` für die genannten Ordner. Jede Zeile muss mit einem Zeilenumbruch (ASCII 10) enden. Um das sicherzustellen, sollte man jede Konfigurationsdatei mit einer Leerzeile oder einem Kommentar beenden. Die zulässigen Inhalte und weitere Details kann man den [:man:Manpages] oder den auszugsweise den hier folgenden Abschnitten entnehmen: {{{#!vorlage Befehl man nfs.conf }}} {{{#!vorlage Befehl man exports }}} Nach jeder Änderung der Konfiguration die Freigaben aktualisieren und den NFS-Server neu starten[4][5][6]: {{{#!vorlage Befehl sudo exportfs -alr }}} {{{#!vorlage Befehl systemctl restart nfs-server.service }}} == Eigenschaften des Servers == Die Konfiguration eines NFS-Servers – ausgenommen die Freigaben – erfolgt über mehrere Dateien: * Die Datei '''/etc/nfs.conf''' enthält die primäre Konfiguration, die zuerst gelesen und dann durch weitere Konfigurationsdateien ergänzt oder überschrieben werden kann. Man kann in dieser Datei selbst Änderungen vornehmen, es wird jedoch empfohlen, eigene Konfigurationen nur in den sekundären Konfigurationsdateien vorzunehmen. * Im Ordner '''/etc/nfs.conf.d/''' enthaltene Dateien mit Namensschema '''*.conf''' sind die sekundären Konfigurationen, die nach der primären gelesen werden. Abgesehen davon gibt es keinen Mechanismus zur Steuerung der Reihenfolge des Lesens. Diese Konfigurationsdateien sind im bekannten [#Links INI-Format] strukurierte Textdateien. Zulässige Zeilen sind: * Überschriften für Sektionen in eckigen Klammern, beispielsweise: `[nfsd]` * Initialisierungsdaten in der Form: `Schlüssel = Wert` * Kommentarzeilen, die in der ersten Spalte mit dem Zeichen `#` oder mit `;` beginnen. Kommentare werden ignoriert. Zeilenendkommentare sich aber nicht erlaubt. * Leerzeilen, die entweder gar nichts oder nur Leerzeichen und Tabulatoren enthalten. Lehrzeilen werden auch ignoriert. Die aktuelle Konfiguration kann man sich bequem anzeigen lassen: {{{#!vorlage Befehl nfsconf --dump }}} Beispielausgabe: {{{ [general] pipefs-directory = /run/rpc_pipefs [mountd] manage-gids = y }}} == Freigaben == Die Freigaben (''"exports"'') definiert man in folgenden Dateien: * Datei '''/etc/exports''' * Ordner '''/etc/exports.d/''' mit Dateien im Namensschema '''*.exports''': Solche Dateien kann man optional zusätzlich verwenden. Ihr Name darf nicht mit einem Punkt beginnen. In Konfigurationsdateien für Freigaben zulässig sind Kommentarzeilen, Leerzeilen und Datenzeilen. Jede Datenzeile besteht aus mindestens zwei Feldern, die durch Whitespace (Leerzeichen und/oder Tabulator) voneinander getrennt sind; innerhalb eines Feldes ist Whitespace unzulässig: * Das erste Feld enthält den freizugebenden Ordner als absoluten Pfad aus Sicht des Betriebssystems. * Das zweite und optional folgende Felder enthalten jeweils eine [#Rechner-spezifizieren Spezifikation für einen Rechner oder eine Gruppe von Rechnern], welche auf die Freigabe im ersten Feld zugreifen dürfen, sowie optional eine [#Optionsliste Liste von Optionen], welche die Art des Zugriffs beschreiben. Beispiel für eine Konfigurationsdatei für Freigaben: {{{ /srv/nfs -rw,subtree_check,insecure FD00::/8 *.fritz.box /home -no_subtree_check,insecure fd00::/8 *.fritz.box(mp) }}} Dieses Beispiel illustriert auch die mit Bindestrich eingeleitete Definition gemeinsamer Optionen für alle Rechnerspezifikationen. === Rechner spezifizieren === Die zum Zugriff berechtigten Rechner (Client) kann man mit folgenden Methoden angeben: * Rechnername, beispielsweise: `tusnelda` * DNS-Name, beispielsweise: `tusnelda.fritz.box` oder `tusnelda.local` oder `tusnelda.example.com` * DNS-Name mit Jokerzeichen `*`, beispielsweise: `*.fritz.box` oder `*.local` oder `*.example.com` Voraussetzung für die Funktion vorstehender Methoden: Der Server muss die IP-Adresse aus der Anfrage zurück in einen DNS-Namen übersetzen können (dazu benötigt man PTR-Records im DNS-Server) und so ermittelten Namen müssen der Spezifikation entsprechen. Während des Hochlaufs des Rechners funktioniert manchmal die Namensauflösung noch nicht. Wenn man bereits in dieser frühen Phase den NFS-Server starten möchte, verwendet man daher besser IP-Adressen zur Identifizierung: * IPv4-Adresse * IPv6-Adresse: Diese dürfen __nicht__ in eckigen Klammern `[]` stehen. * Adressbereiche, also IP-Adresse mit Netzmaske, beispielsweise: `10.0.0.0/255.240.0.0` oder `192.168.0.0/16` oder `fd00::/8` Der Client erhält Zugriff, wenn er eine IP-Adresse aus den genannten Bereichen benutzt. Weitere Methoden: * Eine [#Links Netzgruppe] (netgroup), die man in der Datei '''/etc/netgroup''' spezifiziert hat. Es wird aus den Tripeln jeweils nur die erste Komponente ausgewertet. * Das Zeichen `*`: Damit erlaubt man weltweit jedem Rechner den Zugriff. Effektiv schalten man damit die Prüfung ab, ob ein Rechner zum Zugriff berechtigt ist. * Das Zeichen `-` (Bindestrich), gefolgt von einer (nicht in Klammern stehenden!) Liste von Optionen: Damit selektiert man zunächst keinen zum Zugriff berechtigten Rechner, sondern Vorgaben für die darauf folgenden Rechner. === Optionsliste === Dies ist eine mit Kommata getrennte Liste von Optionen aus folgender Tabelle 1. Man muss die Liste in runde Klammern `()` setzen und ohne trennendes Leerzeichen an die Spezifikation des Rechners anhängen. {{{#!vorlage Tabelle <-3 rowclass="titel" :>Tabelle 1: Ausgewählte Optionen für Freigaben per NFSv4 +++ Option <|2>Beschreibung +++ Vorgabe Alternative +++ ro rw Normalerweise werden Ordner schreibgeschützt freigegeben. Wenn man Erstellung/Änderung/Löschen von Dateien und Ordnern erlauben möchte, muss man den Schutz mit `rw` ausschalten; dann gelten für tatsächliches Schreiben die jeweiligen Dateirechte von Unix sowie ggf. die aus POSIX- und NFSv4-ACLs. +++ sync async Mit der Vorgabe `sync` (ab Version 1.0.0) beantwortet der Server die Anfrage eines Clients erst nachdem alle damit verbundenen Änderungen auch tatsächlich gespeichert wurden. Dieses sichere Verhalten kann man mit `async` abschalten und damit die Performance von Schreibvorgängen auf Kosten der Sicherheit steigern. So etwas sollte man natürlich nur bei unwichtigen Daten erlauben. +++ secure insecure Die Vorgabe `secure` bedeutet, dass der Client einen privilegierten Port (d.h. in der Regel einen unter 1024) benutzen muss. Das kann man man mit `insecure` ausschalten. Der Name dieser Option kann in die Irre führen, tatsächlich wird ein NFS-Server in der Praxis durch Verwendung von `insecure` nicht unsicherer, als er es ohnehin schon ist. +++ no_subtree_check subtree_check Schaltet den sog. "subtree check" aus oder ein. Abhängig von der konkreten Nutzung der Freigabe kann beides gut oder schlecht sein. Konsultiere die Manpage für weitere Details. Vorgabe ist `no_subtree_check` ab Version 1.0.0, man muss aber eine der beiden Möglichkeiten explizit angeben, um nervige Fehlermeldungen zu vermeiden. +++ root_squash no_root_squash Normalerweise wird jede von einem Benutzer mit UID=0 stammende Anfrage so umgesetzt, als wenn sie von einem Benutzer mit der über `anonuid` spezifizierten UID und mit `anongid` spezifizierten GID stammen würde. Also ein `root` auf dem Client wird zu einem `nobody` auf dem Server und hat somit keine Sonderrechte auf dem Server. Man kann dieses Sicherheitsfeature ("root squashing") mit `no_root_squash` abschalten, was in den allermeisten Fällen eine sehr schlechte Idee ist. +++ no_all_squash all_squash Normalerweise wird eine von einem Benutzer mit UID≠0 stammende Anfrage nicht umgesetzt, d.h. jeder Benutzer agiert auf dem Server mit derselben UID und GID wie auf dem anfragendem Rechner. Dies ist nur dann sinnvoll, wenn auf beiden Rechnern die numerische UID auch dieselbe Person bzw. GID dieselbe Benutzergruppe identifiziert; dies trifft in der Regel ohne besondere Maßnahmen meist __nicht__ zu. Mit der Option `all_sqash` kann man eine Umsetzung auf die mit `anonuid` bzw. `anongid` angegebene UID bzw. GID erzwingen. +++ anonuid=65534 anonuid=GANZZAHL Definition der Zielperson bei Squash. 0 ≤ GANZZAHL < 2^^(32)^^ +++ anongid=65534 anongid=GANZZAHL Definition der Zielgruppe bei Squash. 0 ≤ GANZZAHL < 2^^(32)^^ +++ sec=sys sec=krb5p:krb5i:krb5:sys Auswahl der Sicherheitsstufe(n): Der Wert der Option ist eine mit Doppelpunkten getrennte Liste von Sicherheitsstufen. Die Option kann mehrmals angegeben werden und man kann für jede Sicherheitsstufe danach unterschiedliche Werte für `ro/rw`, `root_squash` und `all_squash` angeben. Details siehe Manpage und nachfolgende Diskussion im Kapitel [#Sicherheit Sicherheit]. +++ wdelay no_wdelay <|4>Diese Optionen kann man zwar bei einem NFSv4-Server definieren, sie sind aber hier entweder wirkungslos oder von geringem Nutzen. Details siehe Manpage. +++ hide nohide +++ nocrossmnt crossmnt +++ nordirplus +++ auth_nlm[[BR]]secure_locks no_auth_nlm[[BR]]no_secure_locks Normalerweise verlangt ein moderner NFS-Server bei der Anforderung einer Dateisperre eine Authentifizierung des Clients. Früher war das nicht erforderlich und es gibt noch viele Clients, die das nicht beherrschen, daher kann man es beim Server abschalten. Besser als dieser Notbehelf ist natürlich Verwendung eines modernen Clients. +++ mountpoint[[BR]]mp[[BR]]mountpoint=PFAD[[BR]]mp=PFAD Der freizugebende Ordner wird nur dann exportiert, wenn er auch ein Einbindepunkt ist bzw. wenn genau das angegebene Dateisystem hier eingebunden wurde. Details siehe nachfolgende Diskussion im Kapitel [#Sicherheit Sicherheit]. }}} Weitere Optionen: fsid, refer, replicas, pnfs, security_label = Sicherheit = NFS ist unsicher, außer man tut etwas dagegen. Als ersten Schritt sollte man sich über die Nachteile von NFS informieren, und dabei will dieser Artikel unterstützen. == Daten-Integrität == Die Manpage nfs erläutert, dass beim Austausch von Dateien bei Verwendung des Protokollstacks * NFS in UDP in IP über Gigabit-Ethernet es zwangsläufig zu Fragmentierung der Pakete auf der Ebene IP kommt, und wegen der großen Anzahl der in kurzer Zeit übertragbaren Fragmente der Zähler für Fragmente überläuft, und damit kommt es zwangsläufig zum falschen Zusammenbau der Pakete auf Empfängerseite. Die übertragenen Dateien werden also beschädigt. Außerdem verringert natürlich die Fragmentierung die Performance. Gegenmaßnahmen: * [[Anker( only-NFSv4 ) ]] Man verzichtet auf das Protokoll NFSv3 und erst recht auf noch ältere Versionen und betreibt einen reinen NFSv4-Server. NFSv4 verwendet nur TCP, bei dem das beschriebene fehlerhafte Verhalten nicht auftreten kann. * Das ist technisch einfach über eine Konfigurationsdatei auf dem Server machbar: \\ {{{ [nfsd] vers2 = off vers3 = off }}} * In der Praxis ist es nicht ganz so einfach, weil viele Client-Programme das Protokoll NFSv4 gar nicht oder nur unvollständig oder nur fehlerhaft beherrschen. Viele Benutzer werden sich mit Supportanfragen melden. * [[Anker( no-UDP ) ]] Man verzichtet auf UDP. * Konfigurationsdatei: \\ {{{ [nfsd] UDP = off }}} * Dies erzwingt beim Protokoll NFSv3 die Verwendung von TCP und ändert nichts bei NFSv4, das ohnehin niemals UDP verwendet. * Man verwendet auf der Ebene Ethernet Jumbo-Frames und reduziert damit die Fragmentierung auf Ebene IP. == Vertraulichkeit == Das Protokoll NFS, auch NFSv4, überträgt Daten standardmäßig im Klartext und bietet damit keinerlei Schutz gegen Abhören. Vertrauliche Informationen sollte man daher nur dann per NFS übertragen, wenn das Netzwerk auf andere Weise (z.B. VPN) gegen Abhören gesichert wurde und Unbefugte keinen Zugang zum Netzwerk haben. Der letzte Punkt lässt sich bei Verwendung eines WLANs nicht realisieren. [[Anker( Kerberos ) ]] NFSv4 bietet aber Möglichkeiten, durch zusätzlichen Aufwand die Vertraulichkeit zu verbessern. Die Standardmethode hierzu ist die Verwendung eines separaten Kerberos-Servers zur Identifizierung und Authentifizierung und Bereitstellung einer Infrastruktur zur Verschlüsselung des Datenverkehrs. :arrow: [:Kerberos/NFS mit Kerberos sichern:NFS mit Kerberos sichern] [[Anker( SSH-Tunnel ) ]] Einrichtung und kompetenter Betrieb eines Kerberos-Servers ist allerdings eine herausfordernde Aufgabe, die in der Regel Privatanwender und kleine Unternehmen überfordern kann. Eine einfach einzurichtende Alternative kann sein, den NFSv4-Verkehr über SSH zu tunneln. Erst bei NFSv4 ist wegen dessen Beschränkung auf einen Port diese Technik einfach zu nutzen, obwohl sie auch früher schon möglich war. :arrow: [:Howto/NFSv4 mit SSH sichern:] == Zugriffsschutz == Das Protokoll NFS, auch NFSv4, bietet selber keinen heutigen Ansprüchen entsprechenden Schutz vor dem Zugriff durch Unbefugte: * IP-Adressen lassen sich leicht fälschen. * DNS-Namen können durch Manipulation von DNS-Servern Unbefugten die Nutzung bestimmter IP-Adressen ermöglichen. * Kennungen für Benutzer und Gruppen sind leicht fälschbar. Diese Angriffe erfordern entsprechende technische Kenntnisse und Mittel, die zwar nicht jedem zur Verfügung stehen, aber es gilt als sicher, dass kriminelle Hacker und in staatlichem Auftrag handelnde Angreifer darüber verfügen. Wegen der leichten Fälschbarkeit von Benutzer-Kennungen hat ein Angreifer, der bereits regulären Zugriff auf eine Freigabe hat, damit auch Zugriff auf jeden Ordner und jede Datei, die nicht `root` gehört – und wenn man "root squashing" abgeschaltet hat, dann auch auf diese. Der Zugriff auf fremde Dateien kann auch unabsichtlich ermöglicht werden, wenn Client und Server UID oder dieselbe GID unterschiedlichen Personen zugeordnet haben. Schließlich ist bei NFS aus technischen Gründen unmöglich, nur Teile eines Dateisystems freizugeben. Man kann so etwas zwar in den Exports definieren, aber nicht wirksam verhindern, dass ein Benutzer mit Hackern bekannten Techniken aus dem regulär exportierten Bereich ausbrechen und auf nicht exportierte Dateien im betreffenden Dateisystem zugreifen. Dieses unerwünschte Verhalten kann man mit der Option `subtree_check` etwas abmildern, aber nicht vollständig unterbinden. Aus diesem Grund geben Profis grundsätzlich immer nur vollständige Dateisysteme frei, die sie auf die exportierten Order einbinden ("mounten") und sichern über die Option `mountpoint` ab, dass die Einbindung auch tatsächlich erfolgreich erfolgte. Für viele der vorstehend genannten Probleme ist bei NTFSv4 die Verwendung eines zusätzlich [#Kerberos Kerberos-Servers] die etablierte Standardlösung; für kleine Aufgaben können auch [#SSH-Tunnel SSH-Tunnel] helfen. == Checkliste == * Das Protokoll [#no-UDP UDP für NFS sperren]. * Nach Möglichkeit [#only-NFSv4 nur die Version 4] des NFS-Protokolls benutzen. * Die zum Zugriff berechtigten Clients so weit wie möglich einschränken. Am besten zur [#Rechner-spezifizieren Spezifikation der Rechner] nur einzelne IP-Adressen verwenden. * Auf Server und allen berechtigten Clients müssen die Kennungen für Benutzer und Gruppen dieselben Bedeutung haben. Das ist in der Regel meist nicht der Fall und nur mit großem Aufwand erreichbar. * Die standardmäßig aktivierte Vorsichtsmaßnahme "root squashing" nicht abschalten. * Den Zugriff auf den Server nur aus als sicher geltenden Netzwerken erlauben. Falls dies nicht möglich ist: * VLAN / VPN / IPSec verwenden, * oder Verkehr tunneln über SSH (:arrow: [#SSH-Tunnel NFSv4 mit SSH sichern]) / Wireguard / Stunnel, * oder zukünftig TLS nach RFC9289 verwenden, sobald es als Software verfügbar ist, * oder Kerberos mit den Sicherheitsstufen krb5i oder krb5p benutzen (:arrow: [#Kerberos NFS mit Kerberos sichern] * Nach Möglichkeit Dateisysteme vollständig freigeben, d.h. der jeweilige Export ist die Wurzel des auf den Export eingebundenen Dateisystems; dies mit der Option `mountpoint` absichern. Wenn dies nicht möglich ist, unbedingt die Option `subtree_check` verwenden. * Optional dem NFS-Server eine Firewall vorschalten. Diese ist bei NFSv4 im Vergleich zu älteren Versionen drastisch vereinfacht, da nur noch der Port `2049/tcp` abgesichert werden muss. = Links = [[Seitenliste( '*NFS*' ) ]] Externe Verweise: * [wikipedia:Initialisierungsdatei:INI-Format] * [https://www.pro-linux.de/kurztipps/2/1402/netgroups-lokal-mit-nfs-und-samba-nutzen.html Netgroups lokal mit NFS und Samba nutzen] {de} – aus Pro-Linux Juli 2005 * [https://www.linux.com/news/sysadmin-sysadmin-netgroups-are-not-just-nis-anymore/ Netgroups are not just for NIS] {en} – auf Linux.com April 2004 #tag: Netzwerk, System, Freigabe