Sécuriser NFS

NFS fonctionne bien pour partager des systèmes de fichiers entiers avec de nombreux hôtes connus et de façon très transparente. Nombre d'utilisateurs ont accès à des fichiers sur un montage NFS sans même s'apercevoir que le système de fichiers qu'ils utilisent n'appartient pas à leur système local. Cependant, la facilité d'utilisation va de paire avec toute une série de problèmes potentiels de sécurité.

Vous devriez tenir compte des informations suivantes lorsque vous exportez des systèmes de fichiers NFS sur un serveur ou les montez sur un client. Ainsi, vous minimiserez les risques de sécurité NFS et protégerez mieux vos données et votre équipement.

Accès hôte

NFS contrôle qui peut monter et exporter un système de fichiers en fonction de l'hôte présentant la demande de montage et non en fonction de l'utilisateur qui utilise le système de fichiers. Les hôtes doivent obtenir des droits explicites pour monter un système de fichiers. Le contrôle d'accès n'est cependant pas possible pour les utilisateurs, si ce n'est les autorisations de fichier et de répertoire. Autrement dit, lorsque vous exportez un système de fichiers via NFS vers un hôte distant, vous ne faites pas confiance uniquement à l'hôte qui monte le système de fichiers, mais aussi aux utilisateurs qui ont accès à cet hôte et, par conséquent, à votre système de fichiers. Ce risque peut être contrôlé, en exigeant des montages en lecture seule par exemple ou en réduisant (squash) les utilisateurs à un ID utilisateur et groupe commun, ce qui peut empêcher toutefois que le montage ne soit utilisé de la façon souhaitée à l'origine.

De plus, si l'auteur d'une attaque prend le contrôle du serveur DNS utilisé par le système qui exporte le système de fichiers NFS, le système associé à un nom d'hôte spécifique ou à un nom de domaine pleinement qualifié peut être pointé vers un ordinateur non autorisé. A ce stade, l'ordinateur non autorisé est le système autorisé à monter le partage NFS car aucune information de nom d'utilisateur ou de mot de passe n'est échangée pour fournir plus de sécurité au montage NFS. Les mêmes risques s'appliquent aux serveurs NIS compromis, si les groupes réseau NIS sont utilisés pour permettre à certains hôtes de monter un partage NFS. En utilisant une adresse IP dans /etc/exports, ce genre d'attaque est plus difficile.

Les caractères spéciaux devraient être utilisés avec modération lorsque vous accordez l'accès à un hôte à un partage NFS. La portée du caractère spécial peut englober des systèmes dont vous ignorez l'existence et qui ne devraient pas être autorisés à monter le système de fichiers.

Autorisations de fichier

Lorsqu'un système de fichiers est monté en lecture-écriture par un hôte distant, la seule protection pour les fichiers partagés repose dans leurs autorisations et leur appartenance à un utilisateur et un groupe. Si deux utilisateurs partageant la même valeur d'ID utilisateur montent le même système de fichiers NFS, ils pourront modifier leurs fichiers l'un et l'autre. De plus, tout individu connecté en tant que super-utilisateur sur le système client peut utiliser la commande su pour devenir un utilisateur ayant accès à des fichiers spécifiques via le partage NFS.

Le comportement par défaut lors de l'exportation d'un système de fichiers via NFS est d'utiliser root squashing. Cela a pour effet de paramétrer sur une valeur du compte nobody du serveur l'ID utilisateur de tout utilisateur se servant du partage NFS en tant que super-utilisateur sur son ordinateur local . Vous ne devriez pas désactiver la réduction du super-utilisateur, à moins que la présence de nombreux super-utilisateurs sur votre système ne vous dérange pas.

Si vous n'autorisez les utilisateurs qu'à lire les fichiers via votre partage NFS, vous pourriez utiliser l'option all_squash, qui fait en sorte que tous les utilisateurs accédant à votre système de fichiers exporté aient l'ID utilisateur de l'utilisateur nobody.