Exportación NFS fixada a un enderezo VPN: que non demostra
Unha regra de exportación comproba de onde veu o paquete; AUTH_SYS afirma un UID local e Kerberos autentica un usuario. Decida cal necesita o seu servizo de ficheiros.
Un host exporta un directorio a un enderezo VPN, a montaxe funciona e o deseño queda documentado como autenticado. O que esa regra limita en realidade é de onde parecen vir os paquetes. Que a persoa que impulsa a operación de ficheiros sexa quen di ser depende do perfil de seguridade de NFS, e na maioría das exportacións deste tipo ninguén o cambiou respecto do valor predeterminado.
Tres identidades poden aparecer nunha soa solicitude
O par de VPN leva unha identidade inscrita, como un certificado de cliente ou unha chave de par. O paquete IP interno leva un enderezo de orixe. A operación de ficheiros leva as credenciais de usuario que achegue o seu mecanismo NFS. Un deseño que trata o enderezo como substituto das tres asumiu en silencio xusto a 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 é todo o exercicio. A maior parte da discusión sobre se unha exportación é segura derrúbase en canto queda claro en que fila vive cada control.
A propiedade do enderezo é un detalle de implementación
Unha pasarela pode asignar un enderezo de túnel a un par aceptado ou autorizar unha subrede encamiñada para el. Que despois a implementación rexeite un paquete cuxa orixe interna pertence a outro cliente é unha propiedade desa implementación, e paga a pena comprobalo en lugar de supoñelo.
O código de servidor en espazo de usuario do Community tradicional OpenVPN pode, por exemplo, rexeitar unha orixe asociada a outro cliente antes de que o paquete se entregue polo dispositivo TUN. Iso é unha comprobación de propiedade de enderezo con valor real, e segue sen ser autenticación de usuario NFS, porque non di nada sobre que conta realiza a operación.
A tradución de orixe erosiona incluso iso. Unha pasarela NAT pode presentar cada cliente como un único enderezo, e entón unha regra de exportación non pode distinguir as persoas que hai detrás. A precisión aparente da regra convértese logo nunha ficción que mantén o diagrama. Se a exportación importa, manteña o direccionamento explícito en lugar de deixar que un tradutor decida quen conta como quen.
Lea o perfil de seguridade antes de confiar na exportación
A guía de NFS de Red Hat separa sec=sys, que usa UID e GID de UNIX locais mediante AUTH_SYS, dos modos Kerberos. krb5 engade autenticación de usuario, krb5i engade protección de integridade e krb5p engade protección de privacidade para o tráfico.
A credencial AUTH_SYS contén campos como o UID do chamante e os identificadores de grupo, e o RFC 5531 advirte claramente de que este perfil non proporciona seguridade por si mesmo e depende de protección externa. Executalo dentro dunha VPN achega protección para o transporte e non cambia nada na afirmación dentro do paquete.
exportfs -v
showmount -e nfs.example.internalLea o perfil nesa saída antes de ler a lista de clientes. Unha exportación que parece restrinxida pode estalo só por enderezo mentres cada chamante segue afirmando o UID que lle apetece.
Escolla o modelo e logo conserve os permisos
Escolla o modelo de autenticación do servizo de ficheiros axeitado para os clientes que realmente administra. Kerberos esixe unha identidade e un despregamento de servizo detrás, así que cambiar unha opción de montaxe non é unha migración e simplemente fallará ata que existan o dominio Kerberos, os principals e os keytabs.
Con calquera dos dous modelos, conserve os permisos de exportación e a autorización do sistema de ficheiros que limitan o que pode facer o principal autenticado. A autenticación dinlle quen pregunta; a autorización decide se a resposta debe ser si. Fundir ambas nun só axuste é como unha migración acaba concedendo máis do que concedía a configuración anterior.
Use a regra de enderezo para o seu propósito real
Restrinxir o servizo á ruta e ás fontes aprobadas segue merecendo a pena, incluída a política de entrada do host cando o extremo da VPN e o servidor NFS comparten máquina. As regras que reenvían tráfico non gobernan as solicitudes dirixidas a un servizo que se executa localmente no mesmo host. Esa lagoa explica un número sorprendente de exportacións que pretendían ser privadas. Comprobe explicitamente a política de entrada local en lugar de supoñer que as regras do túnel a cobren.
Comprobe que outra interface ou unha pasarela con tradución de orixe non poida satisfacer a regra de forma inesperada, e trate iso como razón para establecer a procedencia e non como a afirmación de que falsificar un enderezo garante unha montaxe funcional.
Executa tres casos de aceptación en lugar de un. Comeza cun cliente aprobado actuando como usuario aprobado, repite despois desde un par que nunca foi aprobado e logo tenta algo que o usuario aprobado aínda non pode facer. Pregunta despois que cambia se se compromete un cliente autorizado, porque a autenticación de transporte non fai fiable cada proceso desa máquina. Un certificado roubado e unha conta local curiosa son problemas distintos con controis distintos.