Rechercher

8.8. Sécurisation de NFS

download PDF
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

  1. Créez les principaux nfs/client.mydomain@MYREALM et nfs/server.mydomain@MYREALM.
  2. Ajoutez les clés correspondant aux onglets principaux pour le client et le serveur.
  3. Du côté serveur, veuillez ajouter sec=krb5:krb5i:krb5p à l'export. Pour continuer à autoriser AUTH_SYS, veuillez ajouter sec=krb5:krb5i:krb5p à la place.
  4. Du côté client, veuillez ajouter sec=krb5 (ou sec=krb5i, ou sec=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.
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.