Casi todas las evaluaciones de seguridad, pruebas de penetración o conversaciones sobre arquitectura de AD terminan incluyendo la recomendación de «cambiar de LDAP no seguro a LDAPS» para su Active Directory (AD). Al trabajar para un proveedor de software cuyos productos «hacen cosas con AD», escucho varias veces a la semana la pregunta: «¿Su producto XY es compatible con LDAPS? Si no es así, ¿está en la hoja de ruta?». En la mayoría de los casos, la respuesta correcta es «No, y no es un problema de seguridad». Veamos las razones de esa respuesta.
¿Cuál es el problema con LDAPS?
Internet ofrece literalmente miles de artículos, blogs y vídeos sobre cómo crear e importar certificados TLS en los controladores de dominio (DC) para que sirvan LDAP sobre TLS en el puerto 636/TCP. Para obtener más información sobre el método que utilizan los DC para seleccionar su certificado LDAPS cuando existen varios candidatos, puede leer esta publicación de Marc-André Moreau en AwakeCoding, pero, en resumen, Moreau explica que:
«Habilitar y aplicar LDAPS es una tarea habitual para reforzar la seguridad en los entornos de Windows Active Directory actuales... En teoría, todo parece perfecto, hasta que te das cuenta de que no solo [no puedes] seleccionar explícitamente el certificado LDAPS que se va a utilizar, sino que tampoco hay registros que habilitar ni forma de diagnosticar el problema».
Lo que estos artículos sobre «implementar LDAPS» no suelen explicar es qué hacer con LDAPS una vez habilitado. Sin embargo, hay algo que es seguro: sus DC seguirán prestando servicio LDAP sin TLS en el puerto 389, y no podrá deshabilitarlo ni bloquearlo en el firewall sin causar graves trastornos a los miembros de AD.
Permítanme repetir: un miembro de AD siempre utilizará el puerto 389/3268 para cualquier consulta LDAP/GC que tenga que realizar en virtud de su condición de miembro de AD. No hay forma de cambiar ese comportamiento ni de inducir a un equipo miembro a utilizar el LDAPS respaldado por TLS en el puerto 636/3269, y punto. Tampoco existe una forma estandarizada y universalmente fiable de que la infraestructura anuncie el LDAPS a las aplicaciones.
Por qué las soluciones alternativas de LDAPS no funcionan
Dado que el único mecanismo conocido para el descubrimiento de servicios LDAP es el DNS, se han probado múltiples técnicas:
- Añade un registro SRV para LDAPS, como _ldaps._tcp.domain.com junto con _ldap y _gc.
- Cambia el número de puerto en los registros del servicio LDAP de 389 a 636 (y evita que los DC los actualicen).
- Reemplazar los registros SRV _ldap por _ldaps (es decir, eliminar los registros _ldap y _gc ).
El problema con esos enfoques es que no funcionan.
Añadir un registro SRV para LDAPS no cambia nada.
Dado que _ldaps no es un servicio estándar, ninguna aplicación lo buscará en el DNS. Si crea una aplicación que se beneficie de LDAP sobre TLS, puede implementar la detección del servicio LDAPS en su código; entonces funcionará como cualquier otra detección de servicio personalizada. Pero no es ni ha sido nunca un estándar del sector, por lo que ninguna otra aplicación lo utilizará.
Cambiar el número de puerto no funcionará.
Cambiar el número de puerto no interrumpirá las comunicaciones de los miembros de AD, ya que el puerto 389 está codificado en Windows. Esta acción podría interrumpir otras aplicaciones que utilizan LDAP, ya que cambiar el puerto de 389 a 636 no hará que intenten establecer un protocolo de enlace TLS antes de intentar un enlace LDAP.
Eliminar registros _ldap y _gc = Simplemente no lo hagas.
El tercer enfoque es una excelente manera de interrumpir el descubrimiento de servicios para LDAP, incluido el de los miembros del dominio. No lo haga en casa (ni en el trabajo... ni en ningún otro lugar, en realidad).
Enlaces simples frente a enlaces SASL
Entonces, ¿el LDAP en Active Directory es simplemente «inseguro por diseño»? Todo lo contrario.
La razón por la que se le ha recomendado cambiar a LDAPS es para proteger las credenciales de texto sin cifrar que utiliza LDAP si realiza un enlace simple. El caso es que los miembros de AD, y la mayoría de las aplicaciones que acceden a AD a través de LDAP, no utilizan enlaces simples. En su lugar, utilizan enlaces SASL en los que la autenticación se realiza mediante GSS-SPNEGO y la capa de cifrado LDAP se negocia con claves de sesión intercambiadas durante el proceso de autenticación.
Por lo tanto, no solo no hay credenciales en texto claro que proteger, sino que la comunicación que se lleva a cabo ya está cifrada, sin necesidad de depender de certificados para la capa TLS. Este mecanismo no se limita a los miembros del dominio. Cualquier aplicación puede hacerlo, independientemente del sistema operativo y de la pertenencia al dominio.
¿Qué se debe hacer para reforzar la seguridad de AD LDAP, si no se bloquea el puerto 389?
Si está seguro de que ninguna aplicación de su entorno necesita realmente enlaces simples con credenciales de texto sin cifrar, aplique la firma LDAP en sus controladores de dominio configurando la política de grupo como se describe aquí. Además de... bueno, tener las comunicaciones firmadas, lo que evitará una variedad de ataques de retransmisión Kerberos y NTLM, los controladores de dominio también rechazarán un enlace simple a través de una conexión LDAP sin cifrar.
Si desea estar completamente seguro de que no está interrumpiendo nada, observe los registros de eventos de sus DC, tal y como se describe en este artículo permanente de Learn sobre la firma LDAP, la vinculación de canales y LDAPS.
Si tiene aplicaciones que requieren un enlace simple, obligue a esas aplicaciones a utilizar el puerto 636/3269 configurando este comportamiento (y la confianza en los certificados LDAPS) dentro de las propias aplicaciones.
[Nota del editor: este blog es una adaptación de la publicación original del autor].
