La Configuración del Cortafuegos para el Protocolo de Autenticación Kerberos

Nombrado según el perro de tres cabezas que guardaba las puertas del Hades en los mitos griegos antiguos, el protocolo Kerberos proporciona un servicio de autenticación seguro para redes de computadoras. Realiza la autenticación mutua entre el usuario y el servidor con la ayuda de un Centro de Distribución de Claves (KDC) de terceros de confianza que proporciona los servicios de autenticación y concesión de tickets. Todos los sistemas operativos principales, incluidos Microsoft Windows, Linux, Apple OS X y FreeBSD, soportan el protocolo Kerberos.

Los mensajes del protocolo Kerberos están protegidos contra ataques de repetición y escuchas mediante criptografía de secreto compartido. El objetivo principal de Kerberos es evitar la transmisión de contraseñas cifradas a través de la red. Elimina la amenaza de los sniffers de paquetes y mejora la seguridad general de la red.

Aunque el proveedor de soporte de seguridad de Kerberos maneja eficazmente amenazas de seguridad severas, puede ser difícil de implementar debido a una variedad de limitaciones:

• Si el servidor Kerberos está caído, los usuarios no pueden iniciar sesión. El problema puede resolverse utilizando mecanismos de autenticación de respaldo y múltiples servidores Kerberos.
• Los relojes de los hosts involucrados deben estar sincronizados. De lo contrario, la autenticación fallará, ya que los tickets de Kerberos tienen un periodo de disponibilidad determinado.
• Kerberos no puede utilizarse cuando los usuarios quieren conectarse a servicios desde sistemas no confiables.
• En caso de que se utilice criptografía simétrica, la vulnerabilidad de la infraestructura de autenticación permitirá a un atacante hacerse pasar por cualquier usuario.
• Cada servicio de red que requiera un nombre de host diferente necesitará su propio conjunto de claves Kerberos.

Cómo Funciona la Autenticación Kerberos

El Centro de Distribución de Claves consta del Servidor de Autenticación (SA) y el Servidor de Concesión de Tickets (TGS). TGT es un Ticket de Concesión de Tickets.

1. El usuario introduce su nombre de usuario y contraseña. El ID de usuario en texto claro se envía al Servidor de Autenticación (SA) con una solicitud de servicios en nombre del usuario.
2. El SA verifica si el nombre de usuario está en la base de datos. Si hay información sobre ese usuario, entonces el SA puede generar la clave secreta del cliente según el ID y la contraseña del usuario. El SA envía al usuario:
   • Clave de sesión Cliente/TGS (cifrada con la clave secreta del cliente);
   • TGT incluyendo ID de usuario, dirección de red y el periodo de validez del ticket + Clave de sesión Cliente/TGS (cifrada con la clave secreta de TGS).
3. El usuario decodifica el primer mensaje pero no puede decodificar el segundo, porque el usuario no tiene la clave secreta de TGS. El cliente envía un mensaje al TGS:
   • TGT recibido del SA + ID del servidor + clave secreta TGS/Cliente (cifrada con la clave secreta del TGS);
   • Autenticador incluido el ID del cliente y la marca de tiempo (cifrada con la clave de sesión Cliente/TGS).
4. El TGS descifra el primer mensaje, obtiene el TGT + clave de sesión TGS/Cliente, con la cual descifra el segundo mensaje. El TGS verifica si el ID de usuario del primer mensaje coincide con el ID del segundo mensaje y si la marca de tiempo no excede el periodo de validez del ticket. En caso de que todo sea correcto, el TGS envía al usuario:
   • ID utilizado, dirección de red, periodo de validez del ticket + clave de sesión Cliente/Servidor (cifrada con la clave secreta del servidor);
   • Clave de sesión Cliente/Servidor (cifrada con la clave secreta Cliente/TGS).
5. El cliente envía lo siguiente al servidor al que intenta acceder:
   • ID utilizado, dirección de red, periodo de validez del ticket + clave de sesión Cliente/Servidor (cifrada con la clave secreta del servidor);
   • Autenticador incluyendo ID y marca de tiempo (cifrado con la clave de sesión Cliente/Servidor).
6. El servidor de destino descifra los mensajes del usuario, verifica si los ID de usuario de ambos mensajes tienen el mismo valor y si el periodo de validez no está excedido, luego envía al cliente el siguiente parámetro para confirmar su identidad:
   • Marca de tiempo + 1 (cifrada con la clave de sesión Cliente/Servidor)

El cliente verifica si el valor de la marca de tiempo es marca de tiempo + 1, lo que muestra la verdadera identidad de un servidor. Si es así, el cliente puede confiar en el servidor y comenzar a trabajar con él.

Configuración del cortafuegos para trabajar con el protocolo de autenticación Kerberos

El cortafuegos de base de datos DataSunrise soporta el protocolo de autenticación Kerberos. Deben implementarse algunos cambios de configuración para permitir las operaciones de Kerberos, que pueden variar según el producto RDBMS utilizado. En este artículo, mostraremos cómo personalizar Kerberos en MS SQL Server.

Al trabajar en Active Directory, la autorización del usuario se realiza a través de la Interfaz de Proveedor de Soporte de Seguridad (SSPI). Hay dos protocolos que pueden usarse: NTLM y Kerberos. NTLM es un protocolo más lento y menos seguro, por lo tanto, solo contemplaremos la personalización de Kerberos. Para habilitar Kerberos deben cumplirse varias condiciones:

1. Debe estar habilitada la delegación para Usuarios y Equipos de Active Directory.
   • Vaya a Usuarios y Equipos de Active Directory.
   • Encuentre la cuenta del equipo donde está instalado DataSunrise.
   • Vaya a la pestaña Delegación y cambie al estado “Confiar en este equipo para la delegación de cualquier servicio”.
2. La dirección proxy debe coincidir con el SPN registrado del servicio MSSQLSvc. Use la herramienta SetSPN para registrar dos SPN’s necesarios para la cuenta del equipo al que ha permitido la delegación: setspn -A MSSQLSvc/proxy-host:proxy-port proxy-host setspn -A MSSQLSvc/full-fqdn-proxy-host:proxy-port proxy-host

   La lista de todos los SPN’s registrados puede obtenerse con el siguiente comando:

   setspn -L proxy-host

   Para eliminar el proxy del SPN, realice lo siguiente:

   setspn -D MSSQLSvc/proxy-host:proxy-port proxy-host

   Para probar el esquema de autorización, realice el siguiente comando después de conectarse al servidor:

   select auth_scheme from sys.dm_exec_connections where session_id=@@spid

   El resultado corresponderá al esquema de autenticación que el servidor ha utilizado: SQL, NTLM o KERBEROS.

3. En caso de que reciba un error “No se puede generar el contexto de SSPI”, consulte las instrucciones de soporte de Microsoft sobre cómo solucionar el problema con la interfaz del proveedor de soporte de seguridad.