Blokiranje UDP veze na port 389 putem vatrozida

Pregled

LDAP (Lightweight Directory Access Protocol) je protokol aplikacijskog sloja koji stoji iza Active Directory. Obično radi preko TCP-a, ali ima i varijantu bez uspostave veze — CLDAP (Connectionless LDAP) — koja radi preko UDP-a na portu 389. Windows klijenti koriste CLDAP za pronalaženje kontrolera domene (takozvani „LDAP ping“ koji izvodi DC Locator usluga). Moderne verzije Windowsa u mnogim scenarijima mogu prijeći na otkrivanje temeljeno na DNS-u i LDAP preko TCP-a, no CLDAP preko UDP 389 i dalje se koristi za DC Locator operacije i pridruživanje domeni.

Sigurnosni problem je zlouporaba reflektiranjem (pojačavanjem). Napadač šalje mali, lažirani CLDAP zahtjev na UDP port 389 poslužitelja, lažirajući izvorišnu IP adresu tako da izgleda kao da zahtjev dolazi od žrtve. Poslužitelj zatim šalje mnogo veći odgovor na adresu žrtve. Pomnoženo kroz mnoge izložene poslužitelje, to preplavljuje žrtvu prometom. U prošlosti su zabilježeni faktori pojačavanja veći od 50×, ovisno o veličini LDAP odgovora — zbog čega se izloženi poslužitelji koriste kao reflektori.

Cilj ovog vodiča je spriječiti da vaš poslužitelj djeluje kao takav reflektor — bez narušavanja legitimnih funkcija Active Directoryja.

Korak 1: Utvrdite je li vaš poslužitelj kontroler domene

Ovo je najvažniji korak jer određuje što (ako išta) trebate blokirati.

U standardnoj instalaciji Windows Servera, UDP port 389 obično koristi samo Active Directory Domain Services nakon što je poslužitelj promaknut u kontroler domene. Običan Windows Server (web, aplikacijski, datotečni poslužitelj itd.) prema zadanim postavkama ne osluškuje na UDP 389, pa se ne može zloupotrijebiti kao CLDAP reflektor osim ako druga aplikacija (poput AD LDS-a ili LDAP usluge treće strane) ne pruža CLDAP uslugu na tom portu.

Otvorite PowerShell kao administrator i provjerite stvarnu ulogu poslužitelja u domeni:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Tumačenje rezultata:

• 0 — Samostalna radna stanica (Standalone Workstation)
• 1 — Radna stanica član (Member Workstation)
• 2 — Samostalni poslužitelj (Standalone Server)
• 3 — Poslužitelj član (Member Server)
• 4 — Kontroler domene (zbog povijesne kompatibilnosti prijavljen kao „Backup Domain Controller“ — svi moderni Active Directory kontroleri domene vraćaju ovu vrijednost)
• 5 — Kontroler domene s PDC Emulator FSMO ulogom (zbog povijesne kompatibilnosti prijavljen kao „Primary Domain Controller“)

Ako rezultat nije 4 ili 5, poslužitelj nije kontroler domene.

Također možete potvrditi osluškuje li išta stvarno na UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Ako ova naredba ne vrati ništa, Windows ne osluškuje na UDP portu 389, pa poslužitelj ne pruža CLDAP usluge i nije izložen ovom napadu.

Ako vaš poslužitelj NIJE kontroler domene

Ništa ne osluškuje na UDP 389, pa se poslužitelj ne može zloupotrijebiti kao LDAP reflektor. Za ovu specifičnu prijetnju nije potrebna promjena vatrozida.

Ako želite dokumentirati svoju sigurnosnu politiku ili nametnuti izričito pravilo odbijanja, i dalje možete stvoriti pravilo vatrozida u nastavku. Budući da nijedna usluga ne osluškuje na UDP portu 389, pravilo nema praktičnog učinka.

Ako vaš poslužitelj JEST kontroler domene

Kontroler domene stvarno osluškuje na UDP 389 i može se zloupotrijebiti kao reflektor — ali UDP 389 je također neophodan za normalan rad domene.

Upozorenje: Nemojte naslijepo blokirati sav dolazni UDP 389 promet na kontroleru domene. Klijenti pridruženi domeni koriste CLDAP (UDP 389) za pronalaženje kontrolera domene, a isti port je potreban za pridruživanje domeni. Općenita blokada može spriječiti klijente da pronađu kontroler domene te narušiti prijavu i operacije pridruživanja domeni.

Ispravan pristup na kontroleru domene:

U idealnom slučaju, kontroler domene uopće ne bi smio biti dostupan s interneta. Zlouporaba reflektiranjem dolazi izvana, pa je najčišće rješenje držati DC iza perimetarskog vatrozida i ne izlagati UDP 389 javno.

Ako poslužitelj mora biti izložen, nemojte blokirati UDP 389 globalno. Umjesto toga, blokirajte ga samo s vanjskih/nepouzdanih IP raspona, ostavljajući svoje interne podmreže domene izvan blokade. To zaustavlja lažirane vanjske zahtjeve (koji uzrokuju reflektiranje), zadržavajući rad internih klijenata. To se radi pomoću postavki Opsega (Scope) pravila, opisanih u nastavku.

Isto načelo opsega vrijedi za kontrolere domene samo za čitanje (RODC).

Stvaranje pravila vatrozida (blokiranje dolaznog UDP 389)

Otvorite Windows Firewall i odaberite Advanced settings s lijevog bočnog izbornika:

Odaberite Inbound Rules s lijevog bočnog izbornika:

Kliknite Action → New Rule... u gornjem izborniku:

Otvorit će se čarobnjak za stvaranje pravila. Odaberite vrstu pravila Port i kliknite Next >:

Na sljedećoj stranici odaberite UDP, zatim pod Specific local ports upišite 389 i kliknite Next >:

Na sljedećoj stranici odaberite Block the connection i kliknite Next >:

Naposljetku, dodijelite pravilu naziv, na primjer UDP LDAP block, i kliknite Finish:

Isto pravilo može se stvoriti iz PowerShell-a, što je praktično za skriptiranje ili primjenu na više poslužitelja:

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

Upozorenje: Na kontroleru domene nemojte stati ovdje. Gornje pravilo blokira UDP 389 sa svih izvora, što će narušiti pronalaženje kontrolera domene za interne klijente. Morate odrediti njegov opseg (sljedeći korak).

Određivanje opsega pravila (obavezno na kontroleru domene)

Nakon što je pravilo stvoreno, otvorite njegova Svojstva i idite na karticu Scope (Opseg). Pod Remote IP address odaberite These IP addresses i dodajte vanjske ili nepouzdane raspone koje želite blokirati. Nemojte ovdje dodavati svoje interne podmreže domene — svaki raspon naveden pod „Remote IP address“ je raspon koji će pravilo blokirati, pa bi navođenje internih podmreža blokiralo vaše vlastite klijente. Ostavite Local IP address postavljen na Any IP address.

Na taj se način blokada primjenjuje samo na nepouzdane vanjske izvore koje navedete, dok interni klijenti (koji nisu navedeni) ostaju nepromijenjeni.

U PowerShell-u, isti se opseg može primijeniti pomoću ugrađene ključne riječi Internet. Ključna riječ Internet odgovara udaljenim adresama koje Windows vatrozid klasificira kao vanjske, isključujući lokalno računalo, povratnu petlju (loopback) i uobičajene raspone lokalne mreže. To blokira vanjski promet, ostavljajući interne klijente nepromijenjenima:

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

Na ispravno konfiguriranom kontroleru domene, aktivni profil vatrozida obično je Domena. Ograničavanje pravila na profile Javno i Privatno sprječava da utječe na normalan promet domene. Na kontroleru domene ipak je najsigurnije izričito definirati svoje interne podmreže u Opsegu pravila umjesto oslanjanja samo na ključnu riječ Internet — ako vaša mreža koristi nestandardne privatne raspone, mogli bi biti pogrešno klasificirani; u tom slučaju ručno navedite svoje interne raspone i blokirajte sve ostalo.

Provjera rezultata

Upozorenje: Nemojte koristiti Test-NetConnection za provjeru UDP 389 — testira samo TCP veze i dat će obmanjujuće rezultate za UDP.

Najizravniji način za potvrdu odgovara li poslužitelj još uvijek na CLDAP zahtjeve jest poslati ispravan LDAP ping s klijenta pridruženog domeni:

nltest /ping /server:DC_NAME

To šalje ispravno oblikovan CLDAP zahtjev i prijavljuje odgovor. Zamijenite DC_NAME nazivom svog kontrolera domene.

Kao sekundarnu provjeru, s drugog računala možete koristiti PortQry (besplatni Microsoftov alat naredbenog retka):

portqry -n SERVER_NAME -p UDP -e 389

Ovisno o odgovoru, PortQry može prijaviti LISTENING ili FILTERED. Imajte na umu da PortQry šalje probni paket umjesto potpunog CLDAP LDAP pinga, a CLDAP usluga ga možda neće prepoznati kao valjani zahtjev, pa može prijaviti FILTERED čak i kada je port otvoren. Iz tog razloga, smatrajte nltest /ping mjerodavnim testom, a PortQry grubom dopunskom provjerom.

Na kontroleru domene također potvrdite da pronalaženje domene još uvijek radi za interne klijente:

nltest /dsgetdc:example.com

Zamijenite example.com nazivom svoje domene. Uspješan odgovor znači da klijenti još uvijek mogu pronaći kontroler domene. Imajte na umu da uspješan dsgetdc sam po sebi ne dokazuje da CLDAP preko UDP-a radi, jer DC Locator može prijeći na DNS upite i LDAP preko TCP-a ako CLDAP nije dostupan, ovisno o operaciji koja se izvodi — zbog čega je gornja provjera nltest /ping izravniji test.

Dodatne preporuke

Održavajte Windows potpuno ažuriranim. Sigurnosna ažuriranja rješavaju kritične ranjivosti u samoj LDAP implementaciji (poput propusta koji bi mogli omogućiti daljinsko izvršavanje koda) i štite poslužitelj od kompromitiranja. To je zasebno pitanje od zlouporabe reflektiranjem — zakrpe ojačavaju sam poslužitelj, dok gornje određivanje opsega vatrozida sprječava da se poslužitelj koristi kao reflektor protiv drugih.

Omogućite LDAP potpisivanje i vezivanje kanala na kontrolerima domene radi općenitog ojačavanja LDAP-a.

Za volumetrijsku zaštitu, ograničavanje brzine i DDoS filtriranje pripadaju perimetarskom vatrozidu ili nadređenom (upstream) pružatelju usluga, a ne samom Windows hostu.

Sažetak: kada je blokiranje UDP 389 prikladno?

• Poslužitelj nije kontroler domene → nije potrebna nikakva radnja (UDP 389 ne osluškuje).
• Kontroler domene iza vatrozida, nije izložen internetu → nije potrebna nikakva radnja; držite ga izvan javnog interneta.
• Kontroler domene izložen internetu → odredite opseg pravila tako da blokira vanjske izvore, ostavljajući pouzdane interne podmreže nepromijenjenima.