Bloqueo de la conexión UDP al puerto 389 a través del cortafuegos
Descripción general
LDAP (Lightweight Directory Access Protocol) es el protocolo de capa de aplicación que está detrás de Active Directory. Normalmente funciona sobre TCP, pero también tiene una variante sin conexión — CLDAP (Connectionless LDAP) — que funciona sobre UDP en el puerto 389. Los clientes de Windows utilizan CLDAP para localizar controladores de dominio (el «ping LDAP» que realiza el servicio Localizador de DC). Las versiones modernas de Windows a menudo pueden recurrir al descubrimiento basado en DNS y a LDAP sobre TCP en muchos escenarios, pero CLDAP sobre UDP 389 todavía se utiliza para las operaciones del Localizador de DC y la unión al dominio.
El problema de seguridad es el abuso por reflexión (amplificación). Un atacante envía una pequeña solicitud CLDAP falsificada al puerto UDP 389 de un servidor, falsificando la IP de origen para que parezca que la solicitud proviene de la víctima. El servidor envía entonces una respuesta mucho mayor a la dirección de la víctima. Multiplicado a través de muchos servidores expuestos, esto inunda a la víctima con tráfico. En el pasado se han observado factores de amplificación superiores a 50×, dependiendo del tamaño de la respuesta LDAP, razón por la cual los servidores expuestos se utilizan como reflectores.
El objetivo de esta guía es evitar que su servidor actúe como tal reflector — sin interrumpir las funciones legítimas de Active Directory.
Paso 1: Determinar si su servidor es un controlador de dominio
Este es el paso más importante, porque decide qué debe bloquear (si es que debe bloquear algo).
En una instalación estándar de Windows Server, el puerto UDP 389 normalmente solo lo utilizan los Servicios de dominio de Active Directory después de que el servidor se haya promovido a controlador de dominio. Un Windows Server normal (servidor web, de aplicaciones, de archivos, etc.) no escucha en UDP 389 de forma predeterminada, por lo que no puede ser utilizado como reflector CLDAP a menos que otra aplicación (como AD LDS o un servicio LDAP de terceros) proporcione un servicio CLDAP en ese puerto.
Abra PowerShell como administrador y compruebe la función real del servidor en el dominio:
(Get-CimInstance Win32_ComputerSystem).DomainRole
Interpretación del resultado:
- 0 — Estación de trabajo independiente (Standalone Workstation)
- 1 — Estación de trabajo miembro (Member Workstation)
- 2 — Servidor independiente (Standalone Server)
- 3 — Servidor miembro (Member Server)
- 4 — Controlador de dominio (notificado como «Backup Domain Controller» por compatibilidad histórica — todos los controladores de dominio modernos de Active Directory devuelven este valor)
- 5 — Controlador de dominio que posee la función FSMO de emulador PDC (notificado como «Primary Domain Controller» por compatibilidad histórica)
Si el resultado no es 4 ni 5, el servidor no es un controlador de dominio.
También puede confirmar si algo está realmente escuchando en UDP 389:
Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue
Si este comando no devuelve nada, Windows no está escuchando en el puerto UDP 389, por lo que el servidor no proporciona servicios CLDAP y no está expuesto a este ataque.
Si su servidor NO es un controlador de dominio
Nada está escuchando en UDP 389, por lo que el servidor no puede ser utilizado como reflector LDAP. No se requiere ningún cambio en el cortafuegos para esta amenaza específica.
Si desea documentar su política de seguridad o aplicar una regla de denegación explícita, aún puede crear la regla de cortafuegos que se indica a continuación. Dado que ningún servicio está escuchando en el puerto UDP 389, la regla no tiene ningún efecto práctico.
Si su servidor SÍ es un controlador de dominio
Un controlador de dominio realmente escucha en UDP 389 y puede ser utilizado como reflector — pero UDP 389 también es esencial para el funcionamiento normal del dominio.
Advertencia: No bloquee a ciegas todo el tráfico UDP 389 entrante en un controlador de dominio. Los clientes unidos al dominio utilizan CLDAP (UDP 389) para encontrar un controlador de dominio, y el mismo puerto es necesario para la unión al dominio. Un bloqueo general puede impedir que los clientes localicen el controlador de dominio e interrumpir las operaciones de inicio de sesión y de unión al dominio.
El enfoque correcto en un controlador de dominio:
Lo ideal es que un controlador de dominio no sea accesible desde Internet en absoluto. El abuso por reflexión proviene del exterior, por lo que la solución más limpia es mantener el DC detrás de un cortafuegos perimetral y no exponer UDP 389 públicamente.
Si el servidor debe estar expuesto, no bloquee UDP 389 de forma global. En su lugar, bloquéelo únicamente desde rangos de IP externos/no confiables, dejando sus subredes de dominio internas fuera del bloqueo. Esto detiene las solicitudes externas falsificadas (que causan la reflexión) mientras mantiene a los clientes internos funcionando. Esto se hace con la configuración de Ámbito (Scope) de la regla, que se describe a continuación.
El mismo principio de ámbito se aplica a los controladores de dominio de solo lectura (RODC).
Crear la regla del cortafuegos (bloquear el tráfico UDP 389 entrante)
Abra el Firewall de Windows y seleccione Configuración avanzada en el menú de la izquierda:
Seleccione Reglas de entrada en el menú lateral izquierdo:
Haga clic en Acción → Nueva regla... en el menú superior:
Se abrirá el asistente de creación de reglas. Seleccione el tipo de regla Puerto y haga clic en Siguiente >:
En la página siguiente, seleccione UDP, luego en Puertos locales específicos escriba 389 y haga clic en Siguiente >:
En la página siguiente, seleccione Bloquear la conexión y haga clic en Siguiente >:
Por último, asigne un nombre a la regla, por ejemplo UDP LDAP block, y haga clic en Finalizar:
La misma regla se puede crear desde PowerShell, lo cual es conveniente para la creación de scripts o para aplicarla a varios servidores:
New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block
Advertencia: En un controlador de dominio, no se detenga aquí. La regla anterior bloquea UDP 389 desde todas las fuentes, lo que interrumpirá la localización del controlador de dominio para los clientes internos. Debe delimitar su ámbito (paso siguiente).
Delimitar el ámbito de la regla (necesario en un controlador de dominio)
Una vez creada la regla, abra sus Propiedades y vaya a la pestaña Ámbito (Scope). En Dirección IP remota, seleccione Estas direcciones IP y añada los rangos externos o no confiables que desea bloquear. No añada aquí sus subredes de dominio internas — cualquier rango incluido en «Dirección IP remota» es un rango que la regla bloqueará, por lo que incluir subredes internas bloquearía a sus propios clientes. Deje Dirección IP local en Cualquier dirección IP.
De esta manera, el bloqueo se aplica únicamente a las fuentes externas no confiables que especifique, mientras que los clientes internos (no incluidos) permanecen sin verse afectados.
En PowerShell, el mismo ámbito se puede aplicar con la palabra clave integrada Internet. La palabra clave Internet coincide con las direcciones remotas que el Firewall de Windows clasifica como externas, excluyendo el equipo local, el bucle invertido (loopback) y los rangos de red local comunes. Esto bloquea el tráfico externo y deja a los clientes internos sin verse afectados:
New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private
En un controlador de dominio correctamente configurado, el perfil de cortafuegos activo es normalmente Dominio. Limitar la regla a los perfiles Público y Privado evita que afecte al tráfico normal del dominio. En un controlador de dominio, sigue siendo más seguro definir explícitamente sus subredes internas en el Ámbito de la regla en lugar de depender únicamente de la palabra clave Internet — si su red utiliza rangos privados no estándar, pueden clasificarse erróneamente; en ese caso, enumere sus rangos internos manualmente y bloquee todo lo demás.
Verificar el resultado
Advertencia: No utilice Test-NetConnection para verificar UDP 389 — solo prueba conexiones TCP y dará resultados engañosos para UDP.
La forma más directa de confirmar si un servidor todavía responde a las solicitudes CLDAP es enviar un ping LDAP adecuado desde un cliente unido al dominio:
nltest /ping /server:DC_NAME
Esto envía una solicitud CLDAP correctamente formada e informa de la respuesta. Reemplace DC_NAME por el nombre de su controlador de dominio.
Como comprobación secundaria, puede utilizar PortQry (una herramienta gratuita de línea de comandos de Microsoft) desde otro equipo:
portqry -n SERVER_NAME -p UDP -e 389
Según la respuesta, PortQry puede informar de LISTENING o FILTERED. Tenga en cuenta que PortQry envía un paquete de sondeo en lugar de un ping LDAP CLDAP completo, y el servicio CLDAP puede no reconocerlo como una solicitud válida, por lo que puede informar de FILTERED incluso cuando el puerto está abierto. Por esta razón, considere nltest /ping como la prueba autorizada y PortQry como una comprobación complementaria aproximada.
En un controlador de dominio, confirme también que la localización del dominio todavía funciona para los clientes internos:
nltest /dsgetdc:example.com
Reemplace example.com por el nombre de su dominio. Una respuesta correcta significa que los clientes todavía pueden encontrar el controlador de dominio. Tenga en cuenta que un dsgetdc correcto por sí solo no demuestra que CLDAP sobre UDP esté funcionando, porque el Localizador de DC puede recurrir a consultas DNS y LDAP sobre TCP si CLDAP no está disponible, según la operación que se realice — razón por la cual la comprobación nltest /ping anterior es la prueba más directa.
Recomendaciones adicionales
Mantenga Windows totalmente actualizado. Las actualizaciones de seguridad corrigen vulnerabilidades críticas en la propia implementación de LDAP (como fallos que podrían permitir la ejecución remota de código) y protegen al servidor de verse comprometido. Esto es una preocupación independiente del abuso por reflexión — la aplicación de parches refuerza el propio servidor, mientras que la delimitación del ámbito del cortafuegos anterior evita que el servidor sea utilizado como reflector contra otros.
Habilite la firma LDAP y el enlace de canal en los controladores de dominio para reforzar LDAP en general.
Para la protección volumétrica, la limitación de velocidad y el filtrado de DDoS corresponden al cortafuegos perimetral o al proveedor ascendente (upstream), no al propio host de Windows.
Resumen: ¿cuándo es apropiado bloquear UDP 389?
- El servidor no es un controlador de dominio → no se requiere ninguna acción (UDP 389 no está escuchando).
- Controlador de dominio detrás de un cortafuegos, no expuesto a Internet → no se requiere ninguna acción; manténgalo fuera de la Internet pública.
- Controlador de dominio expuesto a Internet → delimite el ámbito de la regla para que bloquee las fuentes externas mientras deja sin afectar las subredes internas de confianza.
