Blokowanie połączenia UDP z portem 389 za pomocą zapory sieciowej

W niniejszym przewodniku wyjaśniono, jak zabezpieczyć serwer Windows Server przed nadużyciami w ramach ataków DDoS typu odbicie/wzmocnienie (LDAP/CLDAP) realizowanych przez port UDP 389 oraz jak to zrobić w bezpieczny sposób w zależności od roli serwera.

Przegląd

LDAP (Lightweight Directory Access Protocol) to protokół warstwy aplikacji, na którym opiera się usługa Active Directory. Zazwyczaj działa on w oparciu o protokół TCP, ale posiada również wariant bezpołączeniowy — CLDAP (Connectionless LDAP) — który działa w oparciu o protokół UDP na porcie 389. Klienci systemu Windows wykorzystują protokół CLDAP do lokalizowania kontrolerów domeny (tzw. „ping LDAP” wykonywany przez usługę DC Locator). Nowoczesne wersje systemu Windows często mogą w wielu scenariuszach przełączać się na wykrywanie oparte na DNS i protokół TCP LDAP, jednak protokół CLDAP na porcie UDP 389 jest nadal używany do operacji DC Locator oraz dołączania do domeny.

Problem bezpieczeństwa polega na nadużyciu odbicia (amplifikacji). Atakujący wysyła małe, sfałszowane żądanie CLDAP na port UDP 389 serwera, podszywając się pod adres IP źródłowy, tak aby wyglądało, jakby żądanie pochodziło od ofiary. Serwer wysyła następnie znacznie większą odpowiedź na adres ofiary. W przypadku wielu narażonych serwerów powoduje to zalanie ofiary ruchem sieciowym. W przeszłości obserwowano współczynniki wzmocnienia przekraczające 50×, w zależności od rozmiaru odpowiedzi LDAP, dlatego narażone serwery są wykorzystywane jako reflektory.

Celem tego przewodnika jest zapobieżenie wykorzystywaniu serwera jako takiego reflektora — bez zakłócania prawidłowego działania funkcji Active Directory.

Krok 1: Sprawdź, czy Twój serwer jest kontrolerem domeny

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

W standardowej instalacji systemu Windows Server port UDP 389 jest zwykle używany wyłącznie przez usługi domenowe Active Directory po podniesieniu serwera do rangi kontrolera domeny. Zwykły serwer Windows Server (serwer WWW, aplikacji, plików itp.) domyślnie nie nasłuchuje na porcie UDP 389, więc nie może być wykorzystywany 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 program PowerShell jako administrator i sprawdź rzeczywistą rolę serwera w domenie:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Interpretacja wyniku:

• 0 — Samodzielna stacja robocza
• 1 — Stacja robocza członkowska
• 2 — Serwer autonomiczny
• 3 — Serwer członkowski
• 4 — Kontroler domeny (wyświetlany jako „Rezerwowy kontroler domeny” ze względu na zgodność z poprzednimi wersjami — wszystkie nowoczesne kontrolery domeny Active Directory zwracają tę wartość)
• 5 — Kontroler domeny pełniący rolę FSMO emulatora PDC (wyświetlany jako „Główny kontroler domeny” ze względu na zgodność z starszymi wersjami)

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

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

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Jeśli to polecenie nie zwróci żadnego wyniku, system Windows nie nasłuchuje na porcie UDP 389, więc serwer nie świadczy usług CLDAP i nie jest narażony na ten atak.

Jeśli serwer NIE jest kontrolerem domeny

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

Jeśli chcesz udokumentować swoją politykę bezpieczeństwa lub wprowadzić wyraźną regułę blokującą, nadal możesz utworzyć poniższą regułę zapory sieciowej. Ponieważ żadna usługa nie nasłuchuje na porcie UDP 389, reguła ta nie ma praktycznego znaczenia.

Jeśli serwer JEST kontrolerem domeny

Kontroler domeny rzeczywiście nasłuchuje na porcie UDP 389 i może zostać wykorzystany jako reflektor — jednak port UDP 389 jest również niezbędny do normalnego funkcjonowania domeny.

Prawidłowe podejście na kontrolerze domeny:

W idealnym przypadku kontroler domeny nie powinien być w ogóle dostępny z Internetu. Nadużycia związane z odbiciem pochodzą z zewnątrz, więc najczystszym rozwiązaniem jest umieszczenie kontrolera domeny za zaporą obwodową i nieudostępnianie portu UDP 389 publicznie.

Jeśli serwer musi być udostępniony, nie należy blokować portu UDP 389 globalnie. Zamiast tego należy zablokować go tylko dla zewnętrznych/niezaufanych zakresów adresów IP, pozostawiając wewnętrzne podsieci domeny poza blokadą. Powstrzymuje to sfałszowane żądania zewnętrzne (które powodują odbicie), jednocześnie zapewniając działanie klientów wewnętrznych. Odbywa się to za pomocą ustawień zakresu reguły, opisanych poniżej.

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

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

Otwórz zaporę systemu Windows Defender i wybierz opcję „Ustawienia zaawansowane” w menu po lewej stronie:

Wybierz opcję „Reguły przychodzące” z menu po lewej stronie:

W górnym menu kliknij opcję Działanie → Nowa reguła...:

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

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

Na następnej stronie wybierz opcję „Zablokuj połączenie ” i kliknij „Dalej >”:

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

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

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

Ogranicz zasięg reguły (wymagane na kontrolerze domeny)

Po utworzeniu reguły otwórz jej „Właściwości ” i przejdź do zakładki „Zakres ”. W sekcji „Zdalny adres IP” wybierz opcję „Te adresy IP ” i dodaj zakresy adresów zewnętrznych lub niezaufanych, które chcesz zablokować. Nie dodawaj tutaj podsieci swojej domeny wewnętrznej — każdy zakres wymieniony w polu „Zdalny adres IP” jest zakresem, który reguła zablokuje, więc umieszczenie tam podsieci wewnętrznych spowodowałoby zablokowanie własnych klientów. Pozostaw opcję „Lokalny adres IP ” ustawioną na „Dowolny adres IP”.

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

W programie 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 oraz typowych zakresów sieci lokalnej. Blokuje to ruch zewnętrzny, nie wpływając na klientów wewnętrznych:

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 aktywnym profilem zapory jest zazwyczaj „Domena”. Ograniczenie reguły do profili „Publiczny” i „Prywatny” zapobiega jej wpływowi na normalny ruch w domenie. Na kontrolerze domeny nadal najbezpieczniej jest jawnie zdefiniować podsieci wewnętrzne w polu „Zakres” reguły, zamiast polegać wyłącznie na słowie kluczowym „Internet” — jeśli w sieci stosowane są niestandardowe zakresy prywatne, mogą one zostać błędnie sklasyfikowane; w takim przypadku należy ręcznie wymienić zakresy wewnętrzne i zablokować wszystko inne.

Sprawdź wynik

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

nltest /ping /server:DC_NAME

Spowoduje to wysłanie poprawnie sformułowanego żądania CLDAP i wyświetlenie odpowiedzi. Zastąp DC_NAME nazwą swojego kontrolera domeny.

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

portqry -n SERVER_NAME -p UDP -e 389

W zależności od odpowiedzi PortQry może zgłosić stan LISTENING lub FILTERED. Należy pamiętać, że PortQry wysyła pakiet sondażowy zamiast pełnego polecenia „ping” CLDAP LDAP, a usługa CLDAP może nie rozpoznać go jako prawidłowego żądania, przez co może zgłosić komunikat FILTERED, nawet jeśli port jest otwarty. Z tego powodu polecenie nltest /ping należy traktować jako test miarodajny, a PortQry jako przybliżoną kontrolę uzupełniającą.

Na kontrolerze domeny należy również sprawdzić, czy lokalizacja 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 wykonanie polecenia dsgetdc nie dowodzi, że protokół CLDAP przez UDP działa, ponieważ lokalizator kontrolera domeny może, w zależności od wykonywanej operacji, przełączyć się na zapytania DNS i protokół LDAP przez TCP, jeśli protokół CLDAP jest niedostępny — dlatego powyższy test nltest /ping jest bardziej bezpośrednim sprawdzianem.

Dodatkowe zalecenia

Dbaj o to, by system Windows był w pełni zaktualizowany. Aktualizacje zabezpieczeń eliminują krytyczne luki w samej implementacji LDAP (takie jak błędy, które mogłyby umożliwić zdalne wykonanie kodu) i chronią serwer przed przejęciem kontroli. Jest to kwestia odrębna od nadużywania refleksji — instalowanie poprawek wzmacnia sam serwer, podczas gdy powyższe ograniczenia zapory sieciowej zapobiegają wykorzystaniu serwera jako reflektora przeciwko innym.

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

W przypadku ochrony przed atakami wolumetrycznymi ograniczenie przepustowości i filtrowanie ataków DDoS powinny być realizowane na zaporze obwodowej lub u dostawcy usług internetowych, a nie na samym hoście z systemem Windows.

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

• Serwer nie jest kontrolerem domeny → nie trzeba podejmować żadnych działań (port UDP 389 nie nasłuchuje).
• Kontroler domeny za zaporą ogniową, nie narażony na dostęp z Internetu → nie ma potrzeby podejmowania żadnych działań; należy utrzymywać go z dala od publicznego Internetu.
• Kontroler domeny wystawiony na działanie Internetu → należy odpowiednio określić zakres reguły, tak aby blokowała ona źródła zewnętrzne, nie wpływając jednocześnie na zaufane podsieci wewnętrzne.