Mejora de la seguridad para el protocolo ligero de acceso a directorios (LDAP)

Por: Caio Ribeiro César y Márcio Morales

El Protocolo ligero de acceso a directorios (LDAP) está diseñado para proporcionar acceso a un servicio de directorio en red, a través del Protocolo de control de transmisión (TCP). Los administradores tienen control sobre cómo administrar los datos y las tecnologías LDAP involucradas en este procedimiento.

Al administrar datos, lo que viene a la mente es la metodología y la arquitectura para mantenerlo seguro. En esta publicación se describe cómo mantener LDAP seguro en Amazon Web Services, junto con información para los administradores que utilizan Microsoft Active Directory como tecnología de servicio de directorio en Amazon Web Services.

Microsoft publicó recientemente un aviso (ADV190023) sobre la guía LDAP en Active Directory para evitar la elevación de vulnerabilidades de privilegios en controladores de dominio. En respuesta a este aviso, AWS Directory Services admitirá la firma LDAP (LDAP Signing) y la firma LDAP sobre SSL/TLS (LDAPS). La firma LDAP no requiere ninguna acción de cliente para activarla. LDAPS del lado del cliente requiere configuración en AWS y AD autogestionado de los clientes.

Las aplicaciones de AWS, como Amazon WorkSpaces, utilizan AWS Managed Microsoft Active Directory (AWS Managed Microsoft AD) y AD Connector para comunicarse con AD autogestionado de los clientes para la autenticación y autorización. Estas comunicaciones utilizan el protocolo LDAP. El aviso de Microsoft describe los planes para cambiar la configuración de seguridad LDAP predeterminada en controladores de dominio AD a través de Windows Update. La nueva configuración bloqueará las conexiones de cliente LDAP a controladores de dominio que no utilicen al menos una de las dos técnicas de seguridad LDAP:

• LDAP signing. Esta técnica de seguridad utiliza una clave de sesión Kerberos para firmar digitalmente comunicaciones LDAP. La firma LDAP garantiza la integridad de los datos: los datos recibidos en el destino son exactamente los que se enviaron desde el origen.
• LDAP over SSL/TLS (LDAPS). Esta técnica utiliza SSL para negociar una clave compartida para cifrar las comunicaciones LDAP. Además de la integridad, LDAPS garantiza la confidencialidad de los datos: los datos solo son legibles por el destinatario previsto.

Por lo tanto, después de la actualización, tener integridad o confidencialidad es un requisito previo para la comunicación LDAP y, en el futuro, la seguridad de los servidores de directorio de Microsoft se mejorará configurando el servidor para rechazar la comunicación LDAP no segura. Dado que AWS Managed AD y AD Connector admiten la integridad de los datos de forma predeterminada, los enlaces LDAP realizados con Simple Authentication y SASL solicitarán la firma (validación de integridad).

¿Qué es la integridad de los datos y cómo se aplica a LDAP? Es la fiabilidad de los datos a lo largo de su ciclo de vida. Con los controles de integridad de datos establecidos, los ataques del segmento intermedio son más difíciles de realizar. Para la firma LDAP, el token de sesión Kerberos ayudará a los administradores a evitar la violación de seguridad de las sesiones LDAP.

¿Qué es la confidencialidad de los datos y cómo se aplica a LDAP? Es la protección de los datos que contra el acceso no autorizado mediante cifrado. Aunque se detecten las sesiones, la información contenida en las comunicaciones que utilizan LDAPS (LDAP sobre SSL) no se puede leer ni modificar. Para esta protección, Active Directory utiliza claves criptográficas y certificados emitidos por un certificado de autoridad interno.

Los clientes que utilicen controladores de dominio de Amazon EC2 (o incluso locales) deben tener en cuenta este requisito y realizar todos los pasos necesarios descritos en los dos siguientes enlaces: 1) Habilitar firma LDAP en Windows Server y 2) Habilitar registro LdapEnforceChannelBinding para hacer la autenticación LDAP sobre SSL/TLS más segura.  Para estos clientes, para comprobar que las aplicaciones del lado del cliente utilizan enlaces LDAP sin firmar:

a. Filtrar eventos 2886 en los registros de «Directory Server» para comprobar si hay enlaces LDAP sin implementaciones de seguridad (enlaces simples [simple bind]; sin integridad o confidencialidad).

b. Filtre eventos 2887 en los registros de “Directory Server” para verificar el número de enlaces LDAP sin implementaciones de seguridad realizadas en un período de 24 horas.

c. Si recibe el evento 2888, esto significa que el servidor de directorios está configurado para rechazar enlaces LDAP sin firmar, pero los clientes siguen intentando enlazar a través del método no seguro.

d. Para recopilar más información sobre el cliente que ejecuta enlaces LDAP inseguros (como la dirección IP), aumente la configuración de la categoría de registro de eventos «Eventos de interfaz LDAP» al nivel 2 o superior y filtre al evento 2889.

HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services\ NTDS\ Diagnostics

La metodología para localizar aplicaciones LDAP que utilizan el mecanismo de autenticación de enlace “legado” también se puede hacer en la capa de red, utilizando herramientas como WireShark. En el ejemplo siguiente, agregamos un filtro para “ldap” y expandimos el método de autenticación “BindRequest”. Como puede ver, estábamos usando un enlace simple, con la contraseña visible para cualquiera que recopile tráfico e intercepte la sesión a través de Man in the Middle (MiTM):

Filtrado para el protocolo «ldap».

A continuación, se muestra el seguimiento recopilado para la misma aplicación LDAP, cuando configuramos la firma LDAP como necesaria para la integridad, pero la aplicación sigue utilizando un enlace simple. Verificamos que BindRequest envía la contraseña en texto enriquecido y luego se descarta la comunicación:

659         2.922296              10.0.8.205            10.0.5.31              LDAP      245         bindResponse(135) strongAuthRequired (00002028: LdapErr: DSID-0C09023C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v4563)

En el siguiente ejemplo, tenemos la conexión realizada por la misma aplicación LDAP, esta vez utilizando la autenticación LDAP SASL con Kerberos y el controlador de dominio configurado para requerir firma para la comprobación de integridad:

También podemos usar “ldp.exe” para probar si es posible realizar un enlace simple o incluso con credenciales en un controlador de dominio específico:

Simple Bind siendo rechazado en el controlador de dominio con el error “a more secure authentication method is required for this server” /  ”se requiere un método de autenticación más seguro para este servidor”.

Enlace con credenciales correctas en el controlador de dominio.

Información para clientes de Amazon Web Services:

• ·       Para los servicios AWS Managed Microsoft AD (MAD) y AD Connector, la firma LDAP y los métodos LDAPS están disponibles. Para obtener más información sobre LDAPS cliente, visite nuestra documentación. No se requiere ninguna acción de cliente para habilitar la firma LDAP en estos servicios.
• ·       Para configurar LDAPS cliente, se requieren acciones de configuración en el entorno de AWS y AD autogestionado. Para obtener más información sobre cómo habilitar Secure LDAP para aplicaciones que se ejecutan en AWS con Directory Service (AWS Directory Service), consulte esta publicación.

Conclusión:

En esta publicación analizamos los mecanismos de seguridad del protocolo ligero de acceso a directorios y lo que los clientes necesitan saber acerca de Microsoft Advisory ADV190023 y cómo se aplica a los servicios de directorio de Amazon Web Services, como AD Connector, Amazon Managed Active Directory (MAD) y controladores de dominio que se ejecutan en Elastic Compute Cloud (EC2).

Para obtener más información sobre el uso de AWS Managed Microsoft AD o AD Connector, visite la documentación de AWS Directory Service. Para obtener información general y precios, consulte la página principal de AWS Directory Service. Si tiene comentarios sobre esta publicación, envíe un comentario en la sección Comentarios a continuación. Si tiene preguntas sobre la implementación o solución de problemas, inicie un nuevo hilo en el foro del servicio de directorio o póngase en contacto con AWS Support.

Sobre el autor

Caio Ribeiro César currently works as a Specialized Solutions Architect for Microsoft Technologies in the AWS Cloud. He started his career as a sysadmin and continued for over 13 years in areas such as Information Security, Identity Online and Email Platforms.

Marcio Morales is a Sr. Microsoft Specialist SA at Amazon Web Services. He works with AWS customers to provide guidance and technical assistance for Microsoft workloads on AWS.

Revisor

Daniel Bravo es Arquitecto de Soluciones en AWS.