Endurecer exportaciones NFS: alcance de red, opciones squash y sec=krb5 en lugar de AUTH_SYS

Objetivo

Reducir lo que una exportación NFS da por bueno de sus clientes: qué hosts pueden conectarse, qué UID/GID puede declarar una petición y si el servidor puede exigir una prueba criptográfica de identidad en lugar de fiarse de lo que dice el cliente.

Requisitos previos

Una exportación existente en /etc/exports. Para la opción con Kerberos se necesita un realm Kerberos operativo, una clave nfs/<fqdn> en el keytab del servidor, gssproxy (o el antiguo rpc.svcgssd) en el servidor y rpc.gssd en los clientes; esa configuración queda fuera del alcance de este artículo.

Pasos

1. No exportes nunca a todos los hosts. exports(5) permite que una exportación se dirija a un único host, a un patrón de nombres o a una subred completa con la forma address/netmask; limita cada exportación a la red más pequeña que la necesite.
2. Mantén root_squash (el valor por defecto): esta opción asigna las peticiones de uid/gid 0 al uid/gid anónimo, de modo que un cliente que se presente como root no obtiene root sobre los archivos del servidor. No impide que el root del cliente cambie a cualquier otro UID y actúe como ese usuario. Quítala (no_root_squash) solo para un host de administración concreto y de confianza que realmente lo necesite.
3. En las exportaciones donde no se deba confiar en ningún UID aportado por el cliente (por ejemplo, un directorio compartido de depósito), usa all_squash para que todas las peticiones se asignen a la cuenta anónima, sea cual sea el UID que presenten.
4. Entiende por qué es importante: las consideraciones de seguridad de nfs(5) indican que los servidores NFS controlan el acceso a los datos de los archivos, pero dependen de su implementación de RPC para la autenticación, y la implementación tradicional representa a cada usuario con un simple número que proporciona el propio cliente; el servidor no lo verifica de forma independiente.
5. Cuando los datos lo justifiquen, pasa la exportación y el montaje del cliente a sec=krb5 (solo autenticación), krb5i (más integridad) o krb5p (más cifrado). nfs(5) documenta sec= como una lista separada por dos puntos de uno o más sabores de seguridad que se usarán para acceder a los archivos del montaje, con krb5, krb5i y krb5p entre los sabores válidos; la línea de exportación admite una opción sec= equivalente para exigirlo.
6. Vuelve a exportar con exportfs -ra y comprueba qué sabor negoció realmente un cliente consultando las opciones del montaje en el cliente (cat /proc/mounts o nfsstat -m).

Resultado esperado

Se rechazan los montajes desde fuera de la red configurada; un cliente que presente UID 0 se asigna a la cuenta anónima en las exportaciones con squash; y cuando la exportación lista solo sabores sec=krb5*, se rechaza el acceso sin credenciales Kerberos válidas (al montar o en el primer acceso) en lugar de recurrir a AUTH_SYS.

Límites y base de verificación

AUTH_SYS concede a cada usuario de cada cliente permitido el acceso que implica su UID; root_squash solo afecta a root, y all_squash solo encaja en exportaciones donde no hace falta propiedad por usuario. NFS con Kerberos depende de una sincronización horaria correcta y de un keytab bien mantenido: si el KDC falla, los montajes dejan de funcionar en lugar de degradarse en silencio, así que prueba los cambios en una ventana de mantenimiento. Conserva una copia del /etc/exports anterior antes de endurecerlo.