El entorno NFS es una forma poderosa y conveniente de compartir sistemas de archivos en una red de distintas arquitecturas de equipos y sistemas operativos. Sin embargo, las mismas funciones que hacen que el uso compartido de sistemas de archivos a través de la operación NFS sea cómodo, también plantean algunos problemas de seguridad. Históricamente, la mayoría de las implementaciones NFS han utilizado autenticación UNIX (o AUTH_SYS) pero también ha habido métodos de autenticación más seguros, como AUTH_DH, disponibles. Al utilizar autenticación UNIX, un servidor NFS autentica una solicitud de archivo al autenticar el equipo que formula la solicitud, pero no el usuario. Por lo tanto, un usuario cliente puede ejecutar su para convertirse en superusuario y suplantar al responsable de un archivo. Si se utiliza la autenticación DH, el servidor NFS autentica el usuario, lo cual hace que este tipo de suplantación sea mucho más difícil.
Con acceso root y conocimiento de programación de red, cualquier usuario puede introducir datos arbitrarios en la red y extraer cualquier dato de ella. Los ataques más peligrosos implican la introducción de datos. Un ejemplo es la suplantación de un usuario mediante la generación de paquetes correctos o mediante la grabación de “conversaciones” y su posterior reproducción. Estos ataques afectan la integridad de los datos. Los ataques que implican intrusiones pasivas, que consisten simplemente en escuchar el tráfico de la red sin suplantar a nadie, no son tan peligrosos, porque integridad de los datos no está comprometida. Los usuarios pueden proteger la privacidad de la información confidencial mediante el cifrando de los datos que se envían a través de la red.
Un enfoque común para los problemas de seguridad de la red es dejar la solución a cada aplicación. Un mejor enfoque es implementar un sistema de autenticación estándar en un nivel que cubra todas las aplicaciones.
El sistema operativo Oracle Solaris incluye un sistema de autenticación en el nivel de del RPC, que es el mecanismo en el que se crea la operación NFS. Este sistema, conocido como RPC seguras, mejora mucho la seguridad de los entornos de red y proporciona seguridad adicional a los servicios como, por ejemplo, el sistema NFS. Un sistema NFS que utiliza las utilidades que se proporcionan con RPC seguras, se conoce como sistema NFS seguro.
Las RPC seguras son fundamentales para un sistema NFS seguro. El objetivo de las RPC seguras es crear un sistema que sea tan seguro, como mínimo, como un sistema de tiempo compartido. En un sistema de tiempo compartido, todos los usuarios comparten una única computadora y los usuarios inician sesión mediante contraseñas de inicio de sesión. Con la autenticación estándar de cifrado de datos (DES), se completa el mismo proceso de datos de autenticación. Los usuarios pueden iniciar sesión en cualquier equipo remoto al igual que los usuarios pueden iniciar sesión en una terminal local. Las contraseñas de inicio de sesión de los usuarios son sus garantías de seguridad de la red. En un entorno de tiempo compartido, el administrador del sistema tiene una obligación ética de no cambiar una contraseña para sustituir a alguien. En las RPC seguras, se confía que el administrador de la red no modificará entradas en una base de datos que almacena las claves públicas.
Un sistema de autenticación RPC: credenciales y verificadores. Con las insignias de ID como ejemplo, la credencial es lo que identifica una persona: un nombre, dirección y fecha de nacimiento. El verificador es la fotografía que se adjunta a la insignia. Puede tener la certeza de que la insignia no se ha robado al comprobar la fotografía que aparece en ella con la persona que la lleva. En RPC, el proceso del cliente envía una credencial y un verificador al servidor con cada solicitud de RPC. El servidor vuelve a enviar sólo un verificador porque el cliente ya "conoce" las credenciales del servidor.
La autenticación de RPC es abierta, lo que significa que es posible conectar una variedad de sistemas de autenticación, como UNIX, DH y KERB.
Cuando un servicio de red usa la autenticación UNIX, las credenciales contienen el nombre de host del cliente, UID, GID y la lista de acceso de grupos. Sin embargo, como no existe un verificador, un superusuario puede falsificar las credenciales adecuadas mediante comandos como su. Otro problema con la autenticación UNIX es que asume que todos los equipos de una red son equipos UNIX. La autenticación UNIX se desglosa cuando se aplica a otros sistemas operativos en una red heterogénea.
Para superar los problemas de autenticación UNIX, las RPC seguras utilizan autenticación DH.
La autenticación DH utiliza el estándar de criptografía de datos (DES) y criptografía de clave pública Diffie-Hellman para autenticar a los usuarios y los equipos en la red. DES es un mecanismo de cifrado estándar. La criptografía por clave pública Diffie-Hellman es un sistema de cifrado que involucra dos claves: una pública y una secreta. Las claves públicas y las claves secretas se almacenan en el espacio de nombres. NIS almacena las claves en el mapa de claves públicas. Estos mapas contienen la clave pública y la clave secreta de todos los usuarios potenciales. Para obtener más información sobre cómo configurar los mapas, consulte Trabajo con servicios de nombres y de directorio en Oracle Solaris 11.2: DNS y NIS .
La seguridad de la autenticación DH se basa en la capacidad del remitente de cifrar la hora actual, que el receptor luego puede descifrar y verificar con su propio reloj. La indicación de hora se cifra con DES. Los dos agentes deben coincidir en el tiempo actual y de remitente y receptor deben utilizar la misma clave de cifrado.
Si una red ejecuta un programa de sincronización de tiempo, el tiempo del cliente y el servidor se sincronizan automáticamente. Si un programa de sincronización de tiempo no está disponible, los indicadores de tiempo se pueden calcular utilizando el horario del servidor en lugar del de la red. El cliente pregunta la hora al servidor antes de iniciar la sesión RPC y, luego, calcula la diferencia de tiempo entre reloj del servidor y su propio reloj. Esta diferencia se utiliza para compensar el reloj del cliente al calcular los indicadores de fecha y hora. Si los relojes del cliente y el servidor dejan de estar sincronizados, el servidor empieza a rechazar las solicitudes del cliente. El sistema de autenticación DH en el cliente se vuelve a sincronizar con el servidor.
El cliente y el servidor llegan a la misma clave de cifrado al generar una clave de conversación aleatoria, también conocida como clave de sesión y al usar criptografía por clave pública para deducir una clave común. La clave común es una clave que sólo el cliente y el servidor son capaces de deducir. La clave de conversación se utiliza para cifrar y descifrar la indicación de hora del cliente. La clave común se emplea para cifrar y descifrar la clave de conversación.
Tenga en cuenta los siguientes puntos si tiene planificado utilizar RPC seguras:
Si un servidor se bloquea cuando no hay un administrador del sistema disponible (después de un fallo de energía, por ejemplo), se suprimen todas las claves secretas almacenadas en el sistema. Ningún proceso que pueda acceder a los servicios de red seguros o montar un sistema de archivos NFS. Los procesos importantes durante un reinicio se ejecutan normalmente como root. Por lo tanto, estos procesos funcionarían si la clave secreta root se hubiera almacenado en otro lugar, pero nadie estaría disponible para escribir la contraseña que los descifra. keylogin -r permite que root almacene la clave secreta borrada en /etc/.rootkey, que keyserv lee.
Algunos sistemas se inician en modo de usuario único, con un shell de inicio de sesión root en la consola y sin solicitud de contraseña. La seguridad física es imperativa en estos casos.
El inicio de equipos sin disco no es totalmente seguro. Otra persona puede conectarse como el servidor de inicio e iniciar un núcleo ilícito que, por ejemplo, haga un registro de la clave secreta en un equipo remoto. El sistema NFS seguro proporciona protección sólo después de que el núcleo y el servidor de claves se ejecuten. De lo contrario, no hay forma de autenticar las respuestas que son dadas por el servidor de inicio. Esta limitación podría ser un problema grave, pero la limitación requiere un ataque sofisticado utilizando código fuente del núcleo. Además, el delito dejaría evidencia. Si sondea la red para los servidores de inicio, detectaría la ubicación del servidor de inicio ilícito.
La mayoría de los programas setuid son responsabilidad de root. Si la clave secreta de root se almacena en /etc/.rootkey, estos programas se comportan como siempre. Si un programa setuid es responsabilidad de un usuario, es posible que no siempre funcione el programa setuid. Por ejemplo, supongamos que un programa setuid es responsabilidad de dave y dave no ha iniciado sesión en el equipo desde que se inició. El programa no podría acceder a los servicios de red segura.
Si inicia sesión en un equipo remoto (con login, rlogin o telnet) y usa keylogin para obtener acceso, otorga acceso a su cuenta. Su clave secreta se transfiere al servidor de claves de ese equipo, que luego almacena su clave secreta. Este proceso sólo es una preocupación si no confía en el equipo remoto. Si tiene dudas, sin embargo, no inicie sesión en un equipo remoto si éste requiere una contraseña. En su lugar, utilice el entorno NFS para montar los sistemas de archivos que compartirá el equipo remoto. Como alternativa, puede utilizar keylogout para suprimir la clave secreta del servidor de claves.
Si un directorio de inicio se comparte con la opción –o sec=dh, los inicios de sesión remotos pueden ser un problema. Si los archivos /etc/hosts.equiv o ~/.rhosts no están configurados para solicitar una contraseña, el inicio de sesión se realiza correctamente. Sin embargo, los usuarios no pueden acceder a sus directorios principales porque no se ha producido la autenticación localmente. Si se les pide una contraseña a los usuarios, estos tienen acceso a sus directorios principales si la contraseña coincide con la contraseña de la red.