Exportación NFS fijada a una dirección VPN: qué no demuestra
Una regla de exportación comprueba de dónde vino el paquete; AUTH_SYS afirma un UID local y Kerberos autentica a un usuario. Decida cuál necesita su servicio de archivos.
Un host exporta un directorio a una dirección VPN, el montaje funciona y el diseño queda documentado como autenticado. Lo que esa regla limita en realidad es de dónde parecen venir los paquetes. Que la persona que impulsa la operación de archivos sea quien dice ser depende del sabor de seguridad de NFS, y en la mayoría de las exportaciones de este tipo nadie lo cambió respecto del valor predeterminado.
Tres identidades pueden aparecer en una sola solicitud
El par de VPN lleva una identidad inscrita, como un certificado de cliente o una clave de par. El paquete IP interno lleva una dirección de origen. La operación de archivos lleva las credenciales de usuario que aporte su mecanismo NFS. Un diseño que trata la dirección como sustituto de las tres ha asumido en silencio justo la parte que debía verificar.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Escribir esas tres filas es todo el ejercicio. La mayor parte de la discusión sobre si una exportación es segura se derrumba en cuanto queda claro en qué fila vive cada control.
La propiedad de la dirección es un detalle de implementación
Una pasarela puede asignar una dirección de túnel a un par aceptado o autorizar una subred enrutada para él. Que luego la implementación rechace un paquete cuyo origen interno pertenece a otro cliente es una propiedad de esa implementación, y conviene comprobarlo en lugar de suponerlo.
El código de servidor en espacio de usuario del Community tradicional OpenVPN puede, por ejemplo, rechazar un origen asociado a otro cliente antes de que el paquete se entregue por el dispositivo TUN. Eso es una comprobación de propiedad de dirección con valor real, y sigue sin ser autenticación de usuario NFS, porque no dice nada sobre qué cuenta realiza la operación.
La traducción de origen erosiona incluso eso. Una pasarela NAT puede presentar cada cliente como una sola dirección, y entonces una regla de exportación no puede distinguir a las personas que hay detrás. La precisión aparente de la regla se convierte luego en una ficción que mantiene el diagrama. Si la exportación importa, mantenga el direccionamiento explícito en lugar de dejar que un traductor decida quién cuenta como quién.
Lea el sabor de seguridad antes de confiar en la exportación
La guía de NFS de Red Hat separa sec=sys, que usa UID y GID de UNIX locales mediante AUTH_SYS, de los modos Kerberos. krb5 añade autenticación de usuario, krb5i añade protección de integridad y krb5p añade protección de privacidad para el tráfico.
La credencial AUTH_SYS contiene campos como el UID del llamante y los identificadores de grupo, y el RFC 5531 advierte claramente de que este sabor no proporciona seguridad por sí mismo y depende de protección externa. Ejecutarlo dentro de una VPN aporta protección para el transporte y no cambia nada en la afirmación dentro del paquete.
exportfs -v
showmount -e nfs.example.internalLea el sabor en esa salida antes de leer la lista de clientes. Una exportación que parece restringida puede estarlo solo por dirección mientras cada llamante sigue afirmando el UID que le apetece.
Elija el modelo y luego conserve los permisos
Elija el modelo de autenticación del servicio de archivos adecuado para los clientes que realmente administra. Kerberos exige una identidad y un despliegue de servicio detrás, así que cambiar una opción de montaje no es una migración y sencillamente fallará hasta que existan el dominio Kerberos, los principales y los keytabs.
Con cualquiera de los dos modelos, conserve los permisos de exportación y la autorización del sistema de archivos que limitan lo que puede hacer el principal autenticado. La autenticación le dice quién pregunta; la autorización decide si la respuesta debe ser sí. Fundir ambas en un solo ajuste es como una migración acaba concediendo más de lo que concedía la configuración anterior.
Use la regla de dirección para su propósito real
Restringir el servicio a la ruta y las fuentes aprobadas sigue mereciendo la pena, incluida la política de entrada del host cuando el extremo de la VPN y el servidor NFS comparten máquina. Las reglas que reenvían tráfico no gobiernan las solicitudes dirigidas a un servicio que se ejecuta localmente en el mismo host. Esa laguna explica un número sorprendente de exportaciones que pretendían ser privadas. Compruebe explícitamente la política de entrada local en lugar de suponer que las reglas del túnel la cubren.
Compruebe que otra interfaz o una pasarela con traducción de origen no pueda satisfacer la regla de forma inesperada, y trate eso como razón para establecer la procedencia y no como la afirmación de que falsificar una dirección garantiza un montaje funcional.
Ejecute tres casos de aceptación en lugar de uno. Empiece con un cliente aprobado actuando como usuario aprobado, repita después desde un par que nunca fue aprobado y luego intente algo que el usuario aprobado todavía no puede hacer. Pregunte después qué cambia si se compromete un cliente autorizado, porque la autenticación de transporte no hace fiable cada proceso de esa máquina. Un certificado robado y una cuenta local curiosa son problemas distintos con controles distintos.