8.8. Sécurisation de NFS

Traditionnellement, NFS offrait deux options pour contrôler l'accès aux fichiers exportés.

Premièrement, le serveur contrôle quels hôtes sont autorisés à monter quels systèmes de fichiers, soit par adresse IP ou par nom d'hôte.

Puis le serveur applique les permissions du système de fichiers pour les utilisateurs des clients NFS de la même manière que pour les utilisateurs locaux. Traditionnellement, ceci est fait à l'aide d'AUTH_SYS (aussi appelé AUTH_UNIX), qui se fie au client pour indiquer l'UID et le GID de l'utilisateur. Soyez conscient que cela signifie qu'un client mal configuré ou malicieux pourrait facilement mal comprendre ceci et autoriser un utilisateur à accéder à des fichiers auxquels il ne devrait pas avoir accès.

Pour limiter les risques potentiels, les administrateurs autorisent souvent l'accès en lecture seule ou limitent les permissions utilisateur à un utilisateur et un ID de groupe communs. Malheureusement, ces solutions empêchent le partage NFS d'être utilisé comme prévu à l'origine.

En outre, si une personne mal intentionnée prenait contrôle du serveur DNS utilisé par le système exportant le système de fichiers NFS, le système associé à un nom d'hôte ou à un nom de domaine complet peut être dirigé vers un ordinateur non autorisé. À ce moment, l'ordinateur non autorisé devient le système autorisé à monter le partage NFS, puisqu'aucune information sur le nom d'utilisateur ou sur le mot de passe n'est échangée pour fournir une sécurité supplémentaire au montage NFS.

Les caractères génériques doivent être utilisés avec précaution lors de l'export de répertoires à travers NFS, car il est possible que l'étendue du caractère générique puisse englober davantage de systèmes que prévu.

Il est également possible de restreindre l'accès au service rpcbind^[1] avec des enveloppes TCP. La création de règles avec iptables peut également limiter l'accès aux ports utilisés par rpcbind, rpc.mountd, et rpc.nfsd.

Pour obtenir des informations supplémentaires sur la sécurisation de NFS et rpcbind, veuillez consulter man iptables.

La sortie de NFSv4 a provoqué une révolution dans la sécurité NFS en mandatant l'implémentation de RPCSEC_GSS et du mécanisme GSS-API Kerberos version 5. Cependant, RPCSEC_GSS et le mécanisme Kerberos sont aussi disponibles pour toutes les versions de NFS. en mode FIPS, vous ne pouvez utiliser que les algorithmes autorisés par FIPS.

Avec le mécanisme Kerberos RPCSEC_GSS, le serveur ne dépend plus du client pour correctement représenter les utilisateurs qui accèdent au fichier, tout comme avec AUTH_SYS. Au lieu de cela, un chiffrement est utilisé pour authentifier les utilisateurs sur le serveur, empêchant ainsi à un client mal intentionné de prendre la place d'un utilisateur sans posséder les informations d'utilisation Kerberos de cet utilisateur. Il est également plus facile ainsi de sécuriser les montages sécurisés, puisqu'après que la configuration Kerberos a eu lieu, cela fonctionne sans modification supplémentaire.

Pour paramétrer RPCSEC_GSS, veuillez utiliser la procédure suivante :

Pour obtenir des informations supplémentaires, comme les différences entre krb5, krb5i, et krb5p, veuillez consulter les pages man exports et nfs ou la Section 8.5, « Options de montage NFS courantes ».

Pour obtenir des informations supplémentaires sur le cadre de RPCSEC_GSS, y compris sur la manière par laquelle rpc.svcgssd et rpc.gssd interagissent, veuillez consulter http://www.citi.umich.edu/projects/nfsv4/gssd/.

Une fois que le système de fichiers NFS est monté en lecture/écriture par un hôte distant, la seule protection que chaque fichier partagé possède sont ses permissions. Si deux utilisateurs partageant la même valeur d'ID d'utilisateur montent le même système de fichiers NFS, ils pourront chacun modifier les fichiers de l'autre. En outre, toute personne connectée en tant que root sur le système client peut utiliser la commande su - pour accéder à tous les fichiers du partage NFS.

Par défaut, les listes de contrôle d'accès (ACL) sont prises en charge par NFS sur Red Hat Enterprise Linux. Red Hat recommande de laisser cette fonctionnalité activée.

Par défaut, NFS utilise root squashing (« Écrasement root ») lors de l'exportation d'un système de fichiers. Ceci définit l'ID d'utilisateur de tout utilisateur root local accédant au partage NFS en tant que nobody (personne). Le root squashing est contrôlé par l'option par défaut root_squash. Pour obtenir des informations supplémentaires sur cette option, veuillez consulter Section 8.7.1, « Fichier de configuration /etc/exports ». Dans la mesure du possible, ne désactivez jamais le root squashing.

Lors de l'exportation d'un partage NFS en lecture seule, veuillez considérer l'utilisation de l'option all_squash. Cette option fait que tout utilisateur accédant au système de fichiers exporté prendra l'ID utilisateur de l'utilisateur nfsnobody.