Fortalecimiento de NFS y comparación con otros sistemas de archivos seguros

Texto completo

(1)INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MEXICO. FORTALECIMIENTO DE NFS Y COMPARACION CON OTROS SISTEMAS DE ARCHIVOS SEGUROS.. TESIS QUE PRESENTA. JORGE RAUL NUEVO FONSECA. MAESTRíA EN CIENCIAS COMPUTACIONALES MCC 93. DICIEMBRE, 1997.

(2) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS ESTADO DE MEXICO. FORTALECIMIENTO DE NFS Y COMPARACION CON OTROS SISTEMAS DE ARCHIVOS SEGUROS.. TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES PRESENTA. JORGE RAUL NUEVO FONSECA. Asesor: Comité de Tesis:. Jurado:. Dr. Jesús Vásquez. Dr. Luis Trejo Rodríguez Dr. Eduardo García García Dr. José de Jesús Vázquez. Presidente Secretario Vocal. Atizapán de Zaragoza, Edo. Méx., Diciembre de 1997.

(3) Fortalecimiento de NFS y Comparación con otros Sistemas de Archivos Seguros Jorge Raúl Nuevo Fonseca 5 de diciembre de 1997.

(4) ,. Indice General 1. Descripción de NFS 7 1.1 Tnstalación de NFS . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Un ejemplo práctico: Iniciación de NFS en la HP9000 . . . . . . . . . . . . . 11 1.2 El Protocolo de NFS . . . . . . . . . . 14 1.3 Descripción de la Arquitectura de NFS 18 1.4 Demonios en NFS . 19 1.5 El Automounter . . . . . . . . . . 21. 2 Debilidades de Seguridad en NFS 2 .1 Debilidades de Seguridad de NIS 2.2 Debilidades en otras versiones de NFS. 23 . . . . . . . . . . 29 32. 3 Fortalecimiento de NFS 3.1 Medidas Preventivas . 3.2 Medidas de Monitoreo. 35 35 36. 4 Otras soluciones utilizadas por NFS 4.1 Criptografía Simétrica y de Llave Pública. 4.2 El modelo de Diffie-Hellman 4.3 Secure RPC . . . . . . . 4.4 Secure NFS . . . . . . . . . 4.5 Otra solución: Kerberos .. 4.5.1 Sistema de Autentificación Kerberos 4.5.2 Proceso de Autentificación. 41 41 42 43. 1. 48 52. 52 53.

(5) Í.VDICE GENERAL. 2. 5 Comparativo 5.1 AFS (Andrew File System) . . . . . . . . . . 5.1.1 Arquitectura de AFS . . . . . . . . . 5.1.2 Características de Seguridad de AFS 5.1.3 Programa de Login en AFS 5.2 Distributed File System 5.3 Secure File System . . . . . . . . . 5.3.1 Resumen de Comandos de SFS. 61 61. 6. 87. Conclusiones. 64 67. 70 75. 80 83.

(6) ,. Indice de Figuras 1.1. Arquitectura de Software de NFS.. 18. 2.1. El Mapeador de Puertos . . . . . .. 27. 4.1 4.2 4.3 4.4. Autentificación en K erberos. . . . Primera Fase de la Autentificación en Kerberos. Segunda Fase de la Autentificación en Kerberos. Tercera Fase de la Autentificación en Kerberos.. 55 56 59 60. 5.1. Modelo de Acceso Remoto de NFS y Modelo UPLOAD DOWNLOAD de AFS. . . . . . . 62 Arquitectura de Software de AFS. . . . . . . . . . . . . . 65. 5.2. 3.

(7) 4. ÍNDICE DE FIGURAS.

(8) Resumen NFS es un sistema de archivos distribuido (Network File System) diseñado e implementado por Sun Microsystems en 1985 y es de hecho el estándar de facto en los sistemas UNIX. Fue el primer sistema de archi,·os distribuido comercialmente exitoso debido en parte a su capacidad para soportar una gran variedad de arquitecturas y es ampliamente aceptado actualmente; sin embargo cuando se diseñó no se tenía como factor importante la seguridad en este sistema. Hoy en día se hace evidente la necesidad de proteger la información en contra de ataqurs que puedan modificarla o destruirla, por lo que se analizan las principales debilidades de este sistema de archivos y sus posibles soluciones. Se hace un análisis comparativo con otros sistemas de archivos que han surgido recientemente y que cuentan en su diseño con mecanismos de seguridad tales como AFS (Andrew File System) creado por la universidad del Carnegie Mellan, SFS (Secure File System) que es un sistema de archivos para DOS/Windows y, aunque no es para sistemas distribuidos, ya cuenta con características de seguridad, DFS (Distributed File System) que es un sistema de archivos sucesor de AFS y que se encuentra incorporado en los ambientes DCE (Distributed Computer Environment). Aunque estos sistemas de archivos ya cuentan con fuertes mecanismos de seguridad, su precio en el mercado es elevado, por lo que la opción más viable a la gran base instalada de NFS es el fortalecimiento de este sistema de archivos.. 5.

(9) Capítulo 1 Descripción de NFS Un sistema de archivos es el responsable de la organización, almacenamiento, recuperación, nombrado, compartición y protección de los archivos, los cuales son a su vez abstracciones de datos guardados en almacenamiento secundario [3, 4, 1, 2]. Un sistema de archivos distribuido es parte esencial en los sistemas distribuidos que se encarga de brindar la compartición de la información, habilita a programas de usuarios accesar archivos remotos sin que los tengan que copiar a sus discos locales y provee el acceso a archivos desde nodos sin disco duro. El sistema de archivos de red de Sun Microsystem (NFS) ha sido ampliamente adoptado en la industria y en los ambientes académicos desde su introducción en 1985. Aunque varios sistemas de archivos distribuidos ya habían sido desarrollados con éxito en universidades y laboratorios de investigación, NFS (Network File System) fue el primero que se diseñó como un producto comercial. Para alentar su adopción como un estándar, las definiciones de sus interfases clave fueron puestas en dominio público en 1989 permitiendo así que otros vendedores produjeran aplicaciones sobre NFS. NFS es un sistema de archivos distribuido que se basa en el modelo cliente-servidor y que provee acceso transparente a archivos remotos para programas clientes corriendo sobre UNIX y otros sistemas. La. 7.

(10) 8. CAPÍTULO 1. DESCRIPCIÓN DE NFS. relación cliente-servidor en NFS es simétrica ya que cada computadora puede actuar como cliente y como servidor y los archivos en cada máquina están disponibles para el acceso remoto por otras máquinas; aunque es una práctica común dejar máquinas como servidores dedicados. NFS da una transparencia de acceso ya que el cliente NFS provee una interfase de programación de aplicaciones a procesos locales que es idéntica a la interfase del sistema operativo local. De esta manera en un cliente UNIX el acceso a los archivos remotos se realiza utilizando las llamadas a sistema que son usuales en UNIX. Los sistemas de archivos tienen que ser exportados por el nodo que los contiene y montados remotamente por el cliente antes de que puedan ser accesados por procesos corriendo en el cliente. De esta manera la transparencia de localización es hecha por medio de las instrucciones export y mount. NFS es utilizado junto con otro servicio creado también por Sun Microsystems: NIS (Network Information Service). Este servicio se dedica a resolver uno de los mayores problemas en un sistema distribuido en donde se mantienen copias separadas de archivos de configuración de uso común, tales como passwords, archivos de grupo y hosts. Esta duplicidad de archivos de configuración impide muchas veces conservar la consistencia ya que al realizar una modificación en la configuración, se debe modificar cada uno de los archivos disgregados. NIS es una base de datos distribuida que reemplaza las copias replicadas por archivos de configuración de uso común a todos los hosts facilitando de esta manera una administración centralizada, en lugar de tener que administrar los archivos de configuración de cada host como:.

(11) 9. / etc/bootparams /etc/ethers /etc/group /etc/hosts /etc/aliases /etc/masks /etc/ networks /etc/passwd. Información sobre nodos diskless Direcciones MAC Grupos de Usuarios Direcciones IP y de hosts Alias y listas de correo Máscaras de la red Direcciones de redes Usuarios y sus passwords. Esta información es almacenada en archivos especiales llamados maps o mapas y en donde un dominio NIS comparte un conjunto de mapas. En una red que ejecuta NIS, existe al menos un servidor por dominio que guarda un conjunto de mapas de NIS para que otros hosts tengan acceso. Existen dos tipos de servidores NIS: Un servidor maestro mantiene las copias maestras de los mapas y las reconstruye cuando la información cambia. Sólo puede existir un servidor maestro en un dominio NIS, aunque un solo host puede ser el maestro para más de un dominio. Un servidor esclavo obtiene copias de los mapas de un servidor maestro; típicamente hay dos o tres servidores esclavos para cada dominio de manera que no se interrumpa el servicio cuando el servidor maestro se encuentre caído. NFS y NIS son servicios que trabajan juntos: NIS se asegura que la información de configuración se propague a todos los hosts y NFS se asegura que los archivos que un usuario necesita se encuentren disponibles desde estos hosts..

(12) CAPÍTULO l. DESCRIPCIÓN DE NFS. 10. 1.1. Instalación de NFS. El iniciar NFS en clientes y servidores, implica iniciar los demonios que manejan el protocolo NFS, y simplemente exportar los sistemas de archivos de los servidores NFS y montarlos en los clientes. En el lado del cliente, los procesos demonios que se inician son los siguientes:. biod rpc.lockd rpc. statd. Realizan funciones de bloque de entrada/salida. Maneja el file locking o acceso exclusivo a archivos. Maneja el lock recovery en el cliente.. En el lado del servidor, los servicios de NFS son inicializados con los siguientes procesos demonios:. nfsd. Acepta peticiones RPC de operaciones NFS por parte de los clientes y las ejecuta en el servidor. Un servidor corre varios demonios nfsd, de manera que pueda aceptar varias peticiones RPC de clientes a la vez.. rpc.mountd. Maneja las peticiones de los clientes para montar sistemas de archivos remotos.. En el servidor, el archivo /etc/exports determina qué sistemas de archivos pueden ser montados vía NFS a los clientes. Cuando un servidor de archivos se inicializa, revisa la existencia de / etc/ exports y corre el comando exportfs para permitir que los sistemas de archivos se encuentren disponibles para los usuarios. En algunos sistemas la presencia del archivo /etc/exports es una condición necesaria para que puedan correr los demonios nfsd y rpc.mountd. Un ejemplo de archivo /etc/exports puede ser el siguiente:.

(13) 1.1. INSTALACIÓN DE NFS. /home/usuarios /usr/estadisticas /usr/tools. 11. -rw=research -ro, access=sunl.ab, biblio. Aquí se especifica que estos directorios son exportables, y que en el caso del directorio estadisticas sólo lo puede accesar para lectura/escritura el host research, mientras que el directorio tools lo pueden accesar en modo sólo lectura los hosts sunlab y biblia. En el caso de los clientes, éstos pueden montar un sistema de archivos o parte de éste al especificarlo en el archivo /etc/fstab o lo pueden montar explícitamente utilizando el comando mount. De esta manera los archivos remotos montados en el cliente aparecen como locales a éste.. 1.1.1. Un ejemplo práctico: Iniciación de NFS en la HP9000. Para habilitar las capacidades de NFS en un servidor HP9000, se debe revisar que las variables NFS_SERVER y START _MOUNTD se encuentren igualadas a 1 en el archivo / etc/re. config. d/nfsconf, tal y como sigue:. NFS_SERVER = 1 START_MOUNTD = 1. Se debe correr además el siguiente comando para iniciar el script de NFS:. /sbin/init.d/nfs.server. start.

(14) 12. CAPÍTULO 1. DESCRIPCIÓN DE NFS. Este script utiliza las variables en el archivo /etc/re. config. d/nfsconf para determinar los procesos que debe comenzar. La variable START_MOUNTD inicia el demonio rpc.mountd. Para fortalecer la seguridad, la variable START _MOUNTD se iguala a O, y se configura el demonio rpc. mountd con la opción -e en el archivo / etc/inetd. conf. Esto provoca que el demonio ínetd inicie el demonio rpc. mountd en cada petición para montar un sistema de archivos y que revise las credenciales y permisos de acceso para cada petición.. Para hacer los directorios disponibles a Clientes NFS se debe seguir lo siguiente: l. Se debe añadir una línea en el archivo /etc/exports para cada directorio que se quiere hacer disponible a los clientes NFS. El formato que debe seguir cada línea en dicho archivo es el siguiente:. directory [ - option [ , option ]]. 2. Si el sistema se encuentra ya corriendo un servidor NFS , se debe ejecutar el siguiente comando:. /usr/sbin/exportfs. directorio. Para remover un directorio exportado en un servidor NFS se deben seguir los siguientes pasos: l. En el servidor NFS se debe ejecutar el siguiente comando para listar a todos los clientes NFS que han montado el directorio que se quiere remover:. /usr/sbin/showmount -a.

(15) 1.1. INSTALACIÓN DE NFS. 13. 2. En cada cliente NFS que haya montado el directorio, ejecute el siguiente comando para listar los identificadores de procesos y usuarios que se encuentren montando estos directorios.. /usr/sbin/fuser. -u. nombre-servidor:/directorio. 3. Se debe prevenir a los usuarios que salgan de dicho directorio y eliminar los procesos que se encuentren utilizándolo o esperar a que estos procesos terminen. 4. En cada cliente NFS que tenga montado el directorio deseado, se debe ejecutar el siguiente comando:. /usr/sbin/umount. nombre-servidor:/directorio.

(16) 14. 1.2. CAPÍTULO 1. DESCRIPCIÓN DE NFS. El Protocolo de NFS. Tanto NFS como NIS son protocolos de red construidos sobre otros protocolos de menor nivel. De hecho son protocolos pertenecientes a la capa de aplicaciones o capa 7 del modelo de OSI. Los protocolos NFS y NIS se construyen sobre los protocolos XDR en la capa de presentación o capa 6, sobre los RPC (Remote Procedure Call) en la capa de sesión o capa 5 y sobre el protocolo UDP en la capa de transporte o capa 4. En la capa de presentación, el protocolo XDR(External Data Representation) se encarga de dar formato a los datos para su presentación a los protocolos de la capa de aplicación, en este caso los protocolos NFS y NIS. Los RPC proveen mecanismos para hacer que un host haga una llamada a procedimiento y que parezca ser parte de un proceso local cuando en realidad es la ejecución en otra máquina de la red. En la capa de transporte pueden existir 2 protocolos: TCP o UDP. TCP provee una entrega de paquetes en forma confiable y en secuencia y la comunicación es orientada a conexión tal como el login remoto o la transferencia de archivos (file transfer). Sin embargo existe un overhead en este protocolo debido a que se debe mantener un control sobre la entrega en orden de los paquetes. Esta información extra es una información de estado ya que no forma parte de los datos pero si describe el estado de la conexión y de la transferencia de datos. En cambio UDP manda largos datagramas a un host remoto pero no asegura que éstos lleguen o lleguen en orden. UDP es mejor para la comunicación no orientada a conexión. Con UDP, corresponde a la aplicación determinar cuando se ha perdido un paquete y cuando es necesario reenviarlo. El hecho de que NFS y NIS se encuentren sobre el protocolo UDP tiene consecuencias muy importantes:.

(17) 1.2. EL PROTOCOLO DE NFS. 15. • Se eficientiza la recuperación de fallas en NFS ya que como ningún estado se mantiene, el servidor puede reinicializar y empezar a aceptar peticiones NFS de los clientes como si nada hubiera pasado. Similarmente cuando los clientes reinicializan debido a que fallaron, el servidor no necesita saber nada de ellos. • Implica que las peticiones RPC de NFS deben describir completamente la operación a realizar. Por ejemplo, al escribir a un archivo, la operación debe contener : (un manejador de archivo, un offset en el archivo y la longitud de la operación de escritura a realizar). Esto contrasta con la misma operación en UNIX en donde la llamada a sistema write() escribe al buffer a donde señala el apuntador del file descriptor. • La mayoría de las peticiones en NFS son idempotentes, lo que significa que un cliente puede enviar la misma petición varias veces al servidor sin que se produzcan efectos secundarios. Por ejempl0 la operación de lectura, en donde se devuelven los mismos datos al cliente, independientemente de cuántas veces se realice la operación. Las peticiones de retransmisión por parte de un cliente a un servidor NFS se realizan una a la vez y el cliente no hará otra llamada RPC hasta que la actual llamada en curso sea completada y reconocida por el servidor NFS (al igual que las llamadas a sistema en UNIX). Cuando un cliente hace una petición RPC pone un temporizador durante el cual el servidor NFS debe darle servicio y reconocer su petición. Si el servidor no lo hace ya sea porque está sobrecargado o porque sufrió una falla, entonces el cliente retransmite la petición. (De esta manera el cliente no nota ninguna diferencia entre un servidor caído y uno muy lento). El protocolo NFS contiene 16 procedimientos, cada uno de los cuales opera ya sea sobre un archivo o un objeto del sistema de archivos y se agrupan en categorías: l. Operaciones de Directorio.

(18) CAPÍTULO 1. DESCRIPCIÓN DE NFS. 16. 2. Operaciones de Archivo 3. Operaciones de Liga 4. Operaciones del Sistema de Archivos Estos procedimientos se presentan en forma general a continuación:. • lookup ( dirfh, name) = filehandler, attr Regresa el identificador de archivo filehandler para el archivo name en el directorio dirfh. • create ( dirfh, name, attr) = newfh, attr Crea un nuevo archivo name en el directorio dirfh con atributos attr y regresa el nuevo manejador de archivo newfh y sus atributos.. • remove{dirfh,name) = status Quita el archivo name del directorio dirfh • getattr{filehandler) = attr Regresa los atributos del archivo filehandler. llamada de sistema stat de UNIX).. (Es similar a la. • setattr(filehandler, attr) = attr Inicializa los atributos de un archivo (modo, identificador de usuario, identificador de grupo, tamaño y tiempo de acceso).. • read(filehandler, offset, count) = attr, data Regresa count bytes de datos de una archivo desde un offset, así como los atributos del archivo.. • write(filehandler,offset,count,data) = attr Escribe count bytes de datos a un archivo a partir de un offset y regresa los atributos del archivo después de que la escritura se ha llevado a cabo.. • rename(dirfh, name, todirfh, toname} = status Cambia el nombre del archivo name en el directorio dirfh al archivo toname en el directorio todirfh..

(19) 1.2. EL PROTOCOLO DE NFS. 17. • link{newdirfh,newname,dirfh,name) = status Crea una entrada newname en el directorio newdirfh que se refiere al archivo name en el directorio dirfh. • symlink(newdirfh,newname,string) = status Crea una entrada newname en el directorio newdirfh de tipo de liga simbólica con el valor string. El servidor no interpreta el string, pero hace una liga simbólica a éste. • readlink{filehandler) = string Regresa el string asociado con la liga simbólica del archivo identificado por el filehandler. • mkdir{dirfh, name, attr) = newfh, attr Crea un nuevo directorio name con atributos attr y regresa el nuevo identificador de archivo (file handler) y atributos. • rmdir{dirfh, name) = status Remueve el directorio vacío name del directorio padre dirfh. Falla si el directorio no se encuentra vacío. • readdir{dirfh, cookie, count) = en tries Regresa count bytes de entradas de directorios del directorio dirfh. Cada entrada contiene un nombre de archivo, identificador de archivo, y un apuntador a la siguiente entrada de directorio llamada un cookie. La cookie es utilizada en subsecuentes llamadas readdir para empezar a leer desde la siguiente entrada. Una llamada readdir con un valor cookie igual a O empieza a leer desde la primera entrada en el directorio. • statfs {filehandler) = Jstats Regresa información del sistema de archivos tal como tamaño de bloque, número de bloques libres, etc. para el sistema de archivos conteniendo el archivo filehandler..

(20) CAPÍTULO 1. DESCRIPCIÓN DE SFS. 18. 1.3. Descripción de la Arquitectura de NFS. La arquitectura de software de los clientes y servidores de NFS se muestran en la figura 1.1.. compu Udon. ch.?nle. proce.ao. servidor. 1y11iem calla. clienlt: a nivel de. KERNEL DE UNIX. KERNEL DE UNIX. RED. Servidor. UNIX. NFS. fil< 1)'1"111. Figura 1.1: Arquitectura de Software de NFS. El módulo del servidor de ?\FS reside en el kernel de UNIX de cada computadora que actúa como servidor NFS. Las peticiones a archivos en sistemas de archivos remotos son traducidas por el módulo de cliente en operaciones de protocolo NFS y entonces pasadas al módulo I\FS en la computadora que contiene al sistema de archivos en cuestión. Los módulos de cliente y del servidor NFS se comunican usando los RPC's de Sun 11icrosystem desarrollado para el NFS. Un servicio de mapeo de puertos (port mapper service) se incluye para habilitar a los clientes el ligarse a servicios en un host dado. En NFS, un sistema de archivos virtual (virtual file system o VFS) ha sido añadido al kernel de UNIX para distinguir entre archivos locales y archivos remotos y para traducir entre identificadores de archivos •.

(21) 1.4. DEMONIOS EN NFS. 19. independientes de UNIX (file handles) utilizados por l'\FS y los identificadores de archivos internos normalmente usados en C\'IX y otros sistemas de archivos. Los identificadores de archivos utilizados en \'FS se denominan manejadores de archivos (file handles) y, así como los identificadores de archivos de UNIX, identifican de manera única un archivo en el contexto de un proceso. Los manejadores de archivos en NFS son opacos al cliente, es decir que no son de valor para el cliente pues sólo pueden ser interpretados en el contexto del sistema de archivos remoto. Un sistema de archivos utilizando NFS provee dos niveles de transparencia:. l. Los sistemas de archivos parecen ser residentes en el disco local y todas las entradas del sistema de archivos (archivos y directorios) son vistos de la misma manera, ya sean locales o remotos.. 2. Los sistemas pe archivos montados con \'FS no contienen información acerca del servidor de archivos desde el cual son montados. De esta manera el servidor NFS puede ser de diferente arquitectura. NFS logra el primer nivel de transparencia al definir un conjunto genérico de operaciones del sistema de archivos que se realizan en el VFS. El segundo nivel de transparencia viene con la definición de los nodos virtuales (virtual nades) los cuales se relacionan con las estructuras inodes del sistema de archivos UNIX, pero que esconden de hecho la estructura física del sistema de archivos.. 1.4. Demonios en NFS. NFS es similar a otros servicios basados en RPC en el hecho de que el demonio del servidor ( en este caso nfsd) recibe las peticiones de los procesos·de entrada. NFS utiliza múltiples copias de cada demonio para mejorar la eficiencia. Tanto el código cliente como servidor de NFS.

(22) 20. CAPÍTULO 1. DESCRIPCIÓN DE ./\..-FS. está contenido en el kernel en lugar del demonio del servidor. La razón por la que NFS no es un servicio kernel-a-kernel sin procesos (ya que los códigos se encuentran en el kernel), es por la necesidad de contar con peticiones RPC para NFS multihilos entendiendo como multihilos que varias copias de un demonio corran al mismo tiempo para aceptar peticiones NFS de clientes en el servidor. En el lado del cliente, cada proceso que accesa un sistema de archivos NFS hace sus propias llamadas RPC a los servidores de NFS. Cuando bloques de archivos son transferidos entre cliente y servidor, NFS necesita hacer uso del mecanismo de caché-buffer para archivos de UNIX para mantener una eficiencia similar a la lograda en acceso a archivos locales. El buffer-caché tradicional de UNIX es una porción de memoria del sistema que es reservado para bloques de archivo que han sido recientemente referenciados. El resultado de esta actividad de pre-búsqueda es que no todas las llamadas de lectura read(} requieren una operación de disco ya que pueden ser satisfechas con los datos del buffer. Los sistemas SunOS 4.x V de UNIX reemplazan el buffer de caché con un sistema de mapeo de páginas. En lugar de transferir archivos dentro y fuera de buffers de caché, el sistema de manejo de memoria virtual mapea directamente archivos en un espacio de direcciones de procesos y trata el acceso a archivos como acceso a páginas. El efecto en red es el mismo que el de buffer de caché pero el tamaño del caché no es fijo. Los demonios biod en el lado del cliente mejoran la eficiencia de NFS al llenar y vaciar el buffer de caché en los clientes permitiendo que éstos realicen varias llamadas RPC al mismo tiempo. NFS funciona correctamente sin los demonios biod pero su eficiencia puede verse afectada en forma seria. Otro demonio importante es el rpc.lockd el cual corre tanto en el servidor como en el cliente y controla el acceso exclusivo a archivos o parte de ellos, ya sean éstos remotos o locales. Cuando una petición de ac-. BIBLIOTECA ... '(. (~. \.;. ,.

(23) 1.5. EL AUTOMOUNTER. 21. ceso exclusivo es realizada para un archivo montado en NFS, rpc.lockd maneja esa petición y la envía al servidor. Este proceso notifica al demonio monitor rpc.statd que un cliente ha hecho una petición de acceso exclusivo para que lo empieze a monitorear. Estos demonios mantienen dos directorios: /etc/sm y /etc/sm. bak. El primer directorio es utilizado por el monitor de estado en un servidor NFS para seguir el nombre de los hosts que han dado acceso exclusivo a uno o más de sus archivos. Cuando se pide a rpc.statd que siga el monitoreo de un sistema, crea un archivo con el nombre del sistema en /etc/sm. Si el sistema que hace la petición de acceso exclusivo es notificado que el servidor se va a reinicializar, entonces una entrada es hecha en /etc/sm.bak. Cuando el demonio monitor se inicia, hace una llamada a los demonios de estado en todos los sistemas cuyos nombres aparecen en /etc/sm. bak para notificarles que el servidor se ha reinicializado. Estos directorios se utilizan como apuntadores para la regeneración de acceso exclusivo a archivos en el caso de una falla en el cliente o en el servidor.. 1.5. El Automounter. El automounter es una herramienta que monta automáticamente los sistemas de archivos NFS cuando son referenciados y los desmonta cuando ya no son necesitados. Usando el automounter ya no se necesita la actualización manual de cada uno de los archivos /etc/Jstab. El uso de esta herramienta facilita la administración de un ambiente NFS grande y dinámico puesto que es difícil mantener al día cada uno de los archivos /etc/fstab. El automounter monta los sistemas de archivos conforme estos son referenciados. Algunos usuarios requieren que sus máquinas sólo monten aquellos sistemas de archivos que les son de interés para eliminar laposibilidad de que sus máquinas se "culguen" si un servidor conteniendo información no interesante lo hace. El automounter elimina las dependencias de estos servidores NFS no relacionados mediante la imposición.

(24) 22. CAPÍTULO 1. DESCRIPCIÓN DE NFS. de la noción de grupo-de-trabajo en el conjunto de sistemas de archivos montados. Después de varios minutos (cinco por default), el automounter intenta desmontar todos los sistemas de archivos que anteriormente montó. Si el sistema de archivos se encuentra inactivo, la llamada a sistema umount() ejecutada por el automounter tiene éxito. Si el sistema de archivos se encuentra activo, entonces el automounter ignora el error devuelto por la llamada al sistema umount..

(25) Capítulo 2 Debilidades de Seguridad en NFS De acuerdo al CERT (Computer Emergency Response Team) y basados en los 2,241 incidentes de seguridad a sistemas computacionales que le fueron reportados durante 1994, los 4 tipos de ataques a sistemas de cómputo más comunes durante ese año fueron los siguientes: • Ataques de Sniffers: re-uso de passwords, Caballos de Troya, etc. • Ataques a correo electrónico. • Ataques a Network File System (NFS) • Ataques a Network Information Services (NIS) La falta de seguridad en NFS y NIS han hecho que sean servicios muy susceptibles de ser atacados. De hecho NFS sufre de un pobre algoritmo de autentificación y requiere de complementos de seguridad por parte de los programas de usuario, esto no es un problema fácil de resolver. Existen en el WEB varias notas sobre cómo explotar el algoritmo de autentificación de NFS, éstas pueden ser puestas en práctica por cualquier persona. He aquí algunas: • El Servidor NFS puede atender peticiones hechas desde programas de usuario no privilegiados.. 23.

(26) 24. CAPÍTULO 2. DEBILIDADES DE SEGURIDAD EN SFS. Cuando un cliente NFS quiere accesar a un archirn remoto o un directorio, su sistema operativo manda una petición al servidor NFS. Como se vió anteriormente, debido a que NFS es un protocolo sin estado necesita describir completamente la operación a realizar pasando al servidor, entre otros parámetros, un manejador de archivos (file handle), la operación (lectura, escritura, etc.) y la identidad del usuario que hará la operación. NFS cuenta con un pobre algoritmo de autentificación ya que, en forma predeterminada, la indentidad del usuario es especificada con los identificadores de usuario y de grupo de UNIX. Con este esquema llamado AUTH_UNIX, se utiliza t'.n identificador de usuario (UID) y un identificador de grupo (GID) para comprobar que la petición NFS es legítima. Ahora bien, una petición NFS no es más que un mensaje de red. Cualquier usuario puede correr un programa que genere peticiones NFS arbitrarias con el propósito de engañar al sistema para que le otorgue acceso a usuarios arbitrarios. Aún cuando se realiza una autentificación especial para obtener privilegios de root sobre un sistema de archivos, siempre es posible obtener estos privilegios. Por ejemplo, un usuario que corre Linux sobre una PC, es root de su sistema o puede hacerse pasar por el root de otro sistema que tiene acceso al servicio de :\'FS. Este no es un problema fácil de resolver :i,· la mejor solución es encontrar una implementación de NFS que soporte encriptación DES (utilice una autentificación AUTH_DES) como Secure :\'FS con DES o credenciales KERBEROS. Desafortunadamente muchas de las implementaciones NFS sólo soportan AUTH_UNIX. La solución parcial más común consiste en configurar NFS de tal manera que las peticiones que reciba el servidor sólo sean aceptadas cuando son realizadas por programas de sistema privilegiados, lo cual hace que un ataque a la seguridad sea más difícil ya que un usuario debe ser al menos root en un sistema remoto para mandar.

(27) 25. peticiones NFS. Para realizar esto, los administradores de SunOS 4 deben modificar el archivo /etc/re.local:. rpc.mountd (no -n option) echo "nfs_portmon/W1 11 1 adb -w /vmunix /dev/kmem. Los administradores de SunOS 5 deben modificar el archivo /etc/system:. set nfs:nfs_portmon=1. En otros sistemas, las. opciones de la línea del comando mountd difieren y la variable del kernel puede llamarse nfsportmon o algo similar. • Los manejadores de Archivos de NFS son fáciles de duplicar. Cuando un cliente NFS desea accesar un directorio o archivo remoto, manda una petición al demonio NFS (nfsd) del servidor de archivos. Esta petición incluye un manejador de archivos NFS file handle que identifica el objeto accesado. ¿Cómo obtiene un cliente NFS el manejador de archivos?. Un cliente honesto se comunica primero con el demonio que monta los sistemas de archivos (rpc. mountd) el cual verifica los permisos con que cuenta el cliente para accesar dicho sistema de archivos. Cuando este demonio le otorga el derecho de acceso, le manda al cliente el manejador de archivos NFS. Una vez que el cliente éuenta con este manejador de archivos, puede mandar peticiones de acceso de archivos directamente al demonio NFS. De hecho cualquier cliente que esté en posesión de.

(28) 26. CAPÍTULO 2. DEBILIDADES DE SEGURIDAD EN NFS un manejador de archivos válido de NFS puede accesar la información. ¡,Cómo se puede entonces proteger al servidor NFS contra usuarios maliciosos?. La solución de Sun Microsystems es utilizar manejadores de archivos que sean difíciles de adivinar.. Por otra parte Existen riesgos en el servidor de NFS debido a que el servicio generalmente se encuentra en el puerto 2049 y por lo tanto se encuentra en un rango no privilegiado que puede ser asignado a procesos de usuarios. Por lo que filtros de paquetes, que permiten la comunicación UDP, deben ser configurados para bloquear este puerto. • Inseguridad con el mapeador de puertos. \"FS exporta archivos a través del mapeador de puertos y puede ser que las restricciones de exportación puedan ser sobrepasadas.. En los sistemas UNIX BSD, el mapeador de puertos o Portmapper es utilizado para convertir números de protocolo TCP /IP en números de programa RPC [3]. Como se vió anteriormente, NFS y NIS son aplicaciones que se encuentran basadas sobre RPC. Un servidor RPC provee un grupo de procedimientos que un cliente puede llamar al enviar una petición al servidor. El servidor invoca el procedimiento deseado y regresa el resultado al cliente. La colección de procedimientos que un servidor RPC provee se conoce como programa y es identificada por un número de programa. Un problema se introduce con este mecanismo ya que los servidores RPC no reservan puertos (al contrario de aquellos servicios listados en el archivo /etc/services ); por lo que cuando inician toman cualquier puerto disponible en ese momento. Cuando un programa cliente requiere un servicio RPC en particular, no tiene manera de conocer en qué puerto el número de programa que desea se encuentra. El mapeador de puertos resuelve este problema ya que mapea los números de programa RPC a los puertos TPC, UDP, en los cuales los servidores se encuentran escuchando..

(29) 27. La forma en que funciona el mapeador de puertos se muestra en la figura 2.1.. 2. SERVIDOR. Figura 2.1: El Mapeador de Puertos. Como se puede apreciar en esta figura, un programa cliente difunde (broadcast) una petición para un programa particular, la versión y el procedimiento a un puerto bien conocido donde se encuentra el mapeador de puertos (Puerto 111). Si el procedimiento especificado se encuentra registrado con el mapeador de puertos, éste pasa la petición al procedimiento solicitado. Cuando el procedimiento ha finalizado, éste regresa su respuesta al mapeador de puertos quien a su vez lo envía al cliente..

(30) 28. CAPÍTULO 2. DEBILIDADES DE SEGURIDAD EN NFS Esta respuesta contiene el número de puerto del procedimiento invocado, de manera que las peticiones posteriores del cliente puedan ser realizadas directamente al programa remoto [4]. Cuando el cliente NFS quiere accesar un sistema de archivos remoto por primera vez, necesita obtener un manejador de archivos NFS (NFS file handle). Para este propósito el cliente manda una petición para montar el sistema de archivos al demonio que maneja las peticiones para montar sistemas de archivos por parte de los clientes ( rpc. mountd). Este demonio verifica que el cliente tenga los permisos para accesar el sistema de archivos solicitado. Cuando este demonio ( rpc. mountd) otorga el acceso, envía un manejador de archivos de regreso al cliente NFS. El problema aquí es que, por razones de eficiencia, la mayoría de las restricciones de exportación de NFS son forzadas por rpc. mountd. Las operaciones de acceso a archivos individuales son manejadas por el demonio NFS ( nfsd), y el origen de dichas peticiones es solamente examinado en casos especiales tales como el acceso de un superusuario remoto. En lugar de comunicarse directamente con el demonio rpc.mountd, un cliente NFS malicioso puede pedir al demonio Portmapper del servidor que redirija la petición al demonio rpc. mountd. Cuando el demonio mount recibe la petición del mapeador de puertos (Portmapper), el demonio mount creerá que la petición proviene del servidor de archivos y no del usuario malicioso. De este punto en adelante, el cliente malicioso se comunicará directamente con el demonio NFS para accesar el directorio y todos los archivos que se encuentren debajo de él. Para evitar esta vulnerabilidad se pueden tomar varios pasos. Primero, si se trata de un sistema· UNIX BSD se debe utilizar un mapeador de puertos que no siga adelante con las peticiones para montar sistemas de archivos NFS tal como el mapeador de puertos de Wietse Venema. Para los sistemas UNIX V, una herra-.

(31) 2.1. DEBILIDADES DE SEGURIDAD DE NIS. 29. mienta similar ha sido escrita por Venema la cual es un reemplazo para el rpcbind. Estas herramientas son analizadas más a fondo en la tesis Proposición de Mecanismos de Seguridad para el For-. talecimiento de NFS, Julio A. Díaz.. 2.1. Debilidades de Seguridad de NIS. Como se vió anteriormente, NIS se encarga de concentrar toda la información de configuración en un sistema, pero muchas de sus implementaciones no proporcionan un control de accesso adecuado.. Ejemplos de la información que maneja NIS son los archivos de passwords de usuarios en el sistema, tablas con nombres y direcciones de hosts en la red y alias de correo electrónico la cual es información muy delicada. Desafortunadamente no se realiza una autentificación adecuada y es muy fácil para hosts externos obtener esta información. La mejor solución es actualizar NIS con versiones que provean un mayor control de acceso aunque, por desgracia, no todos los fabricantes proveen este servicio aún. También se recomienda fuertemente una buena política de selección de passwords así como alternativa.~ del comando passwd que requieren que el usuario proporcione passwords más complejos tales como npasswd. Se puede empezar por definir passwords más complejos, como por ejemplo que estos tengan una longitud de ocho letras una de las cuales sea mayúscula y otra sea una letra no alfabética. Se debe a.sí mismo recordar a los usuarios que casi cualquier palabra de diccionario puede ser encontrada por un cracker de passwords. Otra falla de seguridad existe con el comando ypset en el uso del servicio de NIS. Como se vió en la descripción de NFS y NIS, cada dominio en una red tiene servidores NIS maestro y esclavos, los cuales deben correr un proceso llamado ypserv que busca información en los mapas ( maps) de.

(32) 30. CAPÍTULO 2. DEBILIDADES DE SEGCJRIDAD EN NFS. estos servidores en respuesta a peticiones de red y devuelve los datos solicitados. Los clientes de NIS corren procesos que solicitan datos de los mapas de los servidores NIS. Un cliente no repara de donde obtiene los datos ya sea de un servidor maestro o de un servidor esclavo, ya que ambos contienen la misma información. Un programa cliente obtiene información de un servidor a través de un proceso de liga binding process que realiza lo siguiente: 1. El cliente pide a un proceso local denominado ypbind el nombre de un servidor NIS. 2. La función de ypbind es recordar las direcciones de red de los procesos ypserv que corren en los servidores, y rastrear su disponibilidad. Busca un servidor que pueda responder y regresa la información al programa cliente. 3. El cliente manda una petición directamente al servidor NIS. 4. El proceso ypserv en el servidor toma la petición, busca los datos . en los mapas y regresa la información al cliente. El comando ypset puede ser utilizado para indicar al proceso ypbind cual host debe utilizar como servidor para un dominio NIS dado. El comando. $ ypset -d <nombre_de_dominio> <nombre_del_host>. indica al proceso ypbind que cualquier petición de información en el dominio NIS nombre_de_dominio debe ser enviada al host nombre_deLhost. El propósito principal de ypset es permitir a hosts que no se encuentran en una red con NIS, utilizar NIS. Sin embargo esto puede representar un problema de seguridad pues un atacante puede indicar a un proceso ypbind de obtener información de un servidor al que después podrá modificar sus mapas..

(33) 2.1. DEBILIDADES DE SEGURIDAD DE NIS. 31. Otros problemas de seguridad relativos a NIS son los siguientes: Cuando se encuentra configurado para correr bajo NIS, el archivo de passwords de un cliente /etc/passwd contiene una línea especial que indica a los programas contactar un servidor NIS para la información. Esta línea se ve más o menos así:. o. +. o. +. Cuando un programa lee el archivo de password en busca de una cuenta, empieza con la primera línea en dicho archivo y sigue secuencialmente hasta que se encuentra con la línea mostrada arriba. Si un programa encuentra la información que está buscando antes de encontrar la línea de password NIS, entonces usará la información que encontró primero. Esto permite a un administrador otorgar cuentas válidas en toda la red (con NIS) así como cuentas locales. Para otorgar una cuenta en un solo host se debe colocar la línea de password de esta cuenta antes de la línea de password NIS. Sin embargo el mayor problema en esta forma de control de passwords NIS radica en el formato en que se redacta pues si se borra el símbolo + la línea queda:. o. o. que es de hecho una línea de password válida para una cuenta con nombre nulo, sin password e identificador de usuario cero que corresponde a root. Un atacante puede simplemente entrar al sistema con un nombre nulo y con derechos de super-usuario..

(34) 32. CAPÍTULO 2. DEBILIDADES DE SEGURIDAD EN NFS. En caso de que la línea sea+: si se borra accidentalmente el símbolo+, no se convierte en una línea válida de password. Desafortunadamente en una gran cantidad de equipos con NIS, la utilería vipw para la edición del archivo de passwords puede re-escribir esta línea a su forma insegura.. 2.2. Debilidades en otras versiones de NFS. Existen además otras debilidades de seguridad inherentes a determinadas versiones de NFS, por ejemplo: El centro de coordinación del CERT ha recibido información acerca de la vulnerabilidad de:. /usr/etc/rpc. mountd en los sistema<; SunOS 4.1.1., 4.1.2, 4.1.3 y 4.1.3c. Si una lista de acceso de host en el archivo /etc/exports es un string de más de 256 caracteres, entonces el filesystem puede ser montado por cualquiera. El impacto que tiene esto es que hosts remotos no autorizados pueden montar el filesystem permitiendo que usuarios no autorizados lean y escriban a archivos de estos filesystems que han sido montados. Para solucionar este error se debe obtener e instalar el parche apropiado:. Patch-Id ·. 100296-04. Filen ame. 100296-04.tar.Z. E-mail. cert©cert.org. El CERT en su boletín CA-96.08 reporta vulnerabilidades en pcnfsd. El programa pcnfsd y también llamado rpc.pcnfsd es un programa de autentificación e impresión que corre en un servidor UNIX y que no proporciona propiamente los servicios NFS. En impresión, pcnfsd utiliza NFS para transferir archivos de un cliente a un servidor pcnfsd. Cuando un cliente quiere imprimir un archivo, requiere la localización de un directorio de spool del servidor. El cliente entonces transfiere.

(35) 2.2. DEBILIDADES EN OTRAS VERSIONES DE NFS. 33. los archivos a imprimir mediante NFS e informa al servidor pcnfsd que los archivos se encuentran listos a imprimir. pcnfsd crea un subdirectorio para cada uno de sus clientes y regresa la localización de estos directorios a sus clientes. La primera vulnerabilidad en pcnfsd que corre como root es que crea estos directorios con el comando mkdir y luego cambia sus permisos con el comando chmod al modo 777. Si el directorio destino es reemplazado con una liga simbólica que apunte a un archivo o directorio restringido, entonces el comando mkdir fallará pero no así el comando chmod lo que significa que el directorio destino de la liga simbólica tendrá permisos de modo 777. La segunda vulnerabilidad es que pcnfsd llama a las subrutinas desistema como root y los strings que se pasan al sistema pueden ser influenciados por los argumentos dados en los RPCs por lo que usuarios remotos pueden ejecutar comandos arbitrarios como root en las máquinas donde corre pcnfsd. Para corregir este error, igualmente se debe conseguir un parche del vendedor para las distintas versiones de pcnfsd. Algunos sistemas cuentan ya con estos parches tales como:. BSDI BSD/OS Hewlett Packard IBM AIX 3.2 IBM AIX 4.1 NEXTSTEP. SCO OpenServer 5.

(36) 34. CAPÍTULO 2. DEBILIDADES DE SEGURIDAD EN NFS.

(37) Capítulo 3 Fortalecimiento de NFS 3.1. Medidas Preventivas. Configuración adecuada Para fortalecer la seguridad en un sistema de archivos tal cowo NFS se pueden tomar medidas preventivas de configuración tales como las siguientes, las cuales enunciamos en forma de consejos prácticos: • Se debe configurar el servidor de NFS de manera que sólo acepte peticiones de programas con privilegios. Esto requiere que el usuario en una máquina remota tenga los privilegios de root antes de enviar peticiones NFS al servidor ( a menos por supuesto de que la máquina remota se encuentre ejecutando un sistema operativo como MSDOS, el cual no hace distinción entre root y no root, o si el sistema operativo no requiere a root para el acceso a puertos privilegiados, o si el hacker es root). • Se deben exportar los sistemas de archivos mediante restricciones a un conjunto de hosts (aún si se exporta a un solo host, ya que el demonio nfsd ejecuta una autentificación mínima y aceptará peticiones de cualquiera que cuente con el filehandle correcto). • Se debe exportar los sistemas de archivos con atributos de sólolectura siempre que sea posible. De esta manera se previene que ~lguien escriba en éstos aún si consigue o adivina el filehandle.. 35.

(38) CAPÍTULO 3. FORTALECIMIENTO DE NFS. 36. • Igualmente se debe evitar exportar un sistema de archivos a un host no existente, ya que esto es equivalente a exportarlo a todo el mundo (ya que cualquiera puede hacerse pasar por ese host). • Se debe correr el programa /usr/etc/exportfs después de realizar modificaciones al archivo /etc/exports • El ruteador del firewall no debe permitir el paso del puerto 111 TCP, el puerto 111 UDP, el puerto 2049 TCP o el puerto 2049 UDP; ya que el puerto 111 es el Portmapper y el puerto 2049 es nfsd. Esto permite sólo usar el sistema de archivos local, o en la red protegida por el firewall. • Se debe utilizar un mapeador de puertos que no redirija las peticiones para montar un sistema de archivos tal como \Vietse Venema's Portmapper (10]. Este mapeador de puertos se puede encontrar en: ftp://ftp.win.tue.nl/pub/security /portmap_3.shar.Z así como un rpcbind seguro tal como la \'ersión de \Vietse Venema que se puede encontrar en: ftp://ftp.win.tue.nl/pub/security /rpcbind_l.1.tar.Z. 3.2. Medidas de Monitoreo. También se pueden tomar algunas medidas de monitoreo para averiguar si nuestro sistema de archivos ha sido comprometido. Para esto existen algunas herramientas de software y consejos prácticos tales como los siguientes.. En todo el árbol de directorios de sistemas de archivos se deben buscar archivos con atributos set-u.id. Cuando un archivo tiene el atributo setuid, cualquier usuario toma prestada la identificación del dueño mien-.

(39) 37. 3.2. MEDIDAS DE MONITOREO. tras ejecuta el comando. Un ejemplo de este archivo es el /bin/passwd al cual si listamos con el comando Is nos muestra lo siguiente:. $ls -1 /bin/passwd -rwsr-xr-x. 1. root. 8454. Jan 4. 1983. /bin/passwd. $. En este caso los permisos indican que cualquiera puede ejecutar el comando pero sólo root puede cambiar el comando passwd. Sin embargo la s en vez de una x en el campo de ejecución para el dueño del archivo indica que cuando un usuario ejecuta este comando, se le darán los permisos correspondientes al dueño del archivo que en este caso es root para poder modificar el archivo /etc/passwd. Es decir, durante la ejecución del comando, el usuario es considerado como root. El bit de set-uid es una idea simple pero elegante patentada por Dennis Ritchie que resuelve varios problemas de seguridad pero que es a su vez potencialmente peligrosa. Puede ser que un intruso deje copias con atributos set-uid de /bin/sh para permitirle el acceso como root en un momento posterior. En este caso, mientras un usuario use el shell, puede ser considerado como root. Para buscar estos archivos se puede utilizar el comando find:. find / -user root -perm -4000 -print. También se puede utilizar el comando ncheck en cada partición de disco:. ncheck -s /dev/rsdOg.

(40) CAPÍTULO 3. FORTALECIMIENTO DE NFS. 38. Como supervisores de red, podemos comprobar que estamos exportando nuestro sistema de archivos a los hosts correctos mediante el comando de UNIX:. /usr/etc/ showmount -e. nombre_del_host.. Por ejemplo:. Y./usr/etc/showmount -e nombre_del_host export list for nombre_del_host: /usr hosta:hostb:hostc /usr/local (everyone). La salida anterior indica que el servidor NFS exporta dos particiones: usr que puede ser montado por los hosts: hosta, host b y hoste; y usr/local que puede ser montado por cualquiera. En este caso la partición usr/local debería ser restringida.. Las siguientes herramientas de software que nos ayudan a monitorear nuestro sistema son las siguientes:. • SATAN es un software que detecta y reporta fallas de seguridad no solamente de nuestro sistema de archivos sino de otros muchos servicios de los hosts de nuestra red. [5]. • COPS es una colección de herramientas diseñadas para ayudar al administrador de sistemas a descubrir algunas fallas de seguridad tales como passwords débiles, la existencia de archivos con identificadores SUID de root, etc. [6]. • TIGER es una herramienta muy parecida a COPS. [7].

(41) 3.2.' MEDIDAS DE MONITOREO. 39. • NFSWatch es un software que lleva un registro de las transacciones en nfs [8).. • NFSBug es un software que prueba el sistema para determinar posibles errores exitentes en nfs incluyendo manejadores de archivos (filehandles) adivinables. Sin embargo este software sólo corre en sistemas Sun. [9] Una explicación mas detallada de estas herramientas, así como los resultados de la ejecución de algunas de ellas, se pueden encontrar en la tesis Proposición de Mecanismos de Seguridad para el Fortalecimiento. de NFS, Julio A. Díaz..

(42) 40. CAPÍTULO 3. FORTALECIMIENTO DE NFS.

(43) Capítulo 4 Otras soluciones utilizadas por NFS Como se vió en la sección anterior, uno de los principales problemas de T\'FS es que un hacker puede tomar el papel de otros usuarios o sistemas. Para evitar esto se puede hacer uso de NFS Seguro de Sun Microsystems el cual mejora la autentificación de NFS mediante el uso de RPC Seguro.. 4.1. Criptografía Simétrica y de Llave Pública. Antes, cabe mencionar que existen dos tipos de criptografía: • criptografía simétrica. • criptografía de llave pública. En la criptografía simétrica, dos ( o más ) usuarios comparten una llave, la cual es usada para encriptar o decriptar mensajes. Un ejemplo clásico de criptografía simétrica es el estándar de encriptación DES. Se dice que la encriptación es simétrica porque ambos usuarios comparten la misma llave. El problema con el sistema de la llave simétrica es cómo llevar esta llave a los usuarios. t\fas adelante veremos que Kerberos ( un ejemplo de un sistema basado exclusivamente en llaves simétricas ) usa un centro de. 41.

(44) 42 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZA.DAS POR NFS distribución de llaves confiables para realizar esta tarea. Otro método para transferir llaves simétricas es codificándolas usando otra forma de criptografía: la criptografía pública. En la criptografía pública, cada usuario tiene dos llaves: una llave privada y una llave pública. La llave privada se guarda en un lugar seguro y nunca se muestra: la llave pública se da a cualquier persona que la quiera. Las llaves son la inversa una de la otra. La información encriptada con la llave privada sólo puede ser descriptada con la llave pública y vice versa. Si obtenemos un mensaje que pretende ser de un usuario particular, simplemente aplicamos la llave pública a ese mensaje. Si es decriptado satisfactoriamente, debe de ser del usuario porque la única manera que el mensaje pudo ser encriptado fue con la llave privada del usuario.. 4.2. El modelo de Diffie-Hellman. Secure RPC esta basado en una variante particular de criptografía de llave pública, conocida como el modelo de Diffie-Hellman. El modelo de Diffie-Hellman, así como otras variantes (RSA), están basados en el hecho de que matemáticamente la llave pública y privada son inversas una de la otra, y las dos llaves son factores de un número muy largo. Es relativamente fácil usar una llave para decriptar un mensaje encriptado con la otra, pero encontrar la otra llave es imposible de hacer computacionalmente, ya que se requiere la descomposición de números muy largos. En el modelo de Diffie-Hellman, la llave privada y pública son ambas, números de 192 bits en los cuales la llave pública es igual a una constante conocida elevada a la potencia de la llave secreta. La llave pública de .i" es entonces igual a la constante elevada a la potencia de la llave privada de .i ". Para un intercambio particular cliente-host, el usuario "b ", también tendrá una combinación de llave privada y pública. Derivamos una llave común para ser usada entre los usuarios a y b tomando la llave pública de b y elevándola a la potencia de la llave privada de a. La misma llave común puede encontrarse tomando la llave pública de a y elevándola a la potencia de la llave privada de b..

(45) 43. 4.3. SECURE RPC. De esta manera se tiene:. Para A la llave común será lle. = Pb5 ª. Para B la llave común será lle= Pa 5 b. donde lle = llave común Pb = llave pública de Pa = llave pública de Sa = llave priYada de Sb = llave privada de. B A A B. El usuario a puede encontrar la llave común porque este usuario tiene la llave privada de a y puede fácilmente obtener la llave pública de b. Del mismo modo, el usuario b tiene la llave privada de b y la llave pública del usuario a. Nadie más tiene ambas piezas de información y la llave común es privada.. 4.3. Secure RPC. RPC Seguro incrementa considerablemente la seguridad de NFS aunque por desgracia no todos los sistemas soportan esta característica. Tal es el caso de HP-UX, ya que RPC Seguro no es un estándar de UNIX. Los elementos de RPC seguro son los usuarios, los clientes, los servidores y el servidor de autentificación. RPC seguro debe ser transparente al usuario ya que éste debe proporcionar su password una sola vez y ser autentificado en base a su password original. El cliente actúa por el usuario para el intercambio de protocolo y los servidores proveen los servicios requeridos, necesitando que los usuarios sean autentificados.

(46) 44 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZADAS POR NFS antes de proporcionar estos servicios. El servidor de autentificación proporciona las llaves públicas y privadas a los servidores y clientes. El protocolo utilizado para verificar la autenticidad es el siguiente: El usuario realiza un login local presentando su identificador de usuario (userid) y su password al cliente, el cliente procede con el mecanismo de login local. Esto es, el cliente puede tener un archivo de passwords locales y una función de comparación del password proporcionado por el usuario con el password encriptado y almacenado localmente. Alternativamente, el cliente puede no almacenar los passwords localmente y necesitar que una base de datos centralizada, que contenga los nombres de los usuarios y sus correspondientes passwords encriptados, se los proporcione. Usualmente se utiliza la misma base de datos que contiene las llaves públicas de la red. Cuando la autentificación del usuario se realiza localmente se recibe de cualquier forma las llaves públicas y privadas de una base de datos de llaves. El cliente decripta la llave privada utilizando el password proporcionado por el usuario y debe hacerse notar que el password del usuario no es enviado jamás a través de la red, evitando así un ataque por escucha. U ----, C: u,pw l.Recibe de una base de datos de llaves públicas un C: registro que contiene la llave secreta del usuario encriptada por el password del usuario: {llave secreta del usuario }pw 2.Decripta la llave secreta utilizando el pw. donde. U = usuario c = cliente u = identif ic.adordeusuario pw = password. El protocolo utilizado para autentificar usuarios que requieren de acceso remoto (login remoto) y que realizan peticiones cliente/servidor es el mismo. El protocolo utilizado para autentificar al cliente se muestra a continuación:.

(47) 4.3. SECURE RPC. C:. 45. l.Recibe la llave pública del servidor al que hace una peticion desde una base de datos de llaves públicas. 2.Genera una llave de sesión para uso entre el cliente y el servidor: (SK) c,s. C -t S:. c, {CK}SKc,s {ventana}CK, {Tl,ventana + l}CK El cliente manda al servidor su propia llave del cliente (CK) encriptada por la llave de sesión entre cliente y servidor, una ventana (tiempo de vida de la llave del cliente) encriptada por la llave del cliente y una estampilla de tiempo TI. El servidor guarda en una tabla de credenciales con un indice ID lo siguiente: C, CK, la ventana, y TI. El servidor decripta la llave privada del cliente CK con la llave de sesión SKc,s la cual obtuvo mediante el modelo de Diffie Hellman anteriormente descrito.. El cliente autentifica al servidor si éste último es capaz de decriptar la llave secreta del cliente mediante el uso de la llave de sesión entre el cliente y el servidor. El servidor decripta la llave secreta CK utilizando la llave de sesión SK. Así puede decriptar la estampilla de tiempo, la ventana y ventana + 1 utilizando la llave de conversación. El valor de ventana + 1 ayuda a prevenir una adivinación correcta de la combinación estampilla de tiempo/ventana por parte de un intruso. El servidor de archirns sabe que el usuario es quien dice ser porque: • El paquete que el usuario envió fue encriptado utilizando la llave de sesión..

(48) 46 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZADAS POR NFS • La única forma en que el usuario pudo conocer la llave de sesión fue generándola, usando la llave pública del servidor y la llave secreta del usuario. • Para conocer la llave secreta del usuario, la estación de trabajo tuvo que buscar la llave secreta en una base de datos de llaves y decriptarla correctamente. • Para decriptar la llave secreta encriptada, el usuario tuvo que conocer la llave con que fue encriptada que es de hecho el password del usuario. El servidor envía el índice ID de vuelta al cliente junto con la estampilla de tiempo-1 en forma encriptada con la llave de sesión. Es esta estampilla de tiempo la que verifica la identidad del servidor hacia el cliente. El cliente almacena ID y CK para uso en peticiones futuras del servidor. El par ID /CK es almacenado en el cliente y borrado cuando el usuario sale del sistema. En futuras peticiones, el cliente autentifica al usuario frente al servidor al mandar el ID y la estampilla de tiempo actual encriptadas utilizando el CK. El servidor decripta la estampilla de tiempo, utiliza el ID para encontrar la entrada en la tabla de credenciales, y determina si la estampilla de tiempo actual no se encuentra más allá de la estampilla de tiempo + la ventana. Si la estampilla de tiempo es válida el servidor verifica la autentificación del usuario y manda al cliente la estampilla de tiempo1 encriptada utilizando el CK. El cliente sabe que la respuesta viene del servidor porque el servidor tiene el valor correcto de estampilla de tiempo-1 y encriptó este valor con la llave correcta.. RPC Seguro utiliza el modelo de generación de llaves de Diffie-Hellman. Bajo este modelo, cada usuario tiene un par -de llaves pública y privada. Una llave secreta a ser compartida por dos usuarios: es generada independientemente por cada usuario. La llave es generada por cada usuario aplicando su propia llave privada (conocida sólo por el dueño) y la llave pública del otro usuario. Cincuenta y seis bits de la llave son extraídos y usados como llave de DES..

(49) 4.3. SECURE RPC. 47. Para realizar un ataque de diccionario para decriptar la llave privada que se encuentra basada en el password del usuario, un atacante debe mandar una petición al servidor para generar la llave de sesión y comparar la que el intruso generó con la que el servidor generó. Una posible falla de seguridad: Para que este esquema funcione correctamente, los clientes deben confiar que el par de llaves pública/privada que se les otorga es válida. Los servidores deben igualmente confiar que las llaves públicas de los usuarios que ellos obtienen sean válidas. Es por esto que los servidores de autentificación que contienen las llaves públicas y privadas deben estar altamente protegidos. Si la seguridad de este servidor se ve comprometida entonces la seguridad de todas las llaves también y por lo tanto del sistema entero. Es por esta razón que se deben certificar las llaves públicas que se aceptan en la base de datos de llaves. El protocolo RPC incluye un campo para parámetros de autentificación en cada llamada que realiza. El contenido de los parámetros de autentificación está determinado por el tipo de autentificación utilizado por el servidor y el cliente. Un servidor puede soportar distintos tipos de autentificación al mismo tiempo .. El tipo A UTH-NONE no provee ninguna autentificación, es decir que no se pasa ninguna información de autentificación. El tipo A UTH-UNIX provee un identificador de usuario, un identificador de grupo y grupos al estilo UNIX en cada llamada que se realiza. El tipo A UTH-DES provee parámetros de autentificación encriptados en DES dentro del esquema de intercambio de llaves pública y privada de Diffie y Hellman. El tipo A UTH-KERB provee parámetros de autentificación encriptados en DES con llaves de sesión intercambiadas mediante lla\'es secretas kerberos. El servidor revisa los permisos al tomar las credenciales de la información de autentificación en cada petición remota. Por ejemplo, si.

(50) • 48 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZADAS POR NFS. se toma el tipo de autentificación A UTH- UNIX, el servidor toma el identificador efectivo de usuario, el identificador efectivo de grupo y los grupos en cada llamada y los utiliza para permitir el acceso. El usar los identificadores de usuario y de grupo implica que el cliente y el servidor deben compartir la misma lista de identificadores o hacer un mapeo local de usuarios y de grupos. Los servidores y clientes deben ponerse de acuerdo en el mapeo del usuario hacia el uid (user identifier) y del grupo al gid (group identifier) para aquellos sitios donde no se implemente un espacio de identificadores de usuario y de grupo consistente. En la práctica dicho mapeo se realiza típicamente en el servidor siguiendo un esquema de mapeo estático o un mapeo establecido por el usuario desde un cliente al momento de montar NFS. Los estilos de autentificación A UTH-DES y A UTH-KERB proveen mayor seguridad pues un usuario malicioso debe conocer los passwords de red de otros usuarios o las llaves privadas para hacerse pasar por ellos.. 4.4. Secure NFS. Para brindar mayor protección, existe una versión de !\FS llamada serure NFS, la cual se encuentra basada en el mecanismo de secure RPC. Para habilitar secure NFS, el sistema necesita llaves pública y privada para cada usuario. En adición, los sistemas de archivos deben ser exportados con la opción de secure y al montar los sistemas de archivos, el comando mount debe especificar con la opción secure mount. Secure NFS esta basado en el mapa de NIS de llaves públicas. Este mapa tiene tres campos:. netname. public_key. private _ key. El primer campo indica la red donde el usuario se encuentra, por ejemplo: unix.uid.domain. En este punto cabría preguntarse qué tan segura es la llave privada cuando es publicada con un servicio de nombres (naming service) que.

(51) 49. 4.4. SECURE NFS. no cuenta con control de accesos. La respuesta es que en NIS, la llave privada es encriptada con el password del usuario; y en NIS Plus, la llave privada también es encriptada, pero cuenta además con una capa adicional de autentificación y control de acceso que previene de accesos aleatorios por parte de los usuarios. Generar una llave es simple, normalmente la llave es generada por alguien con privilegios de root mediante el comando newkey. Este comando acepta ya sea el nombre del usuario o del host debido a que el host debe ser también autentificado. Los usuarios pueden cambiar sus propias llaves mediante el comando. chkey:. user_machi.. chkey. Generating new key for malamud Password: Sending key charige request to NFS Server Done. User_machi.. Algunos problemas con Secure NFS y la inicialización Remota (Remote Booting) Supongamos que existe una falla de energía a la mitad de la noche, y todas las llaves secretas que estaban almacenadas en el servidor se borran. Esto significa que no se puede tener acceso al sistema de archivos Secure NFS. Si el usuario root se encuentra cerca, él o ella, puede teclear el password el cual decriptará la llave privada root, la cual hará que todo proceda, de lo contrario, el acceso a la información será imposible..

(52) 50 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZADAS POR NFS. Otro problema es el arranque (boot) en modo monousuario. Las estaciones de trabajo Unix, usualmente permiten a un usuario inicializar el sistema en modo de un solo usuario, lo que da a la persona privilegios de root. ¿Para qué se hace esto? Créase o no, esto es porque la gente puede olvidar el password de root, lo que provoca que se pierdan todos los privilegios de supervisión y administración del sistema. En sistemas SUN, la inicialización en modo de un usuario, sólo se permite en un puerto físicamente seguro, como la consola. Cuando la computadora es una estación de trabajo, sin embargo, la consola es simplemente el teclado. En otras palabró.5, si deja a una persona en su oficina por una hora, tiene tiempo suficiente de reinicializar su estación de trabajo en modo de un solo usuario, cambiar varios archivos, y después cambiar la estación de trabajo a su operación normal. Existen dos formas de solucionar este problema. La opción de seguridad C2 de SunOS puede ser activada. esta característica de seguridad, que es parte del sistema operativo, requiere de un password para todas las reinicializaciones del sistema, y añade características tales como pedir el login para operaciones críticas. Otra manera de manejar el problema es cambiar el puerto de la consola para que no sea privilegiado, requiriendo de un password y login. Al hacer esto, tal y como es el caso de la característica de seguridad C2, significa que el usuario root debe recordar el password, de lo contrario, el sistema es básicamente inaccesible. El problema mayor con la inicialización (booteo) se encuentra con las máquinas que no cuentan con unidad de disco duro, ya que no es posible que estas estaciones sean totalmente seguras. Siempre es posible para un usuario malicioso, hacerse pasar por el servidor de inicialización y correr un Kernel alterado para registrar la llave secreta del usuario de terminal remota. El problema aquí es que el mecanismo de Secure RPC sólo provee protección después de que el Kernel y el servidor de llaves se encuentren ya corriendo. Antes de esto, no es posible autentificar un servidor remoto..

(53) 4.4. SECURE NFS. 51. Sin embargo, ¿son estos verdaderos problemas? No en un ambiente realista. Por ejemplo, escribir un Kernel para inicialización alterado es una tarea que va de lo difícil a lo casi impráctico. Además, todo lo que un usuario debe hacer, es inicializar de un disco local si esta falla de seguridad se vuelve un problema. Sin embargo, aún con el mejor hardware y software de seguridad en el mundo, la mejor línea de defensa sigue siendo el administrador. Es esta persona, quien a través de buenas prácticas de administración y auditorías adecuadas y oportunas, puede prevenir y/ o detectar intrusiones al sistema..

(54) 52 CAPÍTULO 4. OTRAS SOLUCIONES UTILIZA.DAS POR NFS. 4.5. Otra solución: Kerberos. Como ya se ha mencionado anteriormente, no todos los sistemas de archivos soportan características de encriptación tal y como lo hace RPC Seguro de Sun Microsystems. Tal es el caso de HP-UX de Hewlett Packard. Para tales sistemas de archivos cabe plantearse la posibilidad de instalar Kerberos como un medio de autentificación de los usuarios, que realizan peticiones al sistema de archivos.. 4.5.1. Sistema de Autentificación Kerberos. Kerberos es un sistema de autentificación de redes inseguras que se basa en el modelo de distribución de llaves de Needham y Schroeder. Fue desarrollado en el Massachusets lnstitute of Technology (MIT) en los primeros días del proyecto Athena. Conforme el \HT fue instalando varios cientos de estaciones de trabajo para e) uso general de sus estudiantes con plena conectividad, se hizo claro que los estudiantes empezarían a explorar la red independientemente de que estuvieran autorizados o no. Por lo tanto se necesitaba de un fuerte sistema de seguridad. A este sistema se le llamó Kerberos en referencia al perro mitológico de tres cabezas que resguardaba las puertas del infierno o del Hades. Las tres cabezas representan la autentificación, la autorización y la auditoría (authentification, authorization & accounting). Kerberos eventualmente proveyó sólo el primer componente: la autentificación; ya que se reconoció que diferentes aplicaciones necesitaban diferentes grados de autorización pero siempre que se pudiera determinar quién estaba requiriendo la autentificación. La aplicación podría determinar, por su cuenta, el grado de autorización. Kerberos fue diseñado para que corriera lo mismo en una IBM PC (procesador 8088 a 4.77 Mhz) que en grandes máquinas y aunque el código ha cambiado desde entonces, el protocolo ha permanecido pequeño por lo que aún es apropiado para máquinas pequeñas. Kerberos permite probar la identidad de las entidades que se comuni-.

(55) 4.5. OTRA SOLUCIÓN: KERBEROS. 53. can sobre la red; previene los ataques eavsdropping y replay; detecta la modificación de los flujos de datos con lo que preserva la integridad y previene la lectura no autorizada usando DES con lo que preserva la confidencialidad. Con Kerberos, una sola identificación sirve para probar la identidad del usuario en todos los servidores de la red. Además la seguridad reside en los servidores de autentificación y no en los clientes y servidores de la red. El modelo en el cual se basa Kerberos tiene las siguientes características: • El servicio de autentificación es en base a un árbitro (Third Party) de confianza, por lo que el sistema contará con un cliente, un servidor y un autentificador. • Existirá un centro de distribución de llaves KDC (Key Distribution Center). • El encriptado es realizado a llave secreta. • Los relojes del sistema deben estar sincronizados.. 4.5.2. Proceso de Autentificación. La autentificación permite confiar en la identidad del emisor de un mensaje, así como en la integridad de dicho mensaje. Un sistema de autentificación consiste de dos partes principales:. 1. La firma de un documento de tal forma que la falsificación sea imposible. 2. La verificación de que la firma fue realizada por aquel a quien representa. Ahora bien, en redes los protocolos de autentificación pueden basarse en dos tipos de sistemas:.