Blockieren der UDP-Verbindung zu Port 389 über die Firewall

In diesem Leitfaden wird erläutert, wie Sie einen Windows Server vor Missbrauch durch LDAP- (CLDAP-) Reflection-/Amplification-DDoS-Angriffe über den UDP-Port 389 schützen können und wie Sie dies je nach Rolle des Servers sicher umsetzen.

Übersicht

LDAP (Lightweight Directory Access Protocol) ist das Protokoll auf Anwendungsebene, das Active Directory zugrunde liegt. Es läuft normalerweise über TCP, verfügt jedoch auch über eine verbindungslose Variante – CLDAP (Connectionless LDAP) –, die über UDP auf Port 389 funktioniert. Windows-Clients nutzen CLDAP, um Domänencontroller zu lokalisieren (der vom DC-Locator-Dienst durchgeführte „LDAP-Ping“). Moderne Windows-Versionen können in vielen Szenarien zwar oft auf DNS-basierte Erkennung und TCP-LDAP zurückgreifen, doch CLDAP über UDP 389 wird nach wie vor für DC-Locator-Vorgänge und den Beitritt zur Domäne verwendet.

Das Sicherheitsproblem ist der Missbrauch durch Reflection (Verstärkung). Ein Angreifer sendet eine kleine, gefälschte CLDAP-Anfrage an den UDP-Port 389 eines Servers und fälscht dabei die Quell-IP so, dass es aussieht, als stamme die Anfrage vom Opfer. Der Server sendet daraufhin eine viel größere Antwort an die Adresse des Opfers. Multipliziert mit vielen ungeschützten Servern führt dies zu einer Überflutung des Opfers mit Datenverkehr. In der Vergangenheit wurden je nach Größe der LDAP-Antwort Verstärkungsfaktoren von über dem 50-Fachen beobachtet, weshalb ungeschützte Server als Reflektoren missbraucht werden.

Das Ziel dieses Leitfadens ist es, zu verhindern, dass Ihr Server als solcher Reflektor fungiert – ohne dabei legitime Active-Directory-Funktionen zu beeinträchtigen.

Schritt 1: Stellen Sie fest, ob Ihr Server ein Domänencontroller ist

Dies ist der wichtigste Schritt, da er darüber entscheidet, was (falls überhaupt) Sie blockieren sollten.

Bei einer Standardinstallation von Windows Server wird der UDP-Port 389 normalerweise nur von den Active Directory-Domänendiensten genutzt, nachdem der Server zum Domänencontroller befördert wurde. Ein regulärer Windows Server (Web-, Anwendungs- oder Dateiserver usw.) hört standardmäßig nicht auf UDP 389, sodass er nicht als CLDAP-Reflektor missbraucht werden kann, es sei denn, eine andere Anwendung (wie AD LDS oder ein LDAP-Dienst eines Drittanbieters) stellt einen CLDAP-Dienst auf diesem Port bereit.

Öffnen Sie PowerShell als Administrator und überprüfen Sie die tatsächliche Rolle des Servers in der Domäne:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interpretation des Ergebnisses:

• 0 – Eigenständige Workstation
• 1 – Mitglieds-Workstation
• 2 – Eigenständiger Server
• 3 – Mitgliedsserver
• 4 – Domänencontroller (aus Gründen der Rückwärtskompatibilität als „Backup-Domänencontroller“ gemeldet – alle modernen Active Directory-Domänencontroller geben diesen Wert zurück)
• 5 – Domänencontroller mit der FSMO-Rolle „PDC-Emulator“ (aus Gründen der historischen Kompatibilität als „Primärer Domänencontroller“ gemeldet)

Wenn das Ergebnis nicht 4 oder 5 ist, handelt es sich bei dem Server nicht um einen Domänencontroller.

Sie können auch überprüfen, ob tatsächlich etwas auf UDP-Port 389 lauscht:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Wenn dieser Befehl keine Ausgabe liefert, hört Windows nicht auf dem UDP-Port 389 ab, sodass der Server keine CLDAP-Dienste bereitstellt und nicht für diesen Angriff anfällig ist.

Wenn Ihr Server KEIN Domänencontroller ist

Es läuft kein Dienst auf UDP 389, daher kann der Server nicht als LDAP-Reflektor missbraucht werden. Für diese spezifische Bedrohung sind keine Änderungen an der Firewall erforderlich.

Wenn Sie Ihre Sicherheitsrichtlinie dokumentieren oder eine explizite Ablehnungsregel durchsetzen möchten, können Sie dennoch die unten aufgeführte Firewall-Regel erstellen. Da kein Dienst auf dem UDP-Port 389 lauscht, hat die Regel keine praktischen Auswirkungen.

Wenn Ihr Server ein Domänencontroller IST

Ein Domänencontroller lauscht tatsächlich auf UDP 389 und kann als Reflektor missbraucht werden – allerdings ist UDP 389 auch für den normalen Domänenbetrieb unerlässlich.

Der richtige Ansatz auf einem Domänencontroller:

Im Idealfall sollte ein Domänencontroller vom Internet aus überhaupt nicht erreichbar sein. Der Missbrauch durch Reflection erfolgt von außen, daher besteht die sauberste Lösung darin, den DC hinter einer Perimeter-Firewall zu halten und UDP 389 nicht öffentlich zugänglich zu machen.

Falls der Server öffentlich zugänglich sein muss, blockieren Sie UDP 389 nicht global. Blockieren Sie ihn stattdessen nur aus externen/nicht vertrauenswürdigen IP-Bereichen und lassen Sie Ihre internen Domänen-Subnetze von der Blockierung aus. Dadurch werden die gefälschten externen Anfragen (die die Reflexion verursachen) gestoppt, während interne Clients weiterhin funktionieren. Dies erfolgt über die unten beschriebenen „Scope“-Einstellungen der Regel.

Das gleiche Prinzip der Bereichsfestlegung gilt für schreibgeschützte Domänencontroller (RODCs).

Erstellen der Firewall-Regel (eingehende UDP-Verbindungen auf Port 389 blockieren)

Öffnen Sie die Windows Defender-Firewall und wählen Sie im Menü auf der linken Seite „Erweiterte Einstellungen“ aus:

Wählen Sie im Menü auf der linken Seite „Eingehende Regeln “ aus:

Klicken Sie im oberen Menü auf „Aktion“ → „Neue Regel... “:

Der Assistent zum Erstellen von Regeln wird geöffnet. Wählen Sie den Regeltyp „Port“ aus und klicken Sie auf „Weiter >“:

Wählen Sie auf der nächsten Seite „UDP“ aus, geben Sie dann unter „Bestimmte lokale Ports“ die Nummer 389 ein und klicken Sie auf „Weiter >“:

Wählen Sie auf der nächsten Seite „Verbindung blockieren“ aus und klicken Sie auf „Weiter >“:

Geben Sie der Regel abschließend einen Namen, zum Beispiel „UDP-LDAP-Blockierung“, und klicken Sie auf „Fertigstellen“:

Die gleiche Regel lässt sich auch über PowerShell erstellen, was für die Skripterstellung oder die Anwendung auf mehrere Server praktisch ist:

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

Regel einschränken (auf einem Domänencontroller erforderlich)

Nachdem die Regel erstellt wurde, öffnen Sie ihre Eigenschaften und wechseln Sie zur Registerkarte „Gültigkeitsbereich “. Wählen Sie unter „Remote-IP-Adresse“ die Option „Diese IP-Adressen “ aus und fügen Sie die externen oder nicht vertrauenswürdigen Adressbereiche hinzu, die Sie blockieren möchten. Fügen Sie hier keine internen Domänen-Subnetze hinzu – jeder unter „Remote-IP-Adresse“ aufgeführte Bereich wird von der Regel blockiert, sodass die Auflistung interner Subnetze Ihre eigenen Clients blockieren würde. Lassen Sie die Einstellung für „Lokale IP-Adresse“ auf „Beliebige IP-Adresse“ gesetzt.

Auf diese Weise gilt die Sperre nur für die von Ihnen angegebenen nicht vertrauenswürdigen externen Quellen, während interne Clients (die nicht aufgeführt sind) davon unberührt bleiben.

In PowerShell lässt sich derselbe Geltungsbereich mit dem integrierten Schlüsselwort „Internet“ festlegen. Das Schlüsselwort „Internet“ passt auf Remote-Adressen, die von der Windows-Firewall als extern klassifiziert werden, wobei der lokale Computer, Loopback-Adressen und gängige lokale Netzwerkbereiche ausgeschlossen sind. Dadurch wird externer Datenverkehr blockiert, während interne Clients davon unberührt bleiben:

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

Auf einem korrekt konfigurierten Domänencontroller ist das aktive Firewall-Profil normalerweise „Domäne“. Durch die Beschränkung der Regel auf die Profile „Öffentlich“ und „Privat“ wird verhindert, dass der normale Domänenverkehr beeinträchtigt wird. Auf einem Domänencontroller ist es nach wie vor am sichersten, Ihre internen Subnetze explizit im Geltungsbereich der Regel zu definieren, anstatt sich ausschließlich auf das Schlüsselwort „Internet“ zu verlassen – wenn Ihr Netzwerk nicht standardmäßige private Adressbereiche verwendet, können diese falsch klassifiziert werden; in diesem Fall sollten Sie Ihre internen Bereiche manuell auflisten und alles andere blockieren.

Überprüfen Sie das Ergebnis

Der direkteste Weg, um zu überprüfen, ob ein Server weiterhin auf CLDAP-Anfragen antwortet, ist das Senden eines korrekten LDAP-Pings von einem Client, der der Domäne angehört:

nltest /ping /server:DC_NAME

Dadurch wird eine korrekt formatierte CLDAP-Anfrage gesendet und die Antwort ausgegeben. Ersetzen Sie „DC_NAME“ durch den Namen Ihres Domänencontrollers.

Als zusätzliche Überprüfung können Sie PortQry (ein kostenloses Microsoft-Befehlszeilentool) von einem anderen Rechner aus verwenden:

portqry -n SERVER_NAME -p UDP -e 389

Je nach Antwort meldet PortQry möglicherweise „LISTENING“ oder „FILTERED“. Beachten Sie, dass PortQry ein Testpaket anstelle eines vollständigen CLDAP-LDAP-Pings sendet und der CLDAP-Dienst dieses möglicherweise nicht als gültige Anfrage erkennt, sodass „FILTERED“ gemeldet werden kann, selbst wenn der Port offen ist. Behandeln Sie daher „nltest /ping“ als maßgeblichen Test und PortQry als grobe ergänzende Überprüfung.

Überprüfen Sie auf einem Domänencontroller außerdem, ob die Domänenlokalisierung für interne Clients weiterhin funktioniert:

nltest /dsgetdc:example.com

Ersetzen Sie „example.com“ durch Ihren Domänennamen. Eine erfolgreiche Antwort bedeutet, dass Clients den Domänencontroller weiterhin finden können. Beachten Sie, dass ein erfolgreicher „dsgetdc“-Befehl allein nicht beweist, dass CLDAP über UDP funktioniert, da der DC Locator je nach ausgeführter Operation auf DNS-Abfragen und TCP-LDAP zurückgreifen kann, wenn CLDAP nicht verfügbar ist – weshalb die oben beschriebene „nltest /ping“-Prüfung der direktere Test ist.

Weitere Empfehlungen

Halten Sie Windows stets auf dem neuesten Stand. Sicherheitsupdates beheben kritische Schwachstellen in der LDAP-Implementierung selbst (wie beispielsweise Fehler, die die Ausführung von Remote-Code ermöglichen könnten) und schützen den Server vor Kompromittierung. Dies ist ein von Reflection-Missbrauch getrenntes Problem – das Installieren von Patches härtet den Server selbst ab, während die oben beschriebene Firewall-Einschränkung verhindert, dass der Server als Reflektor gegen andere genutzt wird.

Aktivieren Sie LDAP-Signierung und Kanalbindung auf Domänencontrollern, um LDAP insgesamt abzusichern.

Zum Schutz vor volumetrischen Angriffen sollten Ratenbegrenzung und DDoS-Filterung auf der Perimeter-Firewall oder beim Upstream-Anbieter erfolgen, nicht auf dem Windows-Host selbst.

Zusammenfassung: Wann ist das Blockieren von UDP 389 angebracht?

• Der Server ist kein Domänencontroller → keine Maßnahmen erforderlich (UDP 389 ist nicht im Listen-Modus).
• Domänencontroller hinter einer Firewall, nicht dem Internet ausgesetzt → keine Maßnahmen erforderlich; halten Sie ihn vom öffentlichen Internet fern.
• Domänencontroller mit Internet-Exposition → Regel so einschränken, dass externe Quellen blockiert werden, während vertrauenswürdige interne Subnetze unberührt bleiben.