Durcir les exports NFS : périmètre réseau, options squash et sec=krb5 à la place d'AUTH_SYS

Objectif

Réduire ce qu'un export NFS accepte sans vérification de la part de ses clients : quels hôtes peuvent se connecter, quels UID/GID une requête est autorisée à revendiquer, et si le serveur peut exiger une preuve cryptographique d'identité au lieu de s'en remettre à la parole du client.

Prérequis

Un export existant dans /etc/exports ; pour l'option Kerberos, un realm Kerberos fonctionnel, une clé nfs/<fqdn> dans le keytab du serveur, gssproxy (ou l'ancien rpc.svcgssd) sur le serveur et rpc.gssd sur les clients, ce qui dépasse le cadre de cet article.

Étapes

1. N'exportez jamais vers tous les hôtes. exports(5) permet de cibler un export sur un hôte unique, un motif de nom ou un sous-réseau entier sous la forme address/netmask ; limitez chaque export au plus petit réseau qui en a besoin.
2. Conservez root_squash (valeur par défaut) : cette option fait correspondre les requêtes provenant de l'uid/gid 0 à l'uid/gid anonyme, de sorte qu'un client se prétendant root n'obtient pas les droits root sur les fichiers du serveur. Elle n'empêche pas le root d'un client de prendre n'importe quel autre UID et d'agir en tant que cet utilisateur. Ne la retirez (no_root_squash) que pour un hôte d'administration précis, de confiance, qui en a réellement besoin.
3. Pour les exports où aucun UID fourni par le client ne doit être cru — un répertoire de dépôt partagé, par exemple — utilisez all_squash afin que chaque requête soit associée au compte anonyme, quel que soit l'UID présenté.
4. Comprenez pourquoi c'est important : les considérations de sécurité de nfs(5) indiquent que les serveurs NFS contrôlent l'accès aux données des fichiers mais dépendent de leur implémentation RPC pour l'authentification, et que l'implémentation traditionnelle représente chaque utilisateur par un simple nombre fourni par le client lui-même — le serveur ne le vérifie pas de manière indépendante.
5. Lorsque les données le justifient, faites passer l'export et le montage client à sec=krb5 (authentification seule), krb5i (plus intégrité) ou krb5p (plus chiffrement). nfs(5) décrit sec= comme une liste séparée par des deux-points d'un ou plusieurs modes de sécurité à utiliser pour accéder aux fichiers du montage, krb5, krb5i et krb5p figurant parmi les modes valides ; la ligne d'export accepte une option sec= correspondante pour l'imposer.
6. Réexportez avec exportfs -ra et vérifiez le mode réellement négocié par un client en consultant les options du montage côté client (cat /proc/mounts ou nfsstat -m).

Résultat attendu

Les montages depuis l'extérieur du réseau configuré sont refusés ; un client présentant l'UID 0 est associé au compte anonyme sur les exports avec squash ; lorsque l'export ne liste que des modes sec=krb5*, l'accès sans identifiants Kerberos valides est refusé (au montage ou au premier accès) au lieu de retomber sur AUTH_SYS.

Limites et base de vérification

AUTH_SYS accorde à chaque utilisateur de chaque client autorisé l'accès que son UID implique ; root_squash ne traite que root, et all_squash ne convient qu'aux exports où aucune propriété par utilisateur n'est nécessaire. NFS avec Kerberos dépend d'une synchronisation horaire correcte et d'un keytab correctement entretenu — un KDC défaillant fait échouer les montages au lieu de dégrader le service en silence ; testez donc les changements pendant une fenêtre de maintenance. Conservez une copie de l'ancien /etc/exports avant de le durcir.