Configuración del Firewall con el Protocolo de Autenticación Kerberos

Nombrado así por el perro de tres cabezas que custodia las puertas del Hades en los mitos de la Antigua Grecia, el protocolo Kerberos proporciona un servicio de autenticación seguro para las redes informáticas. Realiza una autenticación mutua entre el usuario y el servidor con la ayuda de un Centro de Distribución de Claves (KDC) de terceros confiable, que provee el servicio de autenticación y emisió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 espionaje mediante criptografía de clave compartida. El objetivo principal de Kerberos es evitar la transmisión de contraseñas encriptadas a través de la red. Esto elimina la amenaza de los sniffers de paquetes y mejora la seguridad general de la red.

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

• Si el servidor Kerberos está inactivo, los usuarios no pueden iniciar sesión. El problema se puede resolver 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 período de validez determinado.
• Kerberos no se puede usar cuando los usuarios desean conectarse a servicios desde sistemas no confiables.
• En caso de que se utilice criptografía simétrica, el compromiso de la infraestructura de autenticación permitirá a un atacante suplantar a 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 se compone del Servidor de Autenticación (AS) y del Servidor de Emisión de Tickets (TGS). TGT es un Ticket de Concesión de Tickets.

1. El usuario ingresa su nombre de usuario y contraseña. El ID del usuario en texto claro se envía al Servidor de Autenticación (AS) junto con una solicitud de servicios en nombre del usuario.
2. AS verifica si el nombre de usuario existe en la base de datos. Si hay información sobre ese usuario, AS puede generar la clave secreta del cliente de acuerdo con el ID y la contraseña del usuario. AS envía al usuario:
   • Clave de sesión Cliente/TGS (encriptada con la clave secreta del cliente);
   • TGT que incluye el ID del usuario, la dirección de red y el período de validez del ticket + Clave de sesión Cliente/TGS (encriptada con la clave secreta del TGS).
3. El usuario decodifica el primer mensaje, pero no puede decodificar el segundo, ya que no posee la clave secreta del TGS. El cliente envía un mensaje al TGS:
   • TGT recibido de AS + ID del Servidor + Clave secreta Cliente/TGS (encriptada con la clave secreta del TGS);
   • Autenticador que incluye el ID del cliente y una marca de tiempo (encriptada con la clave de sesión Cliente/TGS).
4. TGS descifra el primer mensaje, obtiene el TGT y la clave de sesión TGS/Cliente, con la cual descifra el segundo mensaje. TGS verifica si el ID del usuario del primer mensaje coincide con el del segundo mensaje y si la marca de tiempo no excede el período de validez del ticket. En caso de que todo sea correcto, TGS envía al usuario:
   • ID del usuario, dirección de red, período de validez del ticket + Clave de sesión Cliente/Servidor (encriptada con la clave secreta del Servidor);
   • Clave de sesión Cliente/Servidor (encriptada con la clave secreta Cliente/TGS).
5. El cliente envía lo siguiente al Servidor al que intenta acceder:
   • ID del usuario, dirección de red, período de validez del ticket + Clave de sesión Cliente/Servidor (encriptada con la clave secreta del Servidor);
   • Autenticador que incluye el ID y la marca de tiempo (encriptado con la clave de sesión Cliente/Servidor).
6. El servidor objetivo descifra los mensajes del usuario, verifica que los IDs del usuario en ambos mensajes sean iguales y que el período de validez no se haya excedido, y luego envía al cliente el siguiente parámetro para confirmar su identidad:
   • Marca de tiempo + 1 (encriptada con la clave de sesión Cliente/Servidor)

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

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

El firewall de base de datos DataSunrise soporta el protocolo de autenticación Kerberos. Se deben implementar algunos cambios en la configuración para permitir las operaciones de Kerberos, los cuales 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 de usuarios se realiza a través de la Interfaz de Soporte para Proveedores de Seguridad (SSPI). Existen dos protocolos que se pueden utilizar: NTLM y Kerberos. NTLM es un protocolo más lento y menos seguro, por lo que solo contemplaremos la personalización de Kerberos. Para habilitar Kerberos, se deben cumplir varias condiciones:

1. La delegación para Usuarios y Computadoras de Active Directory debe estar habilitada.
   • Vaya a Usuarios y Computadoras de Active Directory.
   • Encuentre la cuenta de la computadora en la que está instalado DataSunrise.
   • Vaya a la pestaña Delegación y cambie al estado “Confiar en esta computadora para delegar a cualquier servicio”.
2. La dirección proxy debe coincidir con el SPN registrado del servicio MSSQLSvc. Utilice la herramienta SetSPN para registrar los dos SPN requeridos para la cuenta de la computadora para la cual 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 registrados se puede obtener mediante el siguiente comando:

   setspn -L proxy-host

   Para eliminar el SPN proxy, ejecute lo siguiente:

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

   Para probar el esquema de autorización, ejecute 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 ha sido utilizado por el servidor: SQL, NTLM o KERBEROS.

3. En caso de recibir el error “Cannot generate SSPI context”, consulte las instrucciones de soporte de Microsoft sobre cómo solucionar el problema con la interfaz de soporte para proveedores de seguridad.