9.4. Sécuriser NFS

NFS fonctionne bien pour le partage de systèmes de fichiers entiers avec un grand nombre d'hôtes connus et d'une manière largement transparente. Beaucoup d'utilisateurs accédant aux fichiers grâce à un montage NFS ne se rendent pas compte que le système de fichiers qu'ils sont en train d'utiliser ne se trouve pas vraiment sur leur système local. De ce fait, et avec l'habitude d'utilisation, divers problèmes potentiels de sécurité peuvent surgir.

Les points suivants doivent être considérés lorsque des systèmes de fichiers NFS sont exportés sur un serveur où 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.

9.4.1. Accès des hôtes

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é. Le contrôle d'accès n'est possible pour les utilisateurs, que par les permissions de fichier et de répertoire. 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 utilisateurs à une ID d'utilisateur et de groupe commune. Ceci étant, de telles solutions peuvent empêcher l'utilisation du partage NFS de la manière originellement prévue.

De plus, si un agresseur prend le contrôle du serveur DNS utilisé par le système effectuant l'exportation 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 serveurs NIS compromis courent le même risque, si des groupes réseau NIS sont utilisés pour permettre à certains hôtes de monter un partage NFS. En utilisant des adresses IP situées dans /etc/exports, ce genre d'attaque devient plus difficile.

Les caractères génériques doivent être utilisés avec parcimonie lorsque la persmission d'exporter des partages NFS est attribuée car le champs d'action de ces caractères génériques peut s'étendre à un plus grand nombre de systèmes que prévus.

Pour de plus amples informatons sur la sécurisation de NFS, reportez-vous au chapitre intitulé Sécurité du serveur du Guide de sécurité de Red Hat Linux.

9.4.2. Permissions de fichiers

Une fois que le système de fichier NFS est monté en lecture-écriture par un hôte distant, la seule protection dont dispose chacun des fichiers partagés réside dans ses permissions. Si deux utilisateurs partageant la même valeur d'ID d'utilisateur montent le même système de fichier NFS, ils pourront modifier les fichiers mutuellement. De plus, toute personne connectée en tant que super-utilisateur (ou root) sur le système client peut utiliser la commande su - pour devenir un utilisateur ayant accès à des fichiers particuliers via un partage NFS. Pour de plus amples informations sur les conflits entre NFS et les ID d'utilisateur, reportez-vous au chapitre intitulé Gestion de comptes et groupes du Guide d'administration système de Red Hat Linux.

Le comportement par défaut lors de l'exportation 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 d'assigner à l'ID d'utilisateur d'une personne quelconque accédant au partage NFS en tant que super-utilisateur (ou root) sur son ordinateur local, une valeur du compte personne (nobody) du serveur. Il est vivement conseillé de ne jamais désactiver la fonction de 'root squashing'.

Si l'exportation d'un partage NFS ne doit se faire qu'en lecture-seule, songez à utiliser l'option all_squash, qui attribue à tout utilisateur accédant au système de fichiers exporté, l'ID d'utilisateur personne (nobody).