Bloquear la conexión UDP al puerto 389 a través del cortafuegos
Esta guía explica cómo proteger un servidor Windows Server contra los ataques DDoS de reflexión/amplificación LDAP (CLDAP) a través del puerto UDP 389, y cómo hacerlo de forma segura en función de la función del servidor.
Descripción general
LDAP (Lightweight Directory Access Protocol) es el protocolo de capa de aplicación en el que se basa Active Directory. Normalmente funciona a través de TCP, pero también cuenta con una variante sin conexión —CLDAP (Connectionless LDAP)— que funciona a través de UDP en el puerto 389. Los clientes de Windows utilizan CLDAP para localizar controladores de dominio (el «ping LDAP» que realiza el servicio DC Locator). Las versiones modernas de Windows suelen recurrir al descubrimiento basado en DNS y al LDAP sobre TCP en muchos casos, pero el CLDAP sobre el puerto UDP 389 sigue utilizándose para las operaciones del DC Locator y la incorporación al dominio.
El problema de seguridad es el abuso de la 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 procede de la víctima. A continuación, el servidor envía una respuesta mucho mayor a la dirección de la víctima. Al multiplicarse por los numerosos 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 afectar al funcionamiento legítimo de Active Directory.
Paso 1: Determina si tu servidor es un controlador de dominio
Este es el paso más importante, ya que determina qué (si es que hay algo) debe bloquear.
En una instalación estándar de Windows Server, el puerto UDP 389 normalmente solo lo utilizan los Servicios de dominio de Active Directory una vez que el servidor ha sido ascendido a controlador de dominio. Un servidor Windows Server normal (web, de aplicaciones, de archivos, etc.) no escucha en el puerto UDP 389 de forma predeterminada, por lo que no puede ser utilizado indebidamente 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.
Abre PowerShell como administrador y comprueba la función real del servidor en el dominio:
(Get-CimInstance Win32_ComputerSystem).DomainRole
Interpretación del resultado:
- 0 — Estación de trabajo independiente
- 1 — Estación de trabajo miembro
- 2 — Servidor independiente
- 3 — Servidor miembro
- 4 — Controlador de dominio (se indica como «Controlador de dominio de respaldo» por motivos de compatibilidad histórica; todos los controladores de dominio modernos de Active Directory devuelven este valor)
- 5 — Controlador de dominio que desempeña la función FSMO de emulador de PDC (se indica como «controlador de dominio principal» por motivos de compatibilidad histórica)
Si el resultado no es 4 ni 5, el servidor no es un controlador de dominio.
También puedes comprobar si hay algún servicio escuchando en el puerto UDP 389:
Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue
Si este comando no devuelve ningún resultado, Windows no está a la escucha 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
No hay ningún servicio a la escucha en el puerto UDP 389, por lo que el servidor no puede ser utilizado indebidamente como reflector LDAP. No es necesario realizar 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, puede crear igualmente la regla de cortafuegos que se indica a continuación. Dado que ningún servicio está a la escucha en el puerto UDP 389, la regla no tiene ningún efecto práctico.
Si su servidor ES un controlador de dominio
Un controlador de dominio escucha efectivamente en el puerto UDP 389 y puede ser utilizado indebidamente como reflector, pero el puerto UDP 389 también es esencial para el funcionamiento normal del dominio.
No bloquee ciegamente todo el tráfico UDP 389 entrante en un controlador de dominio. Los clientes unidos al dominio utilizan CLDAP (UDP 389) para localizar un controlador de dominio, y se requiere el mismo puerto para la incorporación al dominio. Un bloqueo general puede impedir que los clientes localicen el controlador de dominio y afectar a las operaciones de inicio de sesión y de incorporación al dominio.
El enfoque correcto en un controlador de dominio:
Lo ideal es que no se pueda acceder al controlador de dominio desde Internet en absoluto. El uso indebido de la reflexión proviene del exterior, por lo que la solución más limpia es mantener el controlador de dominio detrás de un cortafuegos perimetral y no exponer el puerto UDP 389 públicamente.
Si es necesario exponer el servidor, no bloquees el puerto UDP 389 de forma global. En su lugar, bloquéalo solo desde rangos de IP externos o no fiables, dejando fuera del bloqueo las subredes internas del dominio. Esto detiene las solicitudes externas falsificadas (que provocan la reflexión) al tiempo que permite que los clientes internos sigan funcionando. Esto se hace mediante la configuración de «Ámbito» 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).
Creación de la regla del cortafuegos (bloquear el tráfico UDP 389 entrante)
Abre el Cortafuegos de Windows Defender y selecciona «Configuración avanzada» en el menú de la izquierda:
Selecciona «Reglas de entrada » en el menú de la izquierda:
Haga clic en «Acción» → «Nueva regla...» en el menú superior:
Se abrirá el Asistente para la creación de reglas. Selecciona el tipo de regla «Puerto» y haz clic en «Siguiente >»:
En la página siguiente, selecciona «UDP»; a continuación, en «Puertos locales específicos», escribe «389» y haz clic en «Siguiente >»:
En la página siguiente, selecciona «Bloquear la conexión » y haz clic en «Siguiente >»:
Por último, asigne un nombre a la regla, por ejemplo «Bloqueo UDP LDAP», y haga clic en «Finalizar»:
Esta misma regla se puede crear desde PowerShell, lo cual resulta muy práctico para crear scripts o aplicarla a varios servidores:
New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block
En un controlador de dominio, no te detengas aquí. La regla anterior bloquea el puerto UDP 389 desde todas las fuentes, lo que impedirá que los clientes internos localicen el controlador de dominio. Debes definir su ámbito de aplicación (siguiente paso).
Limitar el alcance de la regla (obligatorio en un controlador de dominio)
Una vez creada la regla, abre sus «Propiedades» y ve a la pestaña «Ámbito ». En «Dirección IP remota», selecciona «Estas direcciones IP » y añade los rangos externos o no fiables que desees bloquear. No añadas aquí las subredes de tu dominio interno: cualquier rango que figure en «Dirección IP remota» es un rango que la regla bloqueará, por lo que incluir subredes internas bloquearía a tus propios clientes. Deja la opción «Dirección IP local » configurada en «Cualquier dirección IP».
De este modo, el bloqueo se aplica únicamente a las fuentes externas no fiables que especifiques, mientras que los clientes internos (que no figuran en la lista) no se ven afectados.
En PowerShell, se puede aplicar el mismo ámbito de aplicación con la palabra clave integrada «Internet ». La palabra clave «Internet» coincide con las direcciones remotas que el cortafuegos de Windows clasifica como externas, excluyendo el equipo local, el bucle de retorno y los rangos habituales de la red local. Esto bloquea el tráfico externo sin afectar a los clientes internos:
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 suele ser «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 las subredes internas de forma explícita en el ámbito de la regla, en lugar de confiar únicamente en la palabra clave «Internet»: si tu red utiliza rangos privados no estándar, estos podrían clasificarse erróneamente; en tal caso, enumera tus rangos internos manualmente y bloquea todo lo demás.
Comprueba el resultado
No utilices Test-NetConnection para verificar el UDP 389: solo comprueba las conexiones TCP y dará resultados engañosos para el UDP.
La forma más directa de confirmar si un servidor sigue respondiendo 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. Sustituye DC_NAME por el nombre de tu 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
Dependiendo de la respuesta, PortQry puede indicar «LISTENING» o «FILTERED». Ten en cuenta que PortQry envía un paquete de sondeo en lugar de un ping CLDAP LDAP completo, y es posible que el servicio CLDAP no lo reconozca como una solicitud válida, por lo que puede indicar «FILTERED» incluso cuando el puerto esté abierto. Por este motivo, considera «nltest /ping» como la prueba definitiva y PortQry como una comprobación complementaria aproximada.
En un controlador de dominio, comprueba también que la ubicación del dominio sigue funcionando para los clientes internos:
nltest /dsgetdc:example.com
Sustituye example.com por tu nombre de dominio. Una respuesta satisfactoria significa que los clientes aún pueden encontrar el controlador de dominio. Tenga en cuenta que un comando «dsgetdc» con resultado satisfactorio por sí solo no demuestra que CLDAP sobre UDP esté funcionando, ya que el localizador de controladores de dominio (DC Locator) puede recurrir a consultas DNS y a LDAP sobre TCP si CLDAP no está disponible, dependiendo de la operación que se esté realizando; por eso, la comprobación con «nltest /ping» descrita anteriormente es la prueba más directa.
Recomendaciones adicionales
Mantén 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 para que no sea comprometido. Se trata de una cuestión distinta del abuso de la reflexión: la aplicación de parches refuerza la seguridad del propio servidor, mientras que la configuración del ámbito del cortafuegos mencionada anteriormente evita que el servidor se utilice como reflector contra otros.
Habilita la firma LDAP y el enlace de canal en los controladores de dominio para reforzar la seguridad general de LDAP.
Para la protección volumétrica, la limitación de tasa y el filtrado de DDoS deben realizarse en el cortafuegos perimetral o en el proveedor de acceso, no en el propio host de Windows.
Resumen: ¿cuándo es adecuado bloquear el puerto UDP 389?
- El servidor no es un controlador de dominio → no es necesario tomar ninguna medida (el puerto UDP 389 no está a la escucha).
- Controlador de dominio detrás de un cortafuegos, no expuesto a Internet → no es necesario tomar ninguna medida; manténgalo fuera de la Internet pública.
- Controlador de dominio expuesto a Internet → delimita el alcance de la regla para que bloquee las fuentes externas sin afectar a las subredes internas de confianza.
