Export NFS verrouillé sur une adresse VPN : ce que cela ne prouve pas
Une règle d'export vérifie d'où vient le paquet ; AUTH_SYS déclare un UID local et Kerberos authentifie un utilisateur. Décidez lequel votre service de fichiers exige.
Un hôte exporte un répertoire vers une adresse VPN, le montage réussit et la conception est consignée comme authentifiée. Ce que cette règle contraint réellement, c'est d'où les paquets semblent venir. Que la personne qui pilote l'opération de fichier soit bien celle qu'elle prétend être dépend du profil de sécurité NFS, et sur la plupart des exports de ce genre personne ne l'a changé par rapport à la valeur par défaut.
Trois identités peuvent apparaître dans une seule requête
Le pair VPN porte une identité enrôlée, comme un certificat client ou une clé de pair. Le paquet IP interne porte une adresse source. L'opération de fichier porte les identifiants utilisateur que fournit son mécanisme NFS. Une conception qui traite l'adresse comme un substitut des trois a silencieusement supposé précisément la partie qu'il fallait vérifier.
| 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 |
Écrire ces trois lignes, c'est tout l'exercice. L'essentiel du débat sur la sûreté d'un export s'effondre dès qu'on voit dans quelle ligne vit chaque contrôle.
La propriété de l'adresse est un détail d'implémentation
Une passerelle peut attribuer une adresse de tunnel à un pair accepté ou autoriser un sous-réseau routé pour lui. Que l'implémentation refuse ensuite un paquet dont la source interne appartient à un autre client est une propriété de cette implémentation, et il vaut la peine de le vérifier plutôt que de le supposer.
Le code serveur en espace utilisateur du Community classique OpenVPN peut, par exemple, rejeter une source associée à un autre client avant que le paquet ne soit livré via le périphérique TUN. C'est un contrôle de propriété d'adresse à la valeur réelle, et ce n'est toujours pas une authentification d'utilisateur NFS, car il ne dit rien du compte qui effectue l'opération.
La traduction de source érode même cela. Une passerelle NAT peut présenter chaque client comme une seule adresse, et une règle d'export ne peut alors plus distinguer les personnes derrière. La précision apparente de la règle devient alors une fiction entretenue par le schéma. Si l'export compte, gardez l'adressage explicite plutôt que de laisser un traducteur décider qui compte pour qui.
Lisez le profil de sécurité avant de faire confiance à l'export
Le guide NFS de Red Hat sépare sec=sys, qui utilise des UID et GID UNIX locaux via AUTH_SYS, des modes Kerberos. krb5 ajoute l'authentification de l'utilisateur, krb5i ajoute la protection de l'intégrité et krb5p ajoute la protection de la confidentialité du trafic.
L'identifiant AUTH_SYS contient des champs comme l'UID de l'appelant et les identifiants de groupe, et la RFC 5531 avertit clairement que ce profil ne procure aucune sécurité en lui-même et dépend d'une protection externe. L'exécuter dans un VPN assure une protection du transport et ne change rien à l'affirmation contenue dans le paquet.
exportfs -v
showmount -e nfs.example.internalLisez le profil dans cette sortie avant de lire la liste des clients. Un export qui paraît restreint peut ne l'être que par l'adresse alors que chaque appelant déclare encore l'UID qui lui plaît.
Choisissez le modèle, puis conservez les permissions
Choisissez le modèle d'authentification du service de fichiers adapté aux clients que vous administrez réellement. Kerberos exige une identité et un déploiement de service derrière elle, donc changer une option de montage n'est pas une migration et échouera simplement tant que le domaine Kerberos, les principaux et les keytabs n'existent pas.
Sous l'un ou l'autre modèle, conservez les permissions d'export et l'autorisation du système de fichiers qui limitent ce que le principal authentifié peut faire. L'authentification vous dit qui demande ; l'autorisation décide si la réponse doit être oui. Fondre les deux dans un seul réglage, c'est ainsi qu'une migration finit par accorder plus que l'ancienne configuration.
Utilisez la règle d'adresse pour son véritable objet
Restreindre le service au chemin et aux sources approuvés reste utile, y compris la politique d'entrée de l'hôte quand le point de terminaison VPN et le serveur NFS partagent une machine. Les règles qui acheminent le trafic ne régissent pas les requêtes adressées à un service exécuté localement sur le même hôte. Cette lacune explique un nombre surprenant d'exports censés être privés. Vérifiez explicitement la politique d'entrée locale au lieu de supposer que les règles du tunnel la couvrent.
Vérifiez qu'une autre interface ou une passerelle à traduction de source ne peut pas satisfaire la règle de façon inattendue, et traitez cela comme une raison d'établir la provenance, non comme l'affirmation que falsifier une adresse garantit un montage fonctionnel.
Exécutez trois cas d'acceptation plutôt qu'un. Commencez par un client approuvé agissant comme utilisateur approuvé, répétez ensuite depuis un pair qui n'a jamais été approuvé, puis tentez quelque chose que l'utilisateur approuvé n'est toujours pas autorisé à faire. Demandez ensuite ce qui change si un client autorisé est compromis, car l'authentification du transport ne rend pas chaque processus de cette machine digne de confiance. Un certificat volé et un compte local curieux sont des problèmes différents avec des contrôles différents.