Blocking the UDP connection to port 389 through the firewall

Overview

LDAP (Lightweight Directory Access Protocol) is the application-layer protocol behind Active Directory. It normally works over TCP, but it also has a connectionless variant — CLDAP (Connectionless LDAP) — that works over UDP on port 389. Windows clients use CLDAP to locate domain controllers (the "LDAP ping" performed by the DC Locator service). Modern versions of Windows can often fall back to DNS-based discovery and TCP LDAP in many scenarios, but CLDAP over UDP 389 is still used for DC Locator operations and domain join.

The security problem is reflection (amplification) abuse. An attacker sends a small, spoofed CLDAP request to a server's UDP port 389, forging the source IP so it looks like the request came from the victim. The server then sends a much larger response to the victim's address. Multiplied across many exposed servers, this floods the victim with traffic. Amplification factors exceeding 50× have been observed in the past, depending on the LDAP response size, which is why exposed servers get used as reflectors.

The goal of this guide is to stop your server from acting as such a reflector — without breaking legitimate Active Directory functions.

Step 1: Determine whether your server is a Domain Controller

This is the most important step, because it decides what (if anything) you should block.

In a standard Windows Server installation, UDP port 389 is normally used only by Active Directory Domain Services after the server has been promoted to a domain controller. A regular Windows Server (web, application, file server, etc.) does not listen on UDP 389 by default, so it cannot be abused as a CLDAP reflector unless another application (such as AD LDS or a third-party LDAP service) provides a CLDAP service on that port.

Open PowerShell as Administrator and check the server's actual role in the domain:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interpreting the result:

• 0 — Standalone Workstation
• 1 — Member Workstation
• 2 — Standalone Server
• 3 — Member Server
• 4 — Domain Controller (reported as "Backup Domain Controller" for historical compatibility — all modern Active Directory domain controllers return this)
• 5 — Domain Controller holding the PDC Emulator FSMO role (reported as "Primary Domain Controller" for historical compatibility)

If the result is not 4 or 5, the server is not a domain controller.

You can also confirm whether anything is actually listening on UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

If this command returns nothing, Windows is not listening on UDP port 389, so the server is not providing CLDAP services and is not exposed to this attack.

If your server is NOT a domain controller

Nothing is listening on UDP 389, so the server cannot be abused as an LDAP reflector. No firewall change is required for this specific threat.

If you want to document your security policy or enforce an explicit deny rule, you may still create the firewall rule below. Since no service is listening on UDP port 389, the rule has no practical effect.

If your server IS a domain controller

A domain controller genuinely listens on UDP 389 and can be abused as a reflector — but UDP 389 is also essential for normal domain operation.

Warning: Do not blindly block all inbound UDP 389 on a domain controller. Domain-joined clients use CLDAP (UDP 389) to find a domain controller, and the same port is required for domain join. A blanket block can prevent clients from locating the domain controller and break logon and domain-join operations.

The correct approach on a domain controller:

Ideally, a domain controller should not be reachable from the internet at all. Reflection abuse comes from outside, so the cleanest fix is to keep the DC behind a perimeter firewall and not expose UDP 389 publicly.

If the server must be exposed, do not block UDP 389 globally. Instead, block it only from external/untrusted IP ranges, leaving your internal domain subnets out of the block. This stops the spoofed external requests (which cause the reflection) while keeping internal clients working. This is done with the rule's Scope settings, described below.

The same scoping principle applies to Read-Only Domain Controllers (RODCs).

Creating the firewall rule (block inbound UDP 389)

Open Windows Defender Firewall and select Advanced settings on the left side menu:

Select Inbound Rules from the left-hand side menu:

Click Action → New Rule... in the top menu:

The Rule Creation Wizard opens. Select the rule type Port and click Next >:

On the next page, select UDP, then under Specific local ports type 389 and click Next >:

On the next page, select Block the connection and click Next >:

Finally, give the rule a name, for example UDP LDAP block, and click Finish:

The same rule can be created from PowerShell, which is convenient for scripting or applying it to multiple servers:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP)" -Direction Inbound -Protocol UDP -LocalPort 389 -Action Block

Warning: On a domain controller, do not stop here. The rule above blocks UDP 389 from all sources, which will break domain controller location for internal clients. You must scope it (next step).

Scope the rule (required on a domain controller)

After the rule is created, open its Properties and go to the Scope tab. Under Remote IP address, select These IP addresses and add the external or untrusted ranges you want to block. Do not add your internal domain subnets here — any range listed under Remote IP address is a range the rule will block, so listing internal subnets would block your own clients. Leave Local IP address set to Any IP address.

This way the block applies only to the untrusted external sources you specify, while internal clients (not listed) remain unaffected.

In PowerShell, the same scoping can be applied with the built-in Internet keyword. The Internet keyword matches remote addresses that Windows Firewall classifies as external, excluding the local computer, loopback, and common local network ranges. This blocks external traffic while leaving internal clients unaffected:

New-NetFirewallRule -DisplayName "Block inbound UDP 389 (CLDAP) from Internet" -Direction Inbound -Protocol UDP -LocalPort 389 -RemoteAddress Internet -Action Block -Profile Public,Private

On a correctly configured domain controller, the active firewall profile is normally Domain. Limiting the rule to the Public and Private profiles prevents it from affecting normal domain traffic. On a domain controller it is still safest to define your internal subnets explicitly in the rule's Scope rather than relying only on the Internet keyword — if your network uses non-standard private ranges, they may be misclassified, in which case list your internal ranges manually and block everything else.

Verify the result

Warning: Do not use Test-NetConnection to verify UDP 389 — it only tests TCP connections and will give misleading results for UDP.

The most direct way to confirm whether a server still answers CLDAP requests is to send a proper LDAP ping from a domain-joined client:

nltest /ping /server:DC_NAME

This sends a correctly formed CLDAP request and reports the response. Replace DC_NAME with your domain controller's name.

As a secondary check, you can use PortQry (a free Microsoft command-line tool) from another machine:

portqry -n SERVER_NAME -p UDP -e 389

Depending on the response, PortQry may report LISTENING or FILTERED. Note that PortQry sends a probe packet rather than a complete CLDAP LDAP ping, and the CLDAP service may not recognize it as a valid request, so it can report FILTERED even when the port is open. For this reason, treat nltest /ping as the authoritative test and PortQry as a rough supplementary check.

On a domain controller, also confirm that domain location still works for internal clients:

nltest /dsgetdc:example.com

Replace example.com with your domain name. A successful response means clients can still find the domain controller. Keep in mind that a successful dsgetdc alone does not prove CLDAP over UDP is working, because DC Locator can fall back to DNS queries and TCP LDAP if CLDAP is unavailable, depending on the operation being performed — which is why the nltest /ping check above is the more direct test.

Additional recommendations

Keep Windows fully updated. Security updates address critical vulnerabilities in the LDAP implementation itself (such as flaws that could allow remote code execution) and protect the server from being compromised. This is a separate concern from reflection abuse — patching hardens the server itself, while the firewall scoping above prevents the server from being used as a reflector against others.

Enable LDAP signing and channel binding on domain controllers to harden LDAP overall.

For volumetric protection, rate limiting and DDoS filtering belong on the perimeter firewall or upstream provider, not on the Windows host itself.

Summary: when is blocking UDP 389 appropriate?

• Server is not a domain controller → no action needed (UDP 389 is not listening).
• Domain controller behind a firewall, not exposed to the internet → no action needed; keep it off the public internet.
• Internet-exposed domain controller → scope the rule so it blocks external sources while leaving trusted internal subnets unaffected.