
Finalmente conseguimos que el último de nuestros usuarios recalcitrantes de Windows 7 usara Windows 10 gracias a la reciente retirada de MS del soporte del primero, por lo que toda la empresa ahora es Ubuntu 18.04 o Windows 10.
Debido a que Windows 10 tiene un cliente NFS, la pregunta ahora es si abandonar SAMBA en favor de NFS.
Específicamente, ¿existe alguna razón para conservar SAMBA ahora que todos nuestros clientes Windows admiten NFS?
Respuesta1
SMB 3.xx tiene un rendimiento mejor ajustado que la conectividad TCP "genérica" y tiene características como RDMA y soporte multicanal que Microsoft no implementó con "su" cliente NFS (en realidad, con licencia).
Respuesta2
Server Message Block (SMB), el protocolo utilizado por el software Samba, podría implementarse más fácilmente con suficiente seguridad. Network File System, abreviado NFS, ha sido llamado en broma "Sin seguridad de archivos". Ese es el nombre en broma, pero "Sin seguridad a nivel de archivos" puede ser un nombre con algunas implicaciones precisas. En otras palabras, la seguridad de NFS se basa en compartir una partición, no un archivo individual, por lo que el protocolo NFS no aplica los permisos a nivel de archivo.
Según mi lectura, es posible que un servidor NFS preste atención a los archivos y rechace solicitudes no válidas. Sin embargo, no todo el software NFS hace eso. El protocolo tiende a hacer que el cliente solicite un bloque de datos en una unidad, y un servidor podría cumplir esa solicitud leyendo el bloque del disco sin necesariamente tener que prestar atención a de qué archivo forma parte ese bloque.
Incluso si descubre que una implementación de NFS es segura, ¿qué impide la posibilidad de que un cambio en el futuro resulte en una implementación/implementación menos segura de NFS? Si tiene dudas sobre la seguridad, puede que valga la pena tener una respuesta a esa pregunta.
Con SMB, las personas comparten directorios en lugar de particiones. Esto puede ayudarle a sentirse seguro de que está compartiendo solo el directorio que desea y no otros directorios ubicados en una parte diferente de la jerarquía de una unidad.
Editar: Aquí viene un nuevo retador. Un comentario a esta respuesta ha afirmado que esto está fuera de objetivo. Entonces, busqué documentación tradicional que ayude a respaldar esto. Y encontré fácilmente material que respalda las afirmaciones de mi respuesta:
Primero y ante todo,"Redes seguras Inc." publicó un "Aviso de seguridad" del 7 de marzo de 1997, titulado "Manejadores de archivos NFS 4.4BSD". (Ese hipervínculo es del sitio web de OpenBSD:Archivo de lista de correo BugTraq de SecList.org de 1997: identificadores de archivos NFS 4.4BSDmuestra lo mismo publicado como parte de una lista de correo antigua, pero agrega un encabezado. PacketStormSecurity: Aviso sobre controladores de archivos SNI BSDtambién muestra el mismo documento.)
Este artículo analiza la naturaleza basada en bloques de cómo NFS entregó datos (y probablemente sea la fuente de mi comprensión de esta vulnerabilidad en particular).
Ese documento ha sido alojado por múltiples organizaciones. Aquí hay un informe diferente, aparentemente sin ninguna relación con ese documento: partes de"Por qué NFS apesta", por "Olaf Kirch" de "SUSE/Novell Inc."[correo electrónico protegido]decir:
"A NFS no le importa si lo que exporta es reiser, ext3 o XFS, un CD o un DVD. Una consecuencia directa de esto es que NFS necesita un mecanismo bastante genérico para identificar los objetos que residen en un sistema de archivos". ... "Sólo el servidor necesita comprender el formato interno de un identificador de archivo". ... "Linux introdujo el concepto de caché de directorio, también conocido como dcache. Una entrada en dcache se llama dentry" ... "prácticamente todas las funciones en la capa VFS esperan un dentry como argumento en lugar de (o además a) el objeto de inodo que solían tomar." "Esto hizo que las cosas fueran interesantes para el servidor NFS, porque la información del inodo ya no es suficiente para crear algo en lo que la capa VFS esté dispuesta a operar"... "los atacantes podrían interceptar un paquete con credenciales válidas y manipular la solicitud NFS para hacerlo sus propias y nefastas órdenes."
En cuanto a mi afirmación sobre el apodo, https://news.ycombinator.com/item?id=10967064hace copias de seguridad:
En 1987, los ingenieros de Sun sabían que NFS significaba "No File Security".
La primera pantalla muestra algunas vulnerabilidades diferentes, incluida la confianza en alguien según el nombre de host informado por la computadora cliente.
Google Books: material citado de "Una guía práctica para Ubuntu Linux"notas:
La seguridad NFS predeterminada es marginal o inexistente (un chiste común es que NFS significa No File Security o Nightmare File System), por lo que no se debe permitir dicho acceso fuera de su red a máquinas en las que no confía.
Sección de eTutorials.org sobre configuración de NFSnotas:
Si monta sus sistemas de archivos a través de Internet, los archivos transferidos pueden ser interferidos e incluso alterados en cualquier momento (algunas personas bromean diciendo que NFS es la abreviatura de "Sin seguridad de archivos").