9.5. Sécurisation de NFS
NFS est tout à fait approprié pour le partage de systèmes de fichiers entiers avec un grand nombre d'hôtes connus et d'une manière transparente. Toutefois, étant donné la facilité d'utilisation, divers problèmes potentiels de sécurité peuvent surgir.
Il est important de prendre en considération les points suivants lorsque des systèmes de fichiers NFS sont exportés sur un serveur ou lorsqu'ils sont montés sur un client. Ce faisant, les risques de sécurité NFS seront minimisés et les données stockées sur le serveur seront mieux protégées.
Pour obtenir une liste complète des étapes que les administrateurs doivent suivre afin de sécuriser les serveurs NFS, reportez-vous au chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Enterprise Linux.
9.5.1. Accès des hôtes
La version de NFS que vous devriez implémenter dépend de votre réseau actuel et de vos craintes en matière de sécurité. Les sections suivantes expliquent les différences qui existent entre l'implémentation de mesures de sécurité avec NFSv2, NFSv3 et NFSv4. Il est recommandé autant que possible, d'utiliser NFSv4 plutôt que d'autres versions de NFS.
9.5.1.1. Utilisation de NFSv2 ou NFSv3
NFS contrôle qui peut monter un système de fichiers exporté en se basant sur l'hôte qui effectue la requête de montage et non pas sur l'utilisateur qui exploitera effectivement le système de fichiers. Les hôtes doivent se voir accorder des droits explicites pour pouvoir monter le système de fichiers exporté. Les utilisateurs ne peuvent contrôler l'accès que par l'intermédiaire des permissions accordées aux fichier et répertoires. En d'autres termes, une fois qu'un système de fichiers est exporté via NFS, tout hôte distant connecté au serveur NFS peut avoir accès aux données partagées. Afin de limiter les risques potentiels, les administrateurs système peuvent restreindre l'accès à une lecture-seule ou peuvent réduire les permissions des utilisateurs à un ID d'utilisateur et de groupe commun. Ceci étant, de telles solutions peuvent empêcher l'utilisation du partage NFS selon l'intention d'origine.
De plus, si un agresseur prend le contrôle du serveur DNS utilisé par le système effectuant l'export du système de fichiers NFS, le système associé avec un nom d'hôte particulier ou un nom de domaine pleinement qualifié peut renvoyer vers un ordinateur non-légitime. À ce stade, l'ordinateur non-autorisé devient le système ayant l'autorisation de monter le partage NFS, puisqu'aucun nom d'utilisateur ou mot de passe n'est échangé pour fournir une sécurité supplémentaire au montage NFS.
Les caractères génériques doivent être utilisés avec parcimonie lors de l'export de répertoires via NFS car il est possible que le champ d'action de ces caractères génériques englobe à un plus grand nombre de systèmes que prévu.
Il est également possible de restreindre l'accès au service portmap grâce aux enveloppeurs TCP. L'accès aux ports utilisés par portmap, rpc.mountd et rpc.nfsd peut également être limité en créant des règles de pare-feu avec iptables.
Pour obtenir de plus amples informations sur la sécurisation de NFS et portmap, reportez-vous au chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Enterprise Linux. Le Chapitre 18 fournit également des informations supplémentaire sur les pare-feu.
9.5.1.2. Utilisation de NFSv4
La publication de NFSv4 a entraîné une révolution en matière d'authentification et de sécurité pour les exports NFS. NFSv4 rend obligatoire l'implémentation du module noyau RPCSEC_GSS, le mécanisme GSS-API de la version 5 de Kerberos, SPKM-3 et LIPKEY. Avec NFSv4, les mécanismes de sécurité obligatoires sont orientés vers l'authentification individuelle des utilisateurs et non pas vers celle des machines clientes comme c'était le cas sous NFSv2 et NFSv3.
 | Remarque |
|---|---|
On suppose qu'un serveur d'émission de tickets Kerberos (ou KDC de l'anglais Key-Distribution Center) est correctement installé et configuré avant la configuration d'un serveur NFSv4. |
NFSv4 inclut la prise en charge d'ACL basée sur le modèle Microsoft Windows NT, et non pas sur le modèle POSIX, en raison de ses fonctionnalités et parce qu'il est d'un déploiement plus répandu. NFSv2 et NFSv3 n'ont pas de prise en charge pour les attributs natifs d'ACL.
La suppression du démon rpc.mountd est une autre fonctionnalité de sécurité importante de NFSv4. Le démon rpc.mountd était à l'origine de brèches de sécurité potentielles en raison de la manière selon laquelle il traitait les gestionnaires de fichiers.
Pour obtenir de plus amples informations sur le cadre RPCSEC_GSS, y compris comment rpc.svcgssd et rpc.gssd opèrent entre eux, rendez-vous à l'adresse suivante : http://www.citi.umich.edu/projects/nfsv4/gssd/.
9.5.2. Permissions de fichiers
Une fois que le système de fichiers NFS est monté en lecture-écriture par un hôte distant, la seule protection dont dispose chacun des fichiers partagés se situe au niveau de 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 modifier les fichiers mutuellement. De plus, toute personne connectée en tant que super-utilisateur sur le système client peut utiliser la commande su - pour devenir un utilisateur ayant accès à des fichiers particuliers via le partage NFS. Pour obtenir de plus amples informations sur les conflits entre NFS et les ID d'utilisateur, reportez-vous au chapitre intitulé Gestion des comptes utilisateur et de l'accès aux ressources du manuel Introduction à l'administration système de Red Hat Enterprise Linux.
Par défaut, les listes de contrôle d'accès (LCA) sont prises en charge par NFS sous Red Hat Enterprise Linux. Il est déconseillé de désactiver cette fonction. Pour obtenir de plus amples informations sur cette fonction, reportez-vous au chapitre intitulé Système de fichiers réseau (NFS) du Guide d'administration système de Red Hat Enterprise Linux.
Le comportement par défaut lors de l'export d'un système de fichiers via NFS consiste à utiliser la fonction de réduction du super-utilisateur (ou root squashing). Cette dernière permet de définir l'ID d'utilisateur d'une personne quelconque accédant au partage NFS en tant que super-utilisateur sur son ordinateur local, une valeur du compte personne (nobody) du serveur. Il est vivement conseillé de ne jamais désactiver cette fonction.
Si vous exportez un partage NFS en lecture-seule, songez à utiliser l'option all_squash qui donne à tout utilisateur accédant au système de fichiers exporté, l'ID d'utilisateur de nfsnobody (personne).