9.5. Cómo proteger NFS

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.

NotaNota
 

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 http://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.