8.8. Sécurisation de NFS
NFS est bien adapté au partage de systèmes de fichiers entiers avec un grand nombre d'hôtes connus de manière transparente. Cependant, cette facilité d'utilisation entraîne toute une variété de problèmes de sécurité potentiels. Prenez en considération les sections suivantes lorsque vous exportez des systèmes de fichiers NFS sur un serveur ou lorsque vous les montez sur un client. Cela minimisera les risques de sécurité NFS et protégera mieux les données sur le serveur.
8.8.1. Sécurité NFS avec AUTH_SYS et les contrôles d'export
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
.
8.8.2. Sécurité NFS avec AUTH_GSS
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.
Note
On considère qu'un serveur d'octroiement de ticket Kerberos (KDC) est correctement installé et configuré avant de procéder à la configuration du serveur NFSv4. Kerberos est un système d'authentification réseau qui permet aux clients et serveurs de s'authentifier à travers l'utilisation d'un chiffrement symétrique et d'une tierce partie de confiance, KDC. Pour obtenir des informations supplémentaires sur Kerberos, veuillez consulter Using Kerberos dans le guide System-Level Authentication Guide.
Pour paramétrer RPCSEC_GSS, veuillez utiliser la procédure suivante :
Procédure 8.2. Paramétrer RPCSEC_GSS
- Créez les principaux
nfs/client.mydomain@MYREALM
etnfs/server.mydomain@MYREALM
. - Ajoutez les clés correspondant aux onglets principaux pour le client et le serveur.
- Du côté serveur, veuillez ajouter
sec=krb5:krb5i:krb5p
à l'export. Pour continuer à autoriser AUTH_SYS, veuillez ajoutersec=krb5:krb5i:krb5p
à la place. - Du côté client, veuillez ajouter
sec=krb5
(ousec=krb5i
, ousec=krb5p
, en fonction de l'installation) aux options de montage.
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/.
8.8.2.1. Sécurité NFS avec NFSv4
NFSv4 inclut la prise en charge des ACL basée sur le modèle Microsoft Windows NT, et non sur le modèle POSIX, à cause des fonctionnalités et du déploiement global de ce dernier.
Une autre fonctionnalité importante de NFSv4 est la suppression de l'utilisation du protocole
MOUNT
pour monter les systèmes de fichiers. Ce protocole présentait des failles de sécurité possibles à cause de la manière par laquelle il traitait les identificateurs de fichiers.
8.8.3. Permissions de fichier
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
.