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�: https://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).
