NFS trabaja muy bien compartiendo sistemas de archivos enteros con un gran n�mero de hosts conocidos de una manera muy transparente. Sin embargo, esta facilidad de uso trae una variedad de problemas potenciales de seguridad.
Los puntos siguientes deber�an ser considerados cuando se exporten sistemas de archivos NFS en un servidor o cuando se monten en un cliente. Haciendo esto reducir� los riesgos de seguridad NFS y proteger� mejor los datos en el servidor.
Para una lista concisa de los pasos que los administradores deben seguir al asegurar servidores NFS, consulte el cap�tulo titulado Seguridad del servidor en el Manual de seguridad de Red Hat Enterprise Linux.
9.5.1. Acceso al sistema
La versi�n de NFS que planee implementar, depende de su red existente y de sus preocupaciones de seguridad. La secci�n siguiente explica las diferencias entre las medidas de seguridad con NFSv2, NFSv3 y NFSv4. Si es posible, utilice NFSv4. Es el m�s recomendado.
9.5.1.1. Uso de NFSv2 o NFSv3
NFS controla quien puede montar y exportar sistemas de archivos basados en la m�quina que hace la petici�n, no el usuario que utiliza el sistema de archivos. Los hosts tienen que tener los derechos para montar los sistemas de archivos exportados expl�citamente. El control de acceso no es posible para usuarios, aparte de los permisos de archivos y directorios. En otras palabras, una vez que un sistema de archivos es exportado v�a NFS, cualquier usuario en cualquier m�quina remota conectada al servidor NFS puede acceder a los datos compartidos. Para limitar estos riesgos potenciales, los administradores s�lo pueden permitir acceso de s�lo-lectura o reducir a los usuarios a un usuario com�n y groupid. Pero estas soluciones pueden impedir que la compartici�n NFS sea usada de la forma en que originalmente se pens�.
Adicionalmente, si un atacante gana el control del servidor DSN usado por el sistema que exporta el sistema de archivos NFS, el sistema asociado con un nombre de host concreto o nombre de dominio totalmente cualificado, puede ser dirigido a una m�quina sin autorizaci�n. En este punto, la m�quina desautorizada es el sistema que tiene permitido montar la compartici�n NFS, ya que no hay intercambio de informaci�n de nombre de usuario o contrase�a para proporcional seguridad adicional al montaje NFS.
Los comodines o metacaracteres deben ser usados lo menos posible cuando garantizamos el acceso a una compartici�n NFS. El uso de los comodines puede incluir m�s sistemas de los que se desean.
Tambi�n es posible restringir el acceso al servicio portmap a trav�s de los TCP wrappers. El acceso a los puertos usados por portmap, rpc.mountd y rpc.nfsd se puede limitar creando reglas de cortafuegos con iptables.
Para m�s informaci�n sobre la seguridad en NFS y portmap, consulte el cap�tulo llamado Seguridad del servidor en el Manual de seguridad de Red Hat Enterprise Linux. Se puede encontrar informaci�n adicional sobre los cortafuegos en Cap�tulo 18.
9.5.1.2. Uso de NFSv4
El lanzamiento de NFSv4 trajo consigo una revoluci�n para la autentificaci�n y la seguridad cuando se comparten directorios a trav�s de NFS. NFSv4 manda la implementaci�n del m�dulo del kernel RPCSEC_GSS, el mecanismo GSS-API de la versi�n Kerberos 5, SPKM-3, y LIPKEY. Con NFSv4, los mecanismos de seguridad obligatorios est�n orientados hacia la autenticaci�n de usuarios individuales y no a m�quinas clientes, como lo hace NFSv2 y NFSv3.
 | Nota |
|---|
| | Se asume que se tiene instalado un servidor de entrega de t�ckets (KDC) y que est� configurado de la forma correcta, antes de configurar el servidor NFSv4. |
NFSv4 incluye el soporte a ACL basado en el modelo de Microsoft Windows NT, no en el modelo POSIX, por sus funcionalidades y porque es implementado ampliamente. NFSv2 y NFSv3 no son compatibles con los atributos nativos de ACL.
Otra funcionalidad de seguridad importante de NFSv4 es la eliminaci�n del demonio rpc.mountd. El demonio rpc.mountd presentaba posibles agujeros de seguridad debido a la forma en que trataba con los manejadores de archivos.
Para m�s informaci�n sobre la estructura de RPCSEC_GSS, incluyendo c�mo rpc.svcgssd y rpc.gssd interoperan, consulte en https://www.citi.umich.edu/projects/nfsv4/gssd/.
9.5.2. Permisos de archivos
Una vez que el sistema de archivos es montado como lectura/escritura por un host remoto, la �nica protecci�n que tiene cada archivo compartido son sus permisos. Si dos usuarios que comparten el mismo valor de identificador de usuario montan el mismo NFS, ellos podran modificar sus archivos mutuamente. Adicionalmente, cualquiera con acceso root en el sistema cliente puede usar el comando su - para volverse un usuario que tenga acceso a determinados archivos a trav�s de la compartici�n NFS. Para m�s detalles sobre los conflictos entre NFS y ID de usuarios, consulte el cap�tulo llamado Administraci�n de cuentas de usuario y acceso a recursos en el Introducci�n a la administraci�n de sistemas de Red Hat Enterprise Linux.
Por defecto, las listas de control de acceso (ACLs) son soportados por NFS bajo Red Hat Enterprise Linux. No se recomienda desactivar esta funcionalidad. Para m�s detalles sobre esta funcionalidad, consulte el cap�tulo llamado Sistema de archivos de red (NFS) en el Manual de administraci�n del sistema de Red Hat Enterprise Linux.
El comportamiento predeterminado cuando se est� exportando un sistema de archivos a trav�s NFS es usar aplastamiento de root. Esto coloca el identificador del usuario de cualquiera que est� accediendo a la compartici�n NFS, como el usuario root en su m�quina local a un valor de la cuenta de nfsnobody. Nunca desactive el aplastamiento (squashing) de root.
Si se est� exportando una compartici�n NFS como de s�lo lectura, considere usar la opci�n all_squash, la cual hace que todos los usuarios accesando el sistema de archivos exportado tomen el ID de usuario del nfsnobody.
