Network File System


Network File System
(NFS)
Familia Protocolos de sistema de archivos en red
Función Acceso a sistema de archivos vía red.
Última versión NFSv4
Puertos 2049
Ubicación en la pila de protocolos*
Aplicación NFS
Presentación XDR
Sesión ONC RPC
Transporte TCP o UDP
Red IP
* según el Modelo OSI
Estándares
RFC 1094 (versión 2)
RFC 1813 (versión 3)
RFC 3530 (versión 4)

Network File System (sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, según el Modelo OSI. Es utilizado para sistemas de archivos distribuido en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. Originalmente fue desarrollado en 1984 por Sun Microsystems, con el objetivo de que sea independiente de la máquina, el sistema operativo y el protocolo de transporte, esto fue posible gracias a que está implementado sobre los protocolos XDR (presentación) y ONC RPC (sesión).[1]​ El protocolo NFS está incluido por defecto en los Sistemas Operativos UNIX y la mayoría de distribuciones Linux.

Todas las operaciones sobre ficheros son síncronas. Esto significa que la operación solo retorna cuando el servidor ha completado todo el trabajo asociado para esa operación. En caso de una solicitud de escritura, el servidor escribirá físicamente los datos en el disco, y si es necesario, actualizará la estructura de directorios, antes de devolver una respuesta al cliente. Esto garantiza la integridad de los ficheros.

Índice

Arquitectura


Suponemos que un cliente de un sistema de archivos (NFS) de red trata de montar un directorio sacado del servidor NFS a un directorio local. Para llevar a cabo esto, necesitara la siguiente orden:

$sudo mount -t nfs maquina_remota:/home /dir_local

En esta orden especificamos el tipo de sistema de archivos que se va a montar con –t, la máquina remota y el directorio donde vamos a montarlo.

Esta orden lo que trata es conectar con el demonio rpc mountd que se está ejecutando en la máquina remota a través de RPC. El servidor comprueba los permisos del cliente sobre el directorio /home donde se va a montar y si los tiene se lleva a cabo el montaje como si fuera cualquier otro dispositivo físico. Una vez realizado el montaje, cuando se acceda al directorio del cliente se estará accediendo al directorio del servidor remoto.

Cuando el directorio /dir_local tenga ya montado el directorio /home de la máquina remota, la única protección que tienen los archivos de dicho directorio son sus permisos.

Al acceder a los archivos del directorio NFS se generará una llamada RPC al demonio rpc nfsd en el servidor, en la cual van incluidos los parámetros correspondientes al UID y el GID del usuario y el descriptor del archivo, con los que se comprobarán los permisos.

Implementación típica


Suponiendo un escenario de estilo Unix en el que una máquina (el cliente) necesita acceder a los datos almacenados en otra máquina (el servidor NFS):

Cliente NFS


El cliente simula las funcionalidades del sistema de archivos de UNIX, integrado directamente en el kernel. Se encarga de controlar las peticiones del VFS al servidor. Manda los bloques o archivos desde el servidor y hasta el servidor. Cuando es posible almacena en la caché local los bloques.

Memoria caché

El módulo cliente de NFS guarda en caché los resultados de las operaciones <readwritegetattlookup> y readdir. Los clientes son responsables de sondear al servidor para comprobar la actualidad de sus datos de caché.

Método de marcas temporales para mantener las cachés:

Cada elemento es etiquetado con dos tiempos diferentes, uno el de la última vez que se validó el elemento y otro la última vez que fue modificado en el servidor. Una entrada en caché es válida en un momento t si t-tiempo que se validó por última vez es menor que el intervalo de refresco tolerado. Si no es válida la entrada se obtiene el tiempo en el que se modificó por última vez en el servidor y si es igual al del cliente, entonces la entrada es válida y se actualiza el tiempo del cliente, si no la entrada es invalida.

Para minimizar las llamadas a getattr, cuando se recibe un valor del servidor de un archivo, se aplica a todas las entradas relevantes de dicho archivo.

Aún con esto habrá problemas de consistencia si tenemos escrituras en dos clientes con una diferencia de tiempo menos que el intervalo de refresco tolerado. Para solucionar este problema tendremos que usar bloqueo de archivos convirtiendo en una sección crítica el archivo, esto se consigue en NFS mediante el protocolo Network Lock Manager (NLM).

Servidor NFS


El servidor NFS es parte del núcleo Linux, en los núcleos que Debian provee está compilado como un módulo de núcleo. Su interfaz está definida en el RFC 1813.

Se encarga de recibir las peticiones, que pueden ser similares a las de modelo de archivos plano o pueden simular las del sistema de UNIX.

El servidor también ofrece servicios de montaje, de control de autenticación y acceso y una caché.

Memoria caché

Hay dos opciones para mantener y asegurar la consistencia en escritura:

Los demonios imprescindibles del servicio NFS son los siguientes:

Seguridad


Si queremos que nuestro servicio NFS sea más seguro deberíamos tener en cuenta una serie de detalles, como son:

  1. Utilizar los comodines (metacaracteres) lo menos posible, ya que podemos dar acceso a más equipos de los que estamos pensando.
  2. Utilizar reglas de Iptables (cortafuegos) para limitar el acceso a los puertos utilizados por los demonios del servicio NFS.
  3. El uso de los archivos /etc/hosts.allow y /etc/hosts.deny no es obligatorio pero es preferible configurarlos para garantizar la seguridad de los datos.
  4. Exportar sistemas de archivos de lectura (ro) siempre que sea posible.
  5. El dueño de los archivos y directorios exportados que sea root ya que es posible mapear el UID de root al del usuario nobody.
  6. Intentar que los archivos exportados no tengan permiso de escritura para el grupo (ACL).
  7. Las versiones 2 y 3 de NFS no disponen de control de acceso para los usuarios concretos. En ellas, cuando un sistema de archivos es exportado, cualquier usuario en cualquier máquina remota conectada al servidor NFS puede acceder a los datos compartidos. El único mecanismo de seguridad que tienen es utilizar el acceso de solo lectura y reducir todos los usuarios a uno común cuyo UID y GID especificamos.
  8. Si no se utiliza la opción de exportación squash, cualquier usuario root en el equipo cliente puede convertirse en un usuario con acceso privilegiado simplemente ejecutando la orden: su - . Conviene siempre tener activada alguna opción de squash.
  9. La versión más segura de NFS es la 4.

<Kerberos>

NFS incluye la identidad del usuario por defecto en las peticiones al servidor, pero solo para compararla con los permisos de accesos, no la valida.

Con kerberos se realiza la autenticación del usuario en el momento del montaje del sistema de archivos. Los resultados de estas autenticaciones se almacenan y se utilizan en cada petición NFS. Esto protege contra la mayoría de ataques.

Versiones NFS


Las versiones de NFS más importantes son NFSv2 (RFC 1094), NFSv3 (RFC 1813) y NFSv4 (RFC 3530).

La versión 2 de NFS es la más utilizada y soportada por los sistemas operativos, a la vez que la más antigua e insegura. La versión 3 es más potente que la 2 pero no es compatible completamente con los clientes de la versión anterior. Estas dos versiones pueden trabajar tanto con TCP como con UDP como protocolo de transporte creando conexiones de red entre cliente y servidor. La ventaja de utilizar UDP es que se minimiza el tráfico de red, pero si se cayera los clientes seguirían mandando mensaje y se saturaría.

En general las versiones 2 y 3 de NFS permiten controlar la exportación y montaje de sistemas de archivos en función del equipo que hace la solicitud, pero no del usuario. Es decir no se contempla un control de acceso al sistema de archivos por usuario. Solo para los equipos. Esto implica que si un sistema de archivos es exportado desde el servidor NFS, cualquier usuario de un equipo remoto cliente NFS podría acceder a él. Los únicos mecanismos de seguridad que quedan en este caso son los permisos de acceso (solo lectura) o utilizar un usuario y grupo únicamente. Lógicamente esto limita bastante la idea de compartición que tenemos todos.

En el caso de la versión 4 de NFS estos problemas de seguridad desaparecen pero, a cambio, tiene unos requerimientos de configuración y servicios adicionales mucho más importantes. Por ejemplo, en la versión 4 la utilización de mecanismos para la autenticación de los usuarios es obligatoria. Para ello y en función del tipo de seguridad seleccionada, se requiere la utilización del servicio Kerberos cuya misión será funcionar como servidor de entrega de tickets (KDC) y que debe estar configurado y funcionando correctamente antes de configurar  el servidor NFSv4. Este requerimiento proporciona seguridad al servicio NFS a cambio de incluir mayor complejidad a su configuración y puesta a punto.

Otra característica importante de NFS4 es la utilización de ACLs (Listas de Control de Acceso) al estilo Windows y que no son soportadas por las versiones 2 y 3 de NFS. Cuando hablamos de ACLs nos referimos a los permisos o derechos de acceso que tiene cada usuario sobre un archivo o directorio y que vienen especificados a modo de listas editables por el administrador del sistema.

Ventajas NFS


Desventajas NFS


Operaciones


Inicialmente NFS soportaba 18 procedimientos para todas las operaciones básicas de E/S.[1]​ Los comandos de la versión 2 del protocolo son los siguientes:[2]

En la versión 3 del protocolo se eliminan los comandos STATFS, ROOT y WRITECACHE; y se agregaron los siguientes:[3]

La versión 4 fue publicada en abril de 2003 y no es compatible con las versiones anteriores. Soporta 41 comandos: NULL, COMPOUND, ACCESS, CLOSE, COMMIT, CREATE, DELEGPURGE, DELEGRETURN, GETATTR, GETFH, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL.[4]

Véase también


Temas relacionados con NFS:

Otros sistemas:

Referencias


  1. a b Sandberg, R. Goldberg, D. Kleiman, S. Walsh D. Lyon, B. (June 1985). «Design and Implementation of the Sun Network File System» (en inglés). Proceedings of the Summer 1985 Usenix Conference. 
  2. RFC 1094 Especificación del protocolo versión 2. (en inglés)
  3. RFC 1813 Especificación del protocolo versión 3. (en inglés)
  4. RFC 3530 Especificación del protocolo versión 4. (en inglés)

Enlaces externos











Categorías: Sistemas de archivos de red | Protocolos de Internet | Protocolos de nivel de aplicación | Protocolos de Sun Microsystems | Sistemas de archivos




A partir de: 22.06.2021 05:46:13 CEST

Fuente: Wikipedia (Autores [Historia])    Licencia: CC-BY-SA-3.0

Modificaciónes: Se eliminaron todas las imágenes y la mayoría de los elementos de diseño relacionados con ellos. Algunos iconos fueron reemplazados por FontAwesome-Icons. Algunas plantillas se eliminaron (como "el artículo necesita expansión) o se asignaron (como" notas de sombrero "). Las clases CSS fueron eliminadas o armonizadas.
Se eliminaron los enlaces específicos de Wikipedia que no conducen a un artículo o categoría (como "Enlaces rojos", "enlaces a la página de edición", "enlaces a portales"). Cada enlace externo tiene un FontAwesome-Icon adicional. Además de algunos pequeños cambios de diseño, se eliminaron los contenedores de medios, mapas, cuadros de navegación, versiones habladas y Geo-microformatos.

Tenga en cuenta: Debido a que el contenido dado se toma automáticamente de Wikipedia en el momento dado, una verificación manual fue y no es posible. Por lo tanto, LinkFang.org no garantiza la precisión y la actualidad del contenido adquirido. Si hay una información que es incorrecta en este momento o tiene una pantalla incorrecta, no dude en Contáctenos: e-mail.
Ver también: Información legal & Política de privacidad.