Blockieren der UDP-Verbindung zu Port 389 durch die Firewall

Überblick

LDAP (Lightweight Directory Access Protocol) ist das Protokoll der Anwendungsschicht hinter Active Directory. Normalerweise arbeitet es über TCP, es gibt jedoch auch eine verbindungslose Variante — CLDAP (Connectionless LDAP) — die über UDP auf Port 389 arbeitet. Windows-Clients verwenden CLDAP, um Domänencontroller zu finden (der „LDAP-Ping“ des DC-Locator-Dienstes). Moderne Windows-Versionen können in vielen Szenarien auf DNS-basierte Erkennung und TCP-LDAP zurückgreifen, aber CLDAP über UDP 389 wird weiterhin für DC-Locator-Vorgänge und den Domänenbeitritt verwendet.

Das Sicherheitsproblem ist der Reflection- (Amplification-) Missbrauch. Ein Angreifer sendet eine kleine, gefälschte CLDAP-Anfrage an UDP-Port 389 eines Servers und fälscht die Quell-IP so, dass es aussieht, als käme die Anfrage vom Opfer. Der Server sendet dann eine viel größere Antwort an die Adresse des Opfers. Über viele exponierte Server multipliziert, überflutet dies das Opfer mit Datenverkehr. In der Vergangenheit wurden Verstärkungsfaktoren von über 50× beobachtet, abhängig von der Größe der LDAP-Antwort — weshalb exponierte Server als Reflektoren missbraucht werden.

Das Ziel dieser Anleitung ist es, zu verhindern, dass Ihr Server als ein solcher Reflektor agiert — ohne legitime Active-Directory-Funktionen zu beeinträchtigen.

Schritt 1: Feststellen, ob Ihr Server ein Domänencontroller ist

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

Bei einer Standard-Windows-Server-Installation wird UDP-Port 389 normalerweise nur von Active Directory-Domänendiensten verwendet, nachdem der Server zu einem Domänencontroller heraufgestuft wurde. Ein normaler Windows Server (Web-, Anwendungs-, Dateiserver usw.) lauscht standardmäßig nicht auf UDP 389 und kann daher nicht als CLDAP-Reflektor missbraucht werden, 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 Arbeitsstation (Standalone Workstation)
• 1 — Mitglieds-Arbeitsstation (Member Workstation)
• 2 — Eigenständiger Server (Standalone Server)
• 3 — Mitgliedsserver (Member Server)
• 4 — Domänencontroller (aus historischen Kompatibilitätsgründen als „Backup Domain Controller“ gemeldet — alle modernen Active-Directory-Domänencontroller geben diesen Wert zurück)
• 5 — Domänencontroller mit der PDC-Emulator-FSMO-Rolle (aus historischen Kompatibilitätsgründen als „Primary Domain Controller“ gemeldet)

Wenn das Ergebnis nicht 4 oder 5 ist, ist der Server kein Domänencontroller.

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

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Wenn dieser Befehl nichts zurückgibt, lauscht Windows nicht auf UDP-Port 389, der Server stellt also keine CLDAP-Dienste bereit und ist diesem Angriff nicht ausgesetzt.

Wenn Ihr Server KEIN Domänencontroller ist

Es lauscht nichts auf UDP 389, der Server kann also nicht als LDAP-Reflektor missbraucht werden. Für diese spezielle Bedrohung ist keine Firewall-Änderung erforderlich.

Wenn Sie Ihre Sicherheitsrichtlinie dokumentieren oder eine explizite Verweigerungsregel erzwingen möchten, können Sie die unten stehende Firewall-Regel dennoch erstellen. Da kein Dienst auf UDP-Port 389 lauscht, hat die Regel keine praktische Wirkung.

Wenn Ihr Server EIN Domänencontroller ist

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

Warnung: Blockieren Sie auf einem Domänencontroller nicht blind den gesamten eingehenden UDP-389-Verkehr. In die Domäne eingebundene Clients verwenden CLDAP (UDP 389), um einen Domänencontroller zu finden, und derselbe Port wird für den Domänenbeitritt benötigt. Eine pauschale Blockierung kann verhindern, dass Clients den Domänencontroller finden, und die Anmeldung sowie den Domänenbeitritt beeinträchtigen.

Der richtige Ansatz auf einem Domänencontroller:

Idealerweise sollte ein Domänencontroller überhaupt nicht aus dem Internet erreichbar sein. Reflection-Missbrauch kommt von außen, daher besteht die sauberste Lösung darin, den DC hinter einer Perimeter-Firewall zu halten und UDP 389 nicht öffentlich verfügbar zu machen.

Wenn der Server exponiert sein muss, blockieren Sie UDP 389 nicht global. Blockieren Sie ihn stattdessen nur von externen/nicht vertrauenswürdigen IP-Bereichen und lassen Sie Ihre internen Domänen-Subnetze von der Blockierung ausgenommen. Dies stoppt die gefälschten externen Anfragen (die die Reflection verursachen), während interne Clients weiterhin funktionieren. Dies geschieht über die Bereich-Einstellungen (Scope) der Regel, die unten beschrieben werden.

Dasselbe Bereichsprinzip gilt für schreibgeschützte Domänencontroller (RODCs).

Erstellen der Firewall-Regel (eingehenden UDP-389-Verkehr blockieren)

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

Wählen Sie Eingehende Regeln aus dem Menü auf der linken Seite:

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

Der Regelerstellungsassistent öffnet sich. Wählen Sie den Regeltyp Port und klicken Sie auf Weiter >:

Wählen Sie auf der nächsten Seite UDP, geben Sie dann unter Spezifische lokale Ports 389 ein und klicken Sie auf Weiter >:

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

Geben Sie zum Schluss einen Namen für die Regel an, zum Beispiel UDP LDAP block, und klicken Sie auf Fertig stellen:

Dieselbe Regel kann über PowerShell erstellt werden, was für Skripting oder die Anwendung auf mehrere Server praktisch ist:

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

Warnung: Hören Sie auf einem Domänencontroller hier nicht auf. Die obige Regel blockiert UDP 389 von allen Quellen, was die Auffindung des Domänencontrollers für interne Clients unterbricht. Sie müssen den Bereich einschränken (nächster Schritt).

Den Bereich der Regel einschränken (auf einem Domänencontroller erforderlich)

Öffnen Sie nach dem Erstellen der Regel deren Eigenschaften und wechseln Sie zur Registerkarte Bereich (Scope). Wählen Sie unter Remote-IP-Adresse die Option Diese IP-Adressen und fügen Sie die externen oder nicht vertrauenswürdigen Bereiche hinzu, die Sie blockieren möchten. Fügen Sie hier nicht Ihre internen Domänen-Subnetze hinzu — jeder unter „Remote-IP-Adresse“ aufgeführte Bereich ist ein Bereich, den die Regel blockiert, sodass das Auflisten interner Subnetze Ihre eigenen Clients blockieren würde. Belassen Sie Lokale IP-Adresse auf Beliebige IP-Adresse.

Auf diese Weise gilt die Blockierung nur für die nicht vertrauenswürdigen externen Quellen, die Sie angeben, während interne Clients (nicht aufgeführt) unbeeinträchtigt bleiben.

In PowerShell kann derselbe Bereich mit dem integrierten Schlüsselwort Internet angewendet werden. Das Schlüsselwort „Internet“ erfasst Remote-Adressen, die die Windows-Firewall als extern einstuft, mit Ausnahme des lokalen Computers, des Loopbacks und gängiger lokaler Netzwerkbereiche. Dies blockiert externen Datenverkehr und lässt interne Clients unbeeinträchtigt:

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. Die Beschränkung der Regel auf die Profile „Öffentlich“ und „Privat“ verhindert, dass sie den normalen Domänenverkehr beeinträchtigt. Auf einem Domänencontroller ist es dennoch am sichersten, Ihre internen Subnetze explizit im Bereich der Regel zu definieren, anstatt sich nur auf das Schlüsselwort „Internet“ zu verlassen — wenn Ihr Netzwerk nicht standardmäßige private Bereiche verwendet, könnten diese falsch klassifiziert werden; listen Sie in diesem Fall Ihre internen Bereiche manuell auf und blockieren Sie alles andere.

Das Ergebnis überprüfen

Warnung: Verwenden Sie nicht Test-NetConnection, um UDP 389 zu überprüfen — es testet nur TCP-Verbindungen und liefert für UDP irreführende Ergebnisse.

Der direkteste Weg, um zu bestätigen, ob ein Server noch auf CLDAP-Anfragen antwortet, besteht darin, einen ordnungsgemäßen LDAP-Ping von einem in die Domäne eingebundenen Client zu senden:

nltest /ping /server:DC_NAME

Dies sendet eine korrekt formulierte CLDAP-Anfrage und meldet die Antwort. Ersetzen Sie DC_NAME durch den Namen Ihres Domänencontrollers.

Als sekundäre Prüfung können Sie PortQry (ein kostenloses Microsoft-Befehlszeilentool) von einem anderen Computer 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 es 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 den maßgeblichen Test und PortQry als grobe ergänzende Prüfung.

Bestätigen Sie auf einem Domänencontroller außerdem, dass die Domänensuche 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 erfolgreiches dsgetdc allein nicht beweist, dass CLDAP über UDP funktioniert, da der DC-Locator je nach Vorgang auf DNS-Abfragen und TCP-LDAP zurückgreifen kann, wenn CLDAP nicht verfügbar ist — weshalb die obige Prüfung nltest /ping der direktere Test ist.

Zusätzliche Empfehlungen

Halten Sie Windows vollständig aktuell. Sicherheitsupdates beheben kritische Schwachstellen in der LDAP-Implementierung selbst (wie Fehler, die eine Remotecodeausführung ermöglichen könnten) und schützen den Server vor einer Kompromittierung. Dies ist ein separates Anliegen vom Reflection-Missbrauch — das Patchen härtet den Server selbst ab, während die obige Firewall-Bereichseinschränkung verhindert, dass der Server als Reflektor gegen andere verwendet wird.

Aktivieren Sie die LDAP-Signierung und die Kanalbindung auf Domänencontrollern, um LDAP insgesamt zu härten.

Für den Schutz vor volumetrischen Angriffen gehören Ratenbegrenzung und DDoS-Filterung auf die Perimeter-Firewall oder zum Upstream-Anbieter, nicht auf den Windows-Host selbst.

Zusammenfassung: Wann ist das Blockieren von UDP 389 sinnvoll?

• Server ist kein Domänencontroller → keine Maßnahme erforderlich (UDP 389 lauscht nicht).
• Domänencontroller hinter einer Firewall, nicht aus dem Internet erreichbar → keine Maßnahme erforderlich; halten Sie ihn vom öffentlichen Internet fern.
• Aus dem Internet erreichbarer Domänencontroller → schränken Sie den Bereich der Regel so ein, dass sie externe Quellen blockiert, während vertrauenswürdige interne Subnetze unbeeinträchtigt bleiben.