martes, 31 de julio de 2018

NFS



1.- ¿Qué es NFS?

El Network File System (Sistema de archivos de red), o NFS, es un protocolo de nivel de aplicación, desarrollado originariamente por Sun Microsystems en 1984 (por defecto se usa el puerto TCP/UDP 2049).

Dicho protocolo permite a un usuario de un equipo cliente (GNU/LINUX) acceder a un sistema de ficheros remoto a través de una red, de una manera similar a como se accede al sistema de ficheros local o como se hace a través de SMB (Server Message Block), siendo este último nativo en sistemas Windows.

El protocolo NFS utiliza el protocolo de nivel de sesión: RPC (Remote Procedure Call/Llamadas a procedimientos remotos) para establecer la comunicación entre los equipos que compartirán información (por defecto se usa el puerto TCP/UDP 111 - portmap). Básicamente, este protocolo se utiliza por parte del protocolo NFS para comprobar que el servidor NFS realmente tiene el servicio NFS activo, así como para saber el puerto sobre el cual se encuentra montado.

2.- Versiones de NFS.

Las versiones de NFS son:


VERSIÓN
RFC
Comentarios
NFSv2
RFC 1094 - 1983
Es la más extendida, pero también es la más insegura
NFSv3
RFC 1813 - 1995
Es más potente pero no es completamente compatible con clientes NFSv2
NFSv4
RFC 3530 - 2003
Es la más segura de todas
  NFSv4.1
RFC 5661 - 2010
Modificaciones menores que no afecta a su nivel de seguridad
  NFSv4.2
RFC 7862 - 2016
Modificaciones menores que no afecta a su nivel de seguridad.

Más información:  https://tools.ietf.org/wg/nfsv4/

3.- Ventajas e inconvenientes del uso de NFS.

 3.1.- Ventajas.

§         Reducen el riesgo de que el fallo de un solo equipo impida acceder a los datos.
§       Proporcionan ubicaciones centralizadas para los datos que deben o deberían estar compartidas entre todos los usuarios.
§         Simplifican el acceso a los datos existentes en sistemas más veloces.
§      Proporcionan la oportunidad de centralizar operaciones administrativas, tales como la copia de seguridad de los datos (backups).
§        Proporcionan interoperabilidad y flexibilidad. Normalmente se puede acceder a sistemas de ficheros en red desde ordenadores que ejecuten Linux, Windows, Mac OS X, BeOS, BSD, y muchos otros. De esta forma es fácil utilizar el hardware y software más adecuado a los requerimientos de escritorio, y aun así acceder a los mismos datos del entorno de sistema de ficheros en red.

 3.2.- Desventajas.

§     NFSv2 y NFSv3 pueden utilizar UDP como protocolo de transporte que al ser una conexión desatendida, minimiza el tráfico de red, pero si el servidor NFS cayera por cualquier circunstancia, los clientes NFS seguirían enviando peticiones al servidor produciendo el efecto contrario, que es la saturación de la red.
§         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. Sólo 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.
§      NFS sufre algunos problemas de rendimiento debido a su diseño “sin estado” (parte de estos problemas son mitigados en las últimas versiones de NFS). En particular, como el cliente asume que una operación de escritura se completa una vez que recibe el acuse de recibo del servidor, el servidor debe asegurarse de escribir cada bloque a disco antes de responder, para evitar discrepancias en el caso de una caída. Esto introduce un retardo significativo en el caso de escrituras NFS.

4.- Seguridad de NFS

Desde el punto de vista de la seguridad


VERSIÓN
Comentarios
NFSv2
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, sólo se contempla el control de acceso a los recursos publicados mediante la dirección IP del equipo que se quiere conectar.
NFSv3
NFSv4
A las características de las versiones anteriores, se le une el hecho de que  se permite controlar el acceso a los recursos mediante usuario, mediante algún servicio de autenticación (Radius, ACLs, ...)

Ninguna de ellas cifra las comunicaciones, aunque se puede usar NFS a través de SSH, gracias a la capacidad de este para realizar port-forwarding.

Más información: Securización de las comunicaciones NFS a través de SSH (punto 6.4 - Información en inglés): http://nfs.sourceforge.net/nfs-howto/ar01s06.html

Pero veamos de manera más pormenorizada la seguridad en las versiones NFSv3 y NFSv4

4.1.- Seguridad en NFSv3


4.1.1.- Demonios del servicio NFSv3

Los demonios imprescindibles del servicio NFS son los siguientes:


DEMONIO
USO
Comentarios
rpc.mountd
Demonio para el montaje remoto
1.   Se ejecuta en el servidor.
2.   Recibe la petición de montaje desde un cliente NFS y comprueba en el archivo /var/lib/nfs/xtab si el sistema de archivos está exportado. Si el sistema de archivos está disponible, permite las solicitudes de acceso de NFS y después proporciona información sobre los sistemas de archivos mediante el comando showmount.
3.   Comprueba también que el cliente tenga permiso para solicitar acceso.
rpc.nfsd
Demonio para servir archivos.
Gestiona las solicitudes del cliente una vez el demonio "mountd" haya dado el visto bueno al cliente. Se pueden arrancar varias copias de este demonio. Utiliza por defecto el puerto 2049 TCP/UDP.
rpc.portmap
Es el encargado de decir a los clientes donde está localizado (número de puerto) el servicio real en el servidor
Como los servicios basados en RPC utilizan portmap para atender las peticiones de los clientes, este servicio debe estar disponible antes de cualquier otro servicio o demonio de NFS. No se utiliza en NFSv4. Utiliza el puerto TCP/UDP 111
rpc.lockd
Encargado de proporcionar el servicio de bloqueo de archivos para asegurar su consistencia ya que pueden ser accedidos de forma concurrente
Se ejecuta tanto en el servidor como en el cliente
rpc.statd
Trabaja conjuntamente con el demonio: lockd, para permitir la recuperación a una caída de sistemas
Mantiene información sobre los procesos en los clientes que poseen algún archivo determinado en el servidor. Cuando el servidor NFS se recupera, statd informa a los otros procesos statd de los clientes, que el servidor se ha recuperado, y así ellos intentarán resolver los locks que tenían anteriormente. En los clientes statd se utiliza para avisar al servidor de que el cliente ha caído y así poder liberar los archivos que tuviera ese cliente bloqueados


4.1.2.- Archivos de configuración

 

Los archivos de configuración del servicio NFS son los siguientes:


DEMONIO
USO
/etc/fstab
Contiene los sistemas de archivos que pueden ser montados desde sistemas remotos en secuencia de arranque del equipo.
/etc/exports
Contiene una lista de los directorios del sistema local que se van a exportar a sistemas remotos utilizando NFS y los permisos de uso.  Este archivo contiene una línea por cada directorio a compartir.
/var/lib/nfs/etab
Contiene una lista de los sistemas de archivos actualmente exportados para el sistema local. Esta información es actualizada en este archivo cuando se ejecuta el comando exportfs que lee el archivo /etc/exports.
/etc/hosts.allow 
/etc/hosts.deny
NFS utiliza estos archivos para comprobar a qué máquinas se les acepta o deniega el uso de NFS. En general este sistema de comprobación se suele conocer con el nombre de: wrappers TCP

 

4.1.3.- Securización


Se empezará recordando que los datos se transmiten en texto claro.

A continuación se procede a comentar los archivos que deberían ser configurados para bastionar el servicio NFS

4.1.3.1.- /etc/exports

Como se ha comentado en el apartado 4.1.2, este archivo permite indicar al servicio NFS los directorios que se comparten, así como los hosts que van a tener permitido el acceso a dicho directorio, incluyendo los permisos que se tienen sobre el contenido de los mismos.

Cada línea se corresponde con un directorio a compartir.

La estructura de la línea sería la siguiente:

directorio equipo1(opcion11,...) equipo2(opcion21,...)

Donde:

·         directorio: es el nombre del directorio que se comparte
·        equipo<1...n>: es la dirección IP o nombre DNS del hosts que tendrá acceso al recurso compartido

NOTA: Se permite el uso de los comodines: "*" y "?", aunque no se recomienda su uso

·         opcion <11 ... nn>: son las diferentes permisos de acceso que se tendrán por parte del hosts en el directorio compartido. Las opciones más significativas son:

§  ro | rw. el directorio será compartido en solo lectura (ro), opción por defecto, o el directorio será compartido en lectura y escritura (rw).

§  sync | async.  sync comunica al usuario los cambios realizados sobre los archivos cuando realmente se han ejecutado y es la opción recomendada. La opción async mejora el rendimiento y agiliza el funcionamiento del servicio, pero puede generar archivos corruptos si se produce algún tipo de fallo en el servidor.

§  no_subtree_check. permite que no se compruebe el camino hasta el directorio que se exporta, en el caso de que el usuario no tenga permisos sobre el directorio exportado.

§  root_squash | no_root_squash | all_squash

o    root_squash. indica que un usuario identificado como root tendrá acceso al directorio compartido sólo con privilegios de usuario anónimo. De esta forma se ha degradado al root al usuario local de privilegios más bajos, protegiendo así los archivos en el servidor NFS. Esta opción se conoce también con el nombre de 'aplastamiento del root'.

Para el resto de usuarios se intenta conservar su UID y GID en el servidor.

o    no_root_squashdesactiva la opción anterior, es decir, los accesos realizados como root desde el cliente serán también de root en el servidor NFS.

o    all_squashindica que todos los clientes, incluido root, tendrán acceso al directorio con privilegios de un usuario anónimo. No se mantienen los UID y GID de ningún usuario.

NOTA: Si se utiliza alguna de las opciones squash podemos indicar cuál es el UID y GID del usuario con el que se quiere acceder, en lugar del anónimo. En este caso hemos de indicar a continuación de la opción squash lo siguiente:

(rw,all_squash,anonuid=1002,anongid=1002)

Esto significa que la conexión del cliente NFS se hará con los UID y GID 1002.
Ejemplo del contenido del archivo: /etc/exports.

4.1.3.2.- /etc/hosts.allow y /etc/hosts.deny

Como se ha comentado en el apartado 4.1.2, estos archivos permiten indicar al servicio NFS qué máquinas son aceptadas o denegadas en el uso de NFS.

Los ficheros /etc/hosts.allow y /etc/hosts.deny tienen la siguiente estructura:

servicio: host [o red/mascara_subred], host [o red/mascara_subred]

Donde:

·         servicio: servicio permitido o denegado.
·        host [o red/mascara_subred]: es la dirección IP o nombre DNS del hosts que tendrá acceso al recurso compartido

4.1.3.2.1.- Archivo /etc/hosts.deny 

En este archivo se incluyen todas las restricciones que harán más seguro nuestro sistema.

Se recomienda denegar  el acceso a portmap (TCP/UDP 111) desde cualquier IP, de esta forma sólo tendrán acceso a portmap los equipos que incluyamos en /etc/hosts.allow.

El contenido de /etc/hosts.deny será:

portmap:ALL

4.1.3.2.2.- Archivo /etc/hosts.allow 

Incluimos a qué equipos permitimos el acceso al servicio de nfs y portmap.

Podemos indicar hosts individuales o una red.

portmap:192.168.0.0/255.255.255.0
nfs:192.168.0.0/255.255.255.0

Ejemplo de contenido del archivo: /etc/host.allow

4.2.- Seguridad en NFSv4


Como ya se ha comentado, la versión 4 de NFS introduce varias mejoras encaminadas principalmente a la seguridad de NFS.

Características de NFSv4:

§         Autenticación de los usuarios y no de los equipos clientes.
§     Utilización de un único puerto TCP 2049, ya no es necesario el uso de puerto TCP/UDP 111 (portmap)
§     Respecto a seguridad se puede seguir utilizando la seguridad básica del sistema o utilizar Kerberos.
§         La compartición de directorios utiliza un sistema de archivos virtual, similar a los servidores web o servidores FTP.

4.2.1.- Demonios del servicio NFSv4

 

NFSv4 además de los demonios ya conocidos, está versión utiliza otros:

DEMONIO
USO
rpc.gssd
Permite que NFSv4 pueda realizar el proceso de autenticación en la conexión entre cliente y servidor utilizando Kerberos v5. Ejecutado en el cliente NFS.
rpc.svcgssd
Permite que NFSv4 pueda realizar el proceso de autenticación en la conexión entre cliente y servidor utilizando Kerberos v5. Ejecutado en el servidor NFS.
rpc.idmapd
Realiza el mapeo entre UIDs/GIDs locales y nombres NFSv4 de usuario (o grupos) del tipo usuario@dominio. Debe ejecutarse tanto en el cliente como en el servidor, ya que la traducción entre los nombres de usuario y los identificadores de usuario es en ambos sentidos.
 

4.2.2.- Archivos de configuración   

 

NFSv4 utiliza los mismos archivos de configuración utilizados en NFSv3.

4.2.3.- Securización


Si no tenemos o queremos utilizar NFSv4 con un sistema basado en Active Directory (Controlador de dominios), la seguridad se basa exactamente en los mismos componentes que la seguridad de NFSv3.

Si queremos ir un poco más allá y utilizar la seguridad basada en usuario/contraseña, tendremos que tener un controlador de dominio.

Más información: Cómo configurar un entorno NFS seguro con varios modos de seguridad de Kerberos:: https://docs.oracle.com/cd/E56339_01/html/E53968/ksetup-275.html

Referencias:

·         https://es.wikipedia.org/wiki/Network_File_System
·         http://recursostic.educacion.es/observatorio/web/gl/software/software-general/733-nfs-sistema-de-archivos-de-red
·         http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-nfs-security.html
·         http://recursostic.educacion.es/observatorio/web/gl/software/software-general/733-nfs-sistema-de-archivos-de-red
·         http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2-nfs.html
·         https://wiki.archlinux.org/index.php/NFS_(Espa%C3%B1ol)
·         http://penta.ufrgs.br/gereseg/node24.htm
·         https://www.tiendalinux.com/docs/manuales/redhat/rhl-rg-es-7.3/s1-nfs-security.php3
·         http://persoal.citius.usc.es/tf.pena/ASR/Tema_4html/node8.html
·         http://nfs.sourceforge.net/nfs-howto/ar01s06.html
·         http://sopa.dis.ulpgc.es/ii-aso/portal_aso/leclinux/seguridad/nfs+samba/nfs+samba.pdf
·         https://www.snia.org/sites/default/files/NFS_4.2_Final.pdf

  

Lo que hagas con la información es cosa tuya, no mía ... pero ten conciencia