NFS-Export auf eine VPN-Adresse festgelegt: Was das nicht beweist
Eine Exportregel prüft, woher ein Paket kam; AUTH_SYS behauptet eine lokale UID, und Kerberos authentifiziert einen Benutzer. Entscheiden Sie, was Ihr Dateidienst braucht.
Ein Host exportiert ein Verzeichnis an eine VPN-Adresse, der Mount gelingt, und im Entwurf steht danach, der Zugriff sei authentifiziert. Was diese Regel tatsächlich einschränkt, ist, woher die Pakete zu kommen scheinen. Ob die Person, die die Dateioperation auslöst, diejenige ist, für die sie sich ausgibt, hängt vom NFS-Sicherheitsgeschmack ab, und bei den meisten Exporten dieser Art hat ihn niemand vom Standard geändert.
Drei Identitäten können in einer Anfrage auftauchen
Der VPN-Peer trägt eine registrierte Identität wie ein Clientzertifikat oder einen Peer-Schlüssel. Das innere IP-Paket trägt eine Quelladresse. Die Dateioperation trägt die Benutzeranmeldedaten, die ihr NFS-Mechanismus liefert. Ein Entwurf, der die Adresse als Stellvertreter für alle drei behandelt, hat stillschweigend genau den Teil angenommen, der zu prüfen gewesen wäre.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Diese drei Zeilen aufzuschreiben ist die ganze Übung. Der größte Teil der Debatte, ob ein Export sicher ist, bricht zusammen, sobald klar ist, in welcher Zeile welche Kontrolle lebt.
Adresseigentum ist ein Implementierungsdetail
Ein Gateway kann einem akzeptierten Peer eine Tunneladresse zuweisen oder ihm ein geroutetes Subnetz genehmigen. Ob die Implementierung danach ein Paket ablehnt, dessen innere Quelle zu einem anderen Client gehört, ist eine Eigenschaft dieser Implementierung, und es lohnt sich, das zu prüfen statt es anzunehmen.
Der herkömmliche Userspace-Servercode von Community OpenVPN kann beispielsweise eine Quelle ablehnen, die einem anderen Client zugeordnet ist, bevor das Paket über das TUN-Gerät zugestellt wird. Das ist eine Adresseigentumsprüfung mit echtem Wert, und sie ist weiterhin keine NFS-Benutzerauthentifizierung, weil sie nichts darüber sagt, welches Konto die Operation ausführt.
Quellübersetzung nagt sogar daran. Ein NAT-Gateway kann jeden Client als eine Adresse darstellen, und dann kann eine Exportregel die Menschen dahinter nicht mehr unterscheiden. Die scheinbare Präzision der Regel wird dann zu einer Fiktion, die das Diagramm aufrechterhält. Wenn der Export wichtig ist, halten Sie die Adressierung explizit, statt einen Übersetzer entscheiden zu lassen, wer als wer zählt.
Lesen Sie den Sicherheitsgeschmack, bevor Sie dem Export vertrauen
Die NFS-Anleitung von Red Hat trennt sec=sys, das lokale UNIX-UIDs und -GIDs über AUTH_SYS verwendet, von den Kerberos-Modi. krb5 ergänzt die Benutzerauthentifizierung, krb5i ergänzt Integritätsschutz und krb5p ergänzt Datenschutz für den Datenverkehr.
Die AUTH_SYS-Anmeldedaten enthalten Felder wie die UID des Aufrufers und Gruppen-IDs, und RFC 5531 warnt ausdrücklich, dass dieser Geschmack für sich genommen keine Sicherheit bietet und von externem Schutz abhängt. Ihn innerhalb eines VPN zu betreiben liefert Schutz für den Transport und ändert nichts an der Behauptung im Paket.
exportfs -v
showmount -e nfs.example.internalLesen Sie den Geschmack in dieser Ausgabe, bevor Sie die Clientliste lesen. Ein Export, der eingeschränkt aussieht, kann allein durch die Adresse eingeschränkt sein, während jeder Aufrufer weiterhin jede beliebige UID behauptet.
Wählen Sie das Modell und behalten Sie dann die Berechtigungen
Wählen Sie das Authentifizierungsmodell des Dateidienstes, das zu den Clients passt, die Sie tatsächlich administrieren. Kerberos erfordert eine Identität und eine Dienstbereitstellung dahinter, eine geänderte Mount-Option ist also keine Migration und wird schlicht scheitern, bis Kerberos-Domäne, Prinzipale und Keytabs existieren.
Behalten Sie unter beiden Modellen die Exportberechtigungen und die Dateisystem-Autorisierung, die begrenzen, was das authentifizierte Prinzipial tun darf. Authentifizierung sagt Ihnen, wer fragt; Autorisierung entscheidet, ob die Antwort ja lauten soll. Beides in eine Einstellung zu verschmelzen ist der Weg, auf dem eine Migration mehr gewährt als die alte Konfiguration.
Nutzen Sie die Adressregel für ihren eigentlichen Zweck
Den Dienst auf den genehmigten Pfad und die genehmigten Quellen zu beschränken bleibt sinnvoll, einschließlich der Host-Eingaberichtlinie, wenn VPN-Endpunkt und NFS-Server dieselbe Maschine teilen. Regeln, die Datenverkehr weiterleiten, steuern keine Anforderungen an einen Dienst, der lokal auf demselben Host läuft. Diese Lücke erklärt eine überraschende Zahl von Exporten, die privat sein sollten. Prüfen Sie die lokale Eingaberichtlinie ausdrücklich, statt anzunehmen, die Tunnelregeln deckten sie ab.
Prüfen Sie, ob eine andere Schnittstelle oder ein Gateway mit Quellübersetzung die Regel unerwartet erfüllen kann, und behandeln Sie das als Grund, die Herkunft festzustellen, nicht als Behauptung, das Fälschen einer Adresse garantiere einen funktionierenden Mount.
Führen Sie drei Abnahmefälle statt einem durch. Beginnen Sie mit einem genehmigten Client, der als genehmigter Benutzer handelt, wiederholen Sie es dann von einem Peer, der nie genehmigt wurde, und versuchen Sie danach etwas, das der genehmigte Benutzer noch immer nicht darf. Fragen Sie anschließend, was sich ändert, wenn ein autorisierter Client kompromittiert wird, denn Transportauthentifizierung macht nicht jeden Prozess auf dieser Maschine vertrauenswürdig. Ein gestohlenes Zertifikat und ein neugieriges lokales Konto sind verschiedene Probleme mit verschiedenen Kontrollen.