Blokowanie połączenia UDP do portu 389 przez zaporę sieciową

Przegląd

LDAP (Lightweight Directory Access Protocol) to protokół warstwy aplikacji stojący za Active Directory. Zwykle działa przez TCP, ale ma również wariant bezpołączeniowy — CLDAP (Connectionless LDAP) — który działa przez UDP na porcie 389. Klienci systemu Windows używają CLDAP do lokalizowania kontrolerów domeny („ping LDAP” wykonywany przez usługę Lokalizatora DC). Nowoczesne wersje systemu Windows mogą w wielu scenariuszach często wracać do wykrywania opartego na DNS i LDAP przez TCP, ale CLDAP przez UDP 389 jest nadal używany do operacji Lokalizatora DC oraz przyłączania do domeny.

Problemem bezpieczeństwa jest nadużycie typu odbicie (wzmocnienie). Atakujący wysyła małe, sfałszowane żądanie CLDAP na port UDP 389 serwera, fałszując źródłowy adres IP tak, aby wyglądało, że żądanie pochodzi od ofiary. Serwer wysyła wtedy znacznie większą odpowiedź na adres ofiary. Pomnożone przez wiele odsłoniętych serwerów, zalewa to ofiarę ruchem. W przeszłości obserwowano współczynniki wzmocnienia przekraczające 50×, w zależności od rozmiaru odpowiedzi LDAP — dlatego odsłonięte serwery są wykorzystywane jako reflektory.

Celem tego przewodnika jest powstrzymanie serwera przed działaniem jako taki reflektor — bez zakłócania legalnych funkcji Active Directory.

Krok 1: Ustal, czy serwer jest kontrolerem domeny

To najważniejszy krok, ponieważ decyduje o tym, co (jeśli w ogóle) należy zablokować.

W standardowej instalacji Windows Server port UDP 389 jest zwykle używany tylko przez Usługi domenowe Active Directory po podniesieniu serwera do roli kontrolera domeny. Zwykły Windows Server (serwer WWW, aplikacji, plików itp.) domyślnie nie nasłuchuje na UDP 389, więc nie może zostać wykorzystany jako reflektor CLDAP, chyba że inna aplikacja (taka jak AD LDS lub usługa LDAP innej firmy) udostępnia usługę CLDAP na tym porcie.

Otwórz PowerShell jako administrator i sprawdź rzeczywistą rolę serwera w domenie:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interpretacja wyniku:

• 0 — Samodzielna stacja robocza (Standalone Workstation)
• 1 — Stacja robocza będąca członkiem (Member Workstation)
• 2 — Samodzielny serwer (Standalone Server)
• 3 — Serwer członkowski (Member Server)
• 4 — Kontroler domeny (zgłaszany jako „Backup Domain Controller” ze względu na zgodność historyczną — wszystkie nowoczesne kontrolery domeny Active Directory zwracają tę wartość)
• 5 — Kontroler domeny pełniący rolę FSMO emulatora PDC (zgłaszany jako „Primary Domain Controller” ze względu na zgodność historyczną)

Jeśli wynik nie wynosi 4 ani 5, serwer nie jest kontrolerem domeny.

Można również sprawdzić, czy coś faktycznie nasłuchuje na UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Jeśli to polecenie nic nie zwraca, system Windows nie nasłuchuje na porcie UDP 389, więc serwer nie udostępnia usług CLDAP i nie jest narażony na ten atak.

Jeśli serwer NIE jest kontrolerem domeny

Nic nie nasłuchuje na UDP 389, więc serwer nie może zostać wykorzystany jako reflektor LDAP. Nie jest wymagana żadna zmiana w zaporze w przypadku tego konkretnego zagrożenia.

Jeśli chcesz udokumentować swoją politykę bezpieczeństwa lub wymusić jawną regułę odmowy, możesz mimo to utworzyć poniższą regułę zapory. Ponieważ żadna usługa nie nasłuchuje na porcie UDP 389, reguła nie ma praktycznego efektu.

Jeśli serwer JEST kontrolerem domeny

Kontroler domeny faktycznie nasłuchuje na UDP 389 i może zostać wykorzystany jako reflektor — ale UDP 389 jest również niezbędny do normalnego działania domeny.

Ostrzeżenie: Nie blokuj na ślepo całego ruchu przychodzącego UDP 389 na kontrolerze domeny. Klienci przyłączeni do domeny używają CLDAP (UDP 389) do znalezienia kontrolera domeny, a ten sam port jest wymagany do przyłączenia do domeny. Całkowita blokada może uniemożliwić klientom zlokalizowanie kontrolera domeny oraz zakłócić logowanie i operacje przyłączania do domeny.

Prawidłowe podejście na kontrolerze domeny:

W idealnej sytuacji kontroler domeny w ogóle nie powinien być osiągalny z Internetu. Nadużycie typu odbicie pochodzi z zewnątrz, więc najczystszym rozwiązaniem jest trzymanie DC za zaporą brzegową i nieudostępnianie UDP 389 publicznie.

Jeśli serwer musi być odsłonięty, nie blokuj UDP 389 globalnie. Zamiast tego blokuj go tylko z zewnętrznych/niezaufanych zakresów IP, pozostawiając wewnętrzne podsieci domeny poza blokadą. Powstrzymuje to sfałszowane żądania zewnętrzne (które powodują odbicie), zachowując działanie klientów wewnętrznych. Wykonuje się to za pomocą ustawień Zakresu (Scope) reguły, opisanych poniżej.

Ta sama zasada zakresu dotyczy kontrolerów domeny tylko do odczytu (RODC).

Tworzenie reguły zapory (blokowanie ruchu przychodzącego UDP 389)

Otwórz Zaporę systemu Windows i wybierz Ustawienia zaawansowane z menu po lewej stronie:

Wybierz Reguły przychodzące z menu po lewej stronie:

Kliknij Akcja → Nowa reguła... w górnym menu:

Otworzy się Kreator tworzenia reguł. Wybierz typ reguły Port i kliknij Dalej >:

Na następnej stronie wybierz UDP, następnie w sekcji Określone porty lokalne wpisz 389 i kliknij Dalej >:

Na następnej stronie wybierz Blokuj połączenie i kliknij Dalej >:

Na koniec nadaj regule nazwę, na przykład UDP LDAP block, i kliknij Zakończ:

Tę samą regułę można utworzyć z poziomu PowerShell, co jest wygodne przy tworzeniu skryptów lub stosowaniu jej na wielu serwerach:

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

Ostrzeżenie: Na kontrolerze domeny nie zatrzymuj się na tym etapie. Powyższa reguła blokuje UDP 389 ze wszystkich źródeł, co zakłóci lokalizowanie kontrolera domeny dla klientów wewnętrznych. Musisz określić jej zakres (następny krok).

Określanie zakresu reguły (wymagane na kontrolerze domeny)

Po utworzeniu reguły otwórz jej Właściwości i przejdź do karty Zakres (Scope). W sekcji Zdalny adres IP wybierz Te adresy IP i dodaj zewnętrzne lub niezaufane zakresy, które chcesz zablokować. Nie dodawaj tutaj swoich wewnętrznych podsieci domeny — każdy zakres wymieniony w sekcji „Zdalny adres IP” to zakres, który reguła zablokuje, więc wymienienie wewnętrznych podsieci zablokowałoby własnych klientów. Pozostaw Lokalny adres IP ustawiony na Dowolny adres IP.

W ten sposób blokada dotyczy tylko określonych przez Ciebie niezaufanych źródeł zewnętrznych, podczas gdy klienci wewnętrzni (niewymienieni) pozostają nienaruszeni.

W PowerShell ten sam zakres można zastosować za pomocą wbudowanego słowa kluczowego Internet. Słowo kluczowe Internet dopasowuje adresy zdalne, które Zapora systemu Windows klasyfikuje jako zewnętrzne, z wyłączeniem komputera lokalnego, pętli zwrotnej (loopback) i typowych zakresów sieci lokalnej. Blokuje to ruch zewnętrzny, pozostawiając klientów wewnętrznych nienaruszonymi:

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

Na poprawnie skonfigurowanym kontrolerze domeny aktywny profil zapory to zwykle Domena. Ograniczenie reguły do profili Publiczny i Prywatny zapobiega wpływowi na normalny ruch domenowy. Na kontrolerze domeny i tak najbezpieczniej jest jawnie zdefiniować wewnętrzne podsieci w Zakresie reguły, zamiast polegać wyłącznie na słowie kluczowym Internet — jeśli sieć używa niestandardowych zakresów prywatnych, mogą zostać błędnie sklasyfikowane; w takim przypadku wymień ręcznie swoje zakresy wewnętrzne i zablokuj wszystko inne.

Weryfikacja wyniku

Ostrzeżenie: Nie używaj Test-NetConnection do weryfikacji UDP 389 — testuje tylko połączenia TCP i da mylące wyniki dla UDP.

Najbardziej bezpośrednim sposobem potwierdzenia, czy serwer nadal odpowiada na żądania CLDAP, jest wysłanie prawidłowego pingu LDAP z klienta przyłączonego do domeny:

nltest /ping /server:DC_NAME

Wysyła to poprawnie sformułowane żądanie CLDAP i raportuje odpowiedź. Zastąp DC_NAME nazwą swojego kontrolera domeny.

Jako kontrolę dodatkową można użyć narzędzia PortQry (darmowe narzędzie wiersza poleceń firmy Microsoft) z innego komputera:

portqry -n SERVER_NAME -p UDP -e 389

W zależności od odpowiedzi PortQry może raportować LISTENING lub FILTERED. Należy pamiętać, że PortQry wysyła pakiet sondujący zamiast pełnego pingu LDAP CLDAP, a usługa CLDAP może nie rozpoznać go jako prawidłowego żądania, więc może raportować FILTERED nawet wtedy, gdy port jest otwarty. Z tego powodu traktuj nltest /ping jako miarodajny test, a PortQry jako przybliżoną kontrolę uzupełniającą.

Na kontrolerze domeny potwierdź również, że lokalizowanie domeny nadal działa dla klientów wewnętrznych:

nltest /dsgetdc:example.com

Zastąp example.com nazwą swojej domeny. Pomyślna odpowiedź oznacza, że klienci nadal mogą znaleźć kontroler domeny. Należy pamiętać, że samo pomyślne dsgetdc nie dowodzi, że CLDAP przez UDP działa, ponieważ Lokalizator DC może w zależności od wykonywanej operacji wrócić do zapytań DNS i LDAP przez TCP, jeśli CLDAP jest niedostępny — dlatego powyższa kontrola nltest /ping jest bardziej bezpośrednim testem.

Dodatkowe zalecenia

Aktualizuj system Windows na bieżąco. Aktualizacje zabezpieczeń usuwają krytyczne luki w samej implementacji LDAP (takie jak błędy umożliwiające zdalne wykonanie kodu) i chronią serwer przed naruszeniem. Jest to kwestia odrębna od nadużycia typu odbicie — instalowanie poprawek wzmacnia sam serwer, podczas gdy powyższe określenie zakresu zapory zapobiega wykorzystaniu serwera jako reflektora przeciwko innym.

Włącz podpisywanie LDAP i wiązanie kanału na kontrolerach domeny, aby ogólnie wzmocnić LDAP.

W przypadku ochrony wolumetrycznej ograniczanie szybkości i filtrowanie DDoS należą do zapory brzegowej lub dostawcy nadrzędnego (upstream), a nie do samego hosta Windows.

Podsumowanie: kiedy blokowanie UDP 389 jest właściwe?

• Serwer nie jest kontrolerem domeny → nie jest wymagane żadne działanie (UDP 389 nie nasłuchuje).
• Kontroler domeny za zaporą, nieudostępniony w Internecie → nie jest wymagane żadne działanie; trzymaj go z dala od publicznego Internetu.
• Kontroler domeny udostępniony w Internecie → określ zakres reguły tak, aby blokowała źródła zewnętrzne, pozostawiając nienaruszone zaufane podsieci wewnętrzne.