Omitir V�nculos de navegaci�n | |
Salir de la Vista de impresi�n | |
Guía de administración del sistema: servicios de seguridad |
Parte I Descripción general de la seguridad
1. Servicios de seguridad (descripción general)
Parte II Seguridad de sistemas, archivos y dispositivos
2. Gestión de seguridad de equipos (descripción general)
3. Control de acceso a sistemas (tareas)
4. Control de acceso a dispositivos (tareas)
5. Uso de la herramienta básica de creación de informes de auditoría (tareas)
6. Control de acceso a archivos (tareas)
7. Uso de la herramienta automatizada de mejora de la seguridad (tareas)
Parte III Roles, perfiles de derechos y privilegios
8. Uso de roles y privilegios (descripción general)
9. Uso del control de acceso basado en roles (tareas)
10. Control de acceso basado en roles (referencia)
Parte IV Servicios criptográficos
13. Estructura criptográfica de Oracle Solaris (descripción general)
14. Estructura criptográfica de Oracle Solaris (tareas)
15. Estructura de gestión de claves de Oracle Solaris
Parte V Servicios de autenticación y comunicación segura
16. Uso de servicios de autenticación (tareas)
Administración de RPC segura (mapa de tareas)
Administración de autenticación con RPC segura (tareas)
Cómo reiniciar el servidor de claves RPC segura
Cómo configurar una clave Diffie-Hellman para un host NIS+
Cómo configurar una clave Diffie-Hellman para un usuario NIS+
Cómo configurar una clave Diffie-Hellman para un host NIS
Cómo configurar una clave Diffie-Hellman para un usuario NIS
Cómo compartir archivos NFS con autenticación Diffie-Hellman
19. Uso de Oracle Solaris Secure Shell (tareas)
20. Oracle Solaris Secure Shell (referencia)
21. Introducción al servicio Kerberos
22. Planificación del servicio Kerberos
23. Configuración del servicio Kerberos (tareas)
24. Mensajes de error y resolución de problemas de Kerberos
25. Administración de las políticas y los principales de Kerberos (tareas)
26. Uso de aplicaciones Kerberos (tareas)
27. El servicio Kerberos (referencia)
Parte VII Auditoría de Oracle Solaris
28. Auditoría de Oracle Solaris (descripción general)
29. Planificación de la auditoría de Oracle Solaris
30. Gestión de la auditoría de Oracle Solaris (tareas)
La llamada de procedimiento remoto (RPC) segura protege los procedimientos remotos con un mecanismo de autenticación. El mecanismo de autenticación Diffie-Hellman autentica tanto el host como el usuario que realiza una solicitud para un servicio. El mecanismo de autenticación utiliza el cifrado Estándar de cifrado de datos (DES). Las aplicaciones que utilizan RPC segura incluyen NFS y los servicios de nombres, NIS y NIS+.
NFS permite que varios hosts compartan archivos a través de la red. En el servicio NFS, un servidor contiene los datos y recursos para varios clientes. Los clientes tienen acceso a los sistemas de archivos que el servidor comparte con los clientes. Los usuarios conectados a los sistemas cliente pueden acceder a los sistemas de archivos mediante el montaje de sistemas de archivos del servidor. Para el usuario en el sistema cliente, los archivos se ven como locales para el cliente. Uno de los usos más comunes de NFS permite que los sistemas se instalen en oficinas mientras se almacenan todos los archivos de usuario en una ubicación central. Algunas de las funciones del servicio NFS, como la opción -nosuid para el comando mount, se pueden utilizar para prohibir la apertura de dispositivos y sistemas de archivos por parte de usuarios no autorizados.
El servicio NFS utiliza RPC segura para autenticar a los usuarios que realizan solicitudes a través de la red. Este proceso se conoce como NFS seguro. El mecanismo de autenticación Diffie-Hellman, AUTH_DH, usa cifrado DES para garantizar el acceso autorizado. El mecanismo AUTH_DH también se ha denominado AUTH_DES. Para obtener más información, consulte lo siguiente:
Para configurar y administrar NFS seguro, consulte Administración de sistema NFS seguro de Guía de administración del sistema: servicios de red.
Para configurar las tablas NIS+ e introducir nombres en la tabla cred, consulte la System Administration Guide: Naming and Directory Services (NIS+).
Para una descripción de las transacciones implicadas en la autenticación RPC, consulte Implementación de autenticación Diffie-Hellman.
Las funciones de cifrado del Estándar de cifrado de datos (DES) utiliza una clave de 56 bits para cifrar los datos. Si dos principales o usuarios de credenciales conocen la misma clave DES, pueden comunicarse en privado mediante la clave para cifrar y descifrar texto. DES es un mecanismo de cifrado relativamente rápido. Un chip DES hace que el cifrado sea incluso más rápido. Sin embargo, si el chip no está presente, se sustituye una implementación de software.
El riesgo de usar sólo la clave DES es que un intruso puede recopilar suficientes mensajes de texto cifrado que se cifraron con la misma clave para poder descubrir la clave y descifrar los mensajes. Por este motivo, los sistemas de seguridad como NFS seguro necesitan cambiar las claves con frecuencia.
Kerberos es un sistema de autenticación desarrollado en MIT. Algunos cifrados en Kerberos se basan en DES. El soporte de Kerberos V4 ya no se proporciona como parte de RPC segura. Sin embargo, una implementación por parte del cliente y por parte del servidor de Kerberos V5, que utiliza RPCSEC_GSS, se incluye con esta versión. Para obtener más información, consulte el Capítulo 21Introducción al servicio Kerberos.
El método de autenticación de un usuario Diffie-Hellman (DH) no es trivial para un intruso que quiere ingresar. El cliente y el servidor tienen sus propias claves privadas, las cuales se utilizan con la clave pública para crear una clave común. La clave privada también se conoce como clave secreta. El cliente y el servidor utilizan la clave común para comunicarse entre sí. La clave común se cifra con una función de cifrado acordada, como DES.
La autenticación se basa en la capacidad del sistema emisor de utilizar la clave común para cifrar la hora actual. A continuación, el sistema receptor puede descifrar y comprobar la hora actual. La hora en el cliente y el servidor debe estar sincronizada. Para obtener más información, consulte Gestión del protocolo de hora de red (tareas) de Guía de administración del sistema: servicios de red.
Las claves públicas y privadas se almacenan en una base de datos NIS o NIS+. NIS almacena las claves en el mapa publickey. NIS+ almacena las claves en la tabla cred. Estos archivos contienen la clave pública y la clave privada para todos los usuarios potenciales.
El administrador del sistema es responsable de configurar mapas NIS o tablas NIS+ y de generar una clave pública y una clave privada para cada usuario. La clave privada se almacena en formato cifrado con la contraseña del usuario. Este proceso hace que sólo el usuario conozca la clave privada.
En esta sección se describe la serie de transacciones en una sesión cliente-servidor que utiliza autenticación Diffie-Hellman (AUTH_DH).
A veces, antes de una transacción, el administrador ejecuta el comando newkey o nisaddcred para generar una clave pública y una clave secreta. Cada usuario tiene una clave pública y una clave secreta únicas. La clave pública se almacena en una base de datos pública. La clave secreta se almacena en formato cifrado en la misma base de datos. El comando chkey cambia el par de claves.
Normalmente, la contraseña de inicio de sesión es idéntica a la contraseña de RPC segura. En este caso, el comando keylogin no es necesario. Sin embargo, si las contraseñas son distintas, los usuarios tienen que iniciar sesión y, a continuación, ejecutar el comando keylogin.
El comando keylogin le solicita al usuario una contraseña de RPC segura. El comando utiliza la contraseña para descifrar la clave secreta. El comando keylogin pasa la clave secreta descifrada al programa servidor de claves. El servidor de claves es un servicio RPC con una instancia local en cada equipo. El servidor de claves guarda la clave secreta descifrada y espera a que el usuario inicie una transacción RPC segura con un servidor.
Si la contraseña de inicio de sesión y la contraseña de RPC son iguales, el proceso de inicio de sesión pasa la clave secreta al servidor de claves. Si las contraseñas deben ser diferentes, el usuario debe ejecutar siempre el comando keylogin. Cuando el comando keylogin se incluye en el archivo de configuración del entorno del usuario, como el archivo ~/.login, ~/.cshrc o ~/.profile, el comando keylogin se ejecuta automáticamente siempre que el usuario inicia sesión.
Cuando el usuario inicia una transacción con un servidor, ocurre lo siguiente:
El servidor de claves genera aleatoriamente una clave de conversación.
El núcleo usa la clave de conversación junto con otros materiales para cifrar la indicación de hora del cliente.
El servidor de claves busca la clave pública del servidor en la base de datos de claves públicas. Para obtener más información, consulte la página del comando man publickey(4).
El servidor de claves utiliza la clave secreta del cliente y la clave pública del servidor para crear una clave común.
El servidor de claves cifra la clave de conversación con la clave común.
La transmisión, que incluye la indicación de hora cifrada y la clave de conversación cifrada, se envía al servidor. La transmisión incluye una credencial y un verificador. La credencial contiene tres componentes:
El nombre de red del cliente
La clave de conversación, que se cifra con la clave común
Una "ventana", que se cifra con la clave de conversación
La ventana es la diferencia en tiempo que el cliente afirma que se debe permitir entre el reloj del servidor y la indicación de hora del cliente. Si la diferencia entre el reloj del servidor y la indicación de hora es mayor que la ventana, el servidor rechaza la solicitud del cliente. En circunstancias normales, este rechazo no se produce porque el cliente primero se sincroniza con el servidor antes de iniciar la sesión RPC.
El verificador del cliente contiene lo siguiente:
La indicación de hora cifrada
Un verificador cifrado de la ventana especificada, que se reduce a 1
El verificador de ventana es necesario en caso de que alguien desee asumir la personalidad de un usuario. El imitador puede escribir un programa que, en lugar de completar los campos cifrados de la credencial y el verificador, sólo inserte bits de manera aleatoria. El servidor descifra la clave de conversación en alguna clave aleatoria. El servidor utiliza la clave para intentar descifrar la ventana y la indicación de hora. El resultado son números aleatorios. Después de miles de intentos, sin embargo, el par ventana/indicación de hora aleatorio podría pasar el sistema de autenticación. El verificador de ventana disminuye la posibilidad de que una credencial falsa se pueda autenticar.
Cuando el servidor recibe la transmisión del cliente, se produce lo siguiente:
El servidor de claves local del servidor busca la clave pública del cliente en la base de datos de claves públicas.
El servidor de claves utiliza la clave pública del cliente y la clave secreta del servidor para deducir la clave común. La clave común es la misma clave común que el cliente procesa. Sólo el servidor y el cliente pueden calcular la clave común porque el cálculo requiere que se conozca una de las claves secretas.
El núcleo usa la clave común para descifrar la clave de conversación.
El núcleo llama al servidor de claves para descifrar la indicación de hora del cliente con la clave de conversación descifrada.
Después de que el servidor descifra la indicación de hora del cliente, el servidor almacena cuatro elementos de información en una tabla de credenciales:
El nombre de equipo del cliente
La clave de conversación
La ventana
La indicación de hora del cliente
El servidor almacena los primeros tres elementos para su uso futuro. El servidor almacena la indicación de hora del cliente para evitar que se realicen reproducciones. El servidor acepta sólo indicaciones de hora que son cronológicamente mayores que la última indicación de hora vista. Como resultado, cualquier transacción reproducida seguramente sea rechazada.
Nota - El nombre del emisor de llamada está implícito en las transacciones. El emisor se debe autenticar de alguna manera. El servidor de claves no puede usar la autenticación DES para autenticar el emisor de llamada porque el uso de DES por parte del servidor de claves crearía un interbloqueo. Para evitar un interbloqueo, el servidor de claves almacena las claves secretas por ID de usuario (UID) y otorga solicitudes sólo a procesos root locales.
El servidor devuelve un verificador al cliente, que incluye lo siguiente:
El ID de índice, que el servidor registra en su antememoria de credenciales
La indicación de hora del cliente menos 1, que se cifra mediante la clave de conversación
El motivo para sustraer 1 de la indicación de hora del cliente es para asegurarse de que la indicación de hora esté desactualizada. Una indicación de hora desactualizada no puede volver a utilizarse como un verificador de cliente.
El cliente recibe el verificador y autentica el servidor. El cliente sabe que sólo el servidor pudo haber enviado el verificador ya que sólo el servidor conoce la indicación de hora que el cliente envió.
Con cada transacción después de la primera transacción, el cliente devuelve el ID de índice al servidor en su siguiente transacción. El cliente también envía otra indicación de hora cifrada. El servidor envía de vuelta la indicación de hora del cliente menos 1, que se cifra mediante la clave de conversación.