Sistemas de archivos de red seguros para Linux: ¿qué están haciendo las personas?

NFSv3 está muy extendido, pero el modelo de seguridad predeterminado es ... pintoresco . CIFS puede usar la autenticación Kerberos, pero sin la semántica POSIX no es un iniciador. AFS nunca cifró el tráfico en el cable y es krb4, y básicamente es un proyecto muerto. Los nuevos y sofisticados sistemas de archivos experimentales nunca se materializan o se centran en la velocidad (y si tiene suerte, la fiabilidad de los datos), por ejemplo, Luster utiliza el mismo modelo de confianza del cliente que NFSv3. Para uso doméstico, sshfs es ingenioso, pero eso no escala.

Y luego, por supuesto, está NFSv4, con sec = krb5p. Genial en teoría, pero después de diez años, parece ser problemáticamente inutilizado en el mundo real. El cliente de Linux acaba de eliminar la etiqueta experimental. Y si nos fijamos en EMC Celerra, Isilon, etc., todo es NFSv3. (Celerra es compatible con NFSv4, pero está realmente oculto en la documentación. Isilon aparentemente trabajó para agregar el soporte RPCGSS a FreeBSD, así que tal vez esté por llegar, pero ahora no está allí). Ni siquiera puedo etiquetar esta publicación como "nfsv4" porque yo Soy nuevo aquí y eso sería una nueva etiqueta .

Entonces, de verdad . ¿Que están haciendo todos ustedes?

Dado que es una pregunta específica (¿Qué están haciendo?), Respondamos: nada. La mayoría de los administradores y usuarios simplemente no se preocupan por la seguridad de NFS, por lo que todos usan NFSv3. Por lo general, es un entorno controlado (en el sentido de que solo las máquinas conocidas pueden conectarse a la red en primer lugar). Si alguien queda atrapado abusando de la infraestructura, lo despiden o lo encarcelan.

Para los datos que realmente no desea que nadie pueda leer, los encripta explícitamente, por ejemplo, bases de datos de contraseñas de Firefox, claves ssh o claves pgp. Lo hace porque sabe que el administrador podría leerlos en el servidor de archivos, por lo que la seguridad del sistema de archivos de red no sería de ninguna ayuda.

Parece que estás haciendo dos preguntas aquí:

¿Qué estamos usando realmente? y que hace esto

Lo que realmente estoy usando es CIFS, en mis casos de uso POSIX es menos importante, así que no he tenido ningún problema. NFS3 se usa en áreas donde la seguridad no es importante, como mi servidor de instalación SLES. Y finalmente, sshfs / gvfs para compartir fácilmente la tierra del usuario. El cifrado por cable no se considera necesario, por lo que no es un factor significativo para nosotros.

En cuanto a la otra pregunta, parece que hay seis requisitos principales para lo que estás buscando:

1. Cifra el tráfico en el cable.
2. Cifra la autenticación.
3. Posix semántica.
4. Fuerte aplicación de las ACL basadas en servidor.
5. No es userland.
6. En realidad se usa.

Sospecho que los puntos 5 y 6 serán los asesinos aquí, pero aquí va (también, este es el punto donde una tabla sería realmente útil, pero Markdown / StackExchange no lo admite).

NFSv3 + IPSec

1. Cifrado en el cable, pase
2. Sin autenticación cifrada, falla
3. Posix semántica, pase
4. No hay una aplicación estricta de las ACL basadas en servidor, falla
5. No es userland, pase
6. En realidad se usa, pase

NFSv4 + Krb + IPSec

1. Cifrado en el cable, pase
2. Autenticación cifrada, pase
3. Posix semántica, pase
4. Fuerte aplicación de ACL basadas en servidor, pase
5. No es userland, pase
6. En realidad no se usa, falla

CIFS

1. No encriptado en el cable, falla
2. Autenticación cifrada
3. Semántica Posix, pase (Samba y Kernel ahora, Windows ha tenido una capa Posix desde los días de NT)
4. Fuerte aplicación de ACL basadas en servidor, pase
5. No es userland, pase
6. En realidad se usa, pase

CIFS + IPSec

1. Cifrado en el cable, pase
2. Autenticación cifrada
3. Semántica de Posix, pase (Samba y Kernel ahora)
4. Fuerte aplicación de ACL basadas en servidor, pase
5. No es userland, pase
6. En realidad no se usa, falla

SSHFS

1. Cifrado en el cable, pase
2. Autenticación cifrada, pase
3. Posix semántica, pase
4. Fuerte aplicación de ACL basadas en servidor, pase
5. Es tierra de usuarios, falla
6. En realidad se usa, pase

AFP / NetATalk

1. Cifrado en el cable, falla
2. Autenticación cifrada, pase
3. Posix semántica, pase
4. Fuerte aplicación de ACL basadas en servidor, pase
5. No es userland, pase
6. En realidad se usa, falla

Y no estoy tocando los sistemas de archivos distribuidos por ahí. Simplemente no hay una sola cosa que lo haga todo. Algunos se acercan (CIFS) y otros ya están allí, pero nadie los usa (NFS4 + IPSec, CIFS + IPSec). Por alguna razón, un sistema de archivos de red seguro es algo que ha estado sujeto a muchos compromisos a lo largo de los años.

He estado usando openafs en producción durante años, tanto con clientes Linux como Windows. Funciona muy bien, tiene una comunidad de desarrollo activa y se ha vuelto mucho más fácil de instalar y administrar en los últimos años, ya que las diversas distribuciones de Linux han incluido un paquete para ello. Tiene sus verrugas, pero descubrí que están compensadas por una mayor flexibilidad administrativa, la capacidad de tener clientes y servidores separados por enlaces lentos, la facilidad de las copias de seguridad externas y otros AFSismos positivos.

Una cosa que me gusta en particular es ejecutar servidores web de producción orientados a Internet en openafs, con las ACL bloqueadas. Sin un ticket kerberos no hay ningún proceso en la máquina, ni siquiera uno que se ejecute como root, que pueda escribir en el sistema de archivos. No puedo contar cuántas veces hemos notado que los ataques fallan por completo debido a esa simple medida.

Hay algunos usuarios de openafs bastante grandes: el mayor usuario comercial que conozco es Morgan Stanley.

¿Qué hay de OpenAFS que todavía está vivo y una VPN debajo de él porque su único cifrado en este momento es DES?

Veo que muchas personas en este hilo están hablando sobre la ocultación de datos, es decir, los ataques no pueden espiar sus datos. Un aspecto igualmente importante para pensar en la integridad y autenticidad de los datos. ¿Son esos paquetes nfs realmente de su servidor nfs? ¿Se cambió un paquete nfs en tránsito?

Bueno, para mí parece que uno de esos Distributed Filesystems sería para ti. No me gustaría recomendar OpenAFS, ya que es antiguo, todavía no es compatible con IPv6, ..

Estoy bastante contento con GlusterFS . Gluster es bastante maduro, funciona bien y tiene un buen conjunto de características. Sin embargo, como se discutió recientemente en IRC, Gluster tampoco admite IPv6 de manera estable. Esta función se programará para 3.6 o 3.7.

También hay un proyecto llamado HekaFS, que se basa en Gluster, que agrega funciones de autenticación y SSL más avanzadas. Está muy bien documentado y muy bien diseñado.

Lo que también puede ser de interés para usted es XtreemFS , que está diseñado para la computación de red global, por lo que viene con SSL y otras cosas por defecto. Sin embargo, mi elección de uso recayó en Gluster, ya que la comunidad parece más activa y está mejor documentada.

Ambos son compatibles con posix, por supuesto.

Yo uso NFS. Pero el NFS de servidor a servidor se realiza a través de una red troncal de red dedicada, por lo que no se necesita cifrado y la autenticación no tiene sentido. Simplemente configure cada exportación para que solo comparta un directorio seleccionado a un servidor basado en IP.

Con el debido respeto, está mirando completamente este problema de la manera incorrecta y debe alejarse de la consola durante unas horas.

Casi todo el almacenamiento io no está encriptado porque no importa en esa capa de la pila de abstracción. ¿Dudo? Toque su interruptor de fibra de brocado y verá que el canal de fibra, al igual que iscsi y nfs, es todo un desastre sin cifrar, por diseño. Resolver eso es un problema medio, no un problema de protocolo de almacenamiento. Por ejemplo, ¿quieres nfs seguros y encriptados? Creó un lan que está encriptado punto a punto entre el cliente nfs y el servidor usando ipsec / ssl / tls o una solución de hardware puro.