Blokiranje UDP veze na port 389 putem vatrozida

Ovaj vodič objašnjava kako zaštititi Windows Server od zlouporabe u LDAP (CLDAP) refleksijskim/amplifikacijskim DDoS napadima putem UDP porta 389 te kako to sigurno učiniti ovisno o ulozi poslužitelja.

Pregled

LDAP (Lightweight Directory Access Protocol) je protokol aplikacijske razine koji stoji iza Active Directoryja. Obično radi putem TCP-a, ali ima i varijantu bez uspostave veze — CLDAP (Connectionless LDAP) — koja radi putem UDP-a na portu 389. Windows klijenti koriste CLDAP za lociranje kontrolera domene ("LDAP ping" koji provodi usluga DC Locator). Modernije verzije sustava Windows često se u mnogim scenarijima mogu prebaciti na DNS-om temeljeno otkrivanje i TCP LDAP, ali se CLDAP preko UDP-a 389 i dalje koristi za operacije usluge DC Locator i pridruživanje domeni.

Sigurnosni problem je zlouporaba refleksije (pojačanja). Napadač šalje malen, falsificirani CLDAP zahtjev na UDP port 389 poslužitelja, krivotvorivši IP adresu izvora tako da izgleda kao da je zahtjev stigao od žrtve. Poslužitelj zatim šalje mnogo veći odgovor na adresu žrtve. Kad se to pomnoži s brojnim izloženim poslužiteljima, to preplavljuje žrtvu prometom. U prošlosti su zabilježeni faktori pojačanja koji premašuju 50×, ovisno o veličini LDAP odgovora, zbog čega se izloženi poslužitelji koriste kao reflektor.

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 kontrolor domene

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

U standardnoj instalaciji Windows Servera, UDP priključak 389 obično koristi samo usluga Active Directory Domain Services nakon što je poslužitelj promoviran u kontrolor domene. Standardni Windows Server (web poslužitelj, poslužitelj aplikacija, datotečni poslužitelj itd.) prema zadanim postavkama ne sluša na UDP 389, stoga se ne može zloupotrijebiti kao CLDAP reflektor, osim ako neka druga aplikacija (kao što su AD LDS ili usluga LDAP 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
• 1 — Članska radna stanica
• 2 — Samostalni poslužitelj
• 3 — Članski poslužitelj
• 4 — Kontrolor domene (prijavljeno kao "Backup Domain Controller" radi povijesne kompatibilnosti — sve moderne Active Directory kontrolore domene vraćaju ovu vrijednost)
• 5 — Kontrolor domene koji drži ulogu PDC Emulator FSMO (prikazano kao "Primary Domain Controller" radi povijesne kompatibilnosti)

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

Također možete potvrditi sluša li se nešto zapravo na UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

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

Ako vaš poslužitelj NIJE kontrolor domene

Ništa ne sluša na UDP 389, stoga poslužitelj ne može biti zloupotrijebljen kao LDAP reflektor. Za ovu specifičnu prijetnju nije potrebna nikakva promjena vatrozida.

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

Ako je vaš poslužitelj DOMAĆIN domene

Kontrolor domene doista sluša na UDP-u 389 i može se zloupotrijebiti kao reflektor — no UDP 389 je također ključan za normalno funkcioniranje domene.

Ispravan pristup na domain controlleru:

Idealno, domain controller uopće ne bi trebao biti dostupan s interneta. Zlouporaba refleksije dolazi izvana, stoga je najčišći ispravak držati DC iza perimetarskog vatrozida i ne izlagati UDP 389 javno.

Ako poslužitelj mora biti izložen, ne blokirajte UDP 389 globalno. Umjesto toga, blokirajte ga samo s vanjskih/nepoželjnih IP raspona, ostavljajući interne podmreže domene izvan blokade. Time se zaustavljaju krivotvoreni vanjski zahtjevi (koji uzrokuju refleksiju), dok interni klijenti i dalje rade. To se radi pomoću postavki opsega pravila (Scope settings), opisano u nastavku.

Isti princip primjene opsega odnosi se i na domen kontrolore samo za čitanje (RODC).

Izrada pravila vatrozida (blokiranje dolaznog UDP-a 389)

Otvorite Windows Defender vatrozid i u izborniku na lijevoj strani odaberite Napredne postavke:

Odaberite pravila ulaznog prometa iz lijevog izbornika:

Kliknite na Akcija → Nova pravila... u gornjem izborniku:

Otvorit će se čarobnjak za izradu pravila. Odaberite vrstu pravila Luka i kliknite Dalje >:

Na sljedećoj stranici odaberite UDP, zatim u odjeljku Specifični lokalni portovi upišite 389 i kliknite Dalje >:

Na sljedećoj stranici odaberite Blokiraj vezu i kliknite Dalje >:

Na kraju, pravilu dajte naziv, na primjer UDP LDAP blok, i kliknite Završi:

Ista se pravila mogu stvoriti iz PowerShella, što je praktično za skriptanje ili primjenu na više poslužitelja:

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

Definirajte opseg pravila (obavezno na kontroloru domene)

Nakon što se pravilo stvori, otvorite njegova svojstva (Properties) i idite na karticu Opseg (Scope ). Pod poljem Daljinska IP adresa (Remote IP address) odaberite opciju Ove IP adrese (These IP addresses ) i dodajte vanjske ili nepouzdane raspone koje želite blokirati. Ovdje ne dodajte svoje interne domenijske podmreže — svaki raspon naveden pod udaljenom IP adresom (Remote IP address) je raspon koji će pravilo blokirati, stoga bi navođenje internih podmreža blokiralo vaše vlastite klijente. Ostavite lokalnu IP adresu (Local IP address ) postavljeno na bilo koju IP adresu (Any IP address).

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

U PowerShelu isto ograničenje može se primijeniti pomoću ugrađene ključne riječi Internet. Ključna riječ Internet podudara se s udaljenim adresama koje Windows vatrozid klasificira kao vanjske, isključujući lokalno računalo, povratnu vezu (loopback) i uobičajene raspone lokalne mreže. Time se blokira vanjski promet, dok interni klijenti ostaju neometani:

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 kontroloru domene aktivni profil vatrozida obično je Domain. Ograničavanje pravila na profile Public i Private sprječava da utječe na normalni promet domene. Na kontroloru domene i dalje je najsigurnije izričito definirati svoje interne podmreže u opsegu pravila (Scope) umjesto da se oslanjate samo na ključnu riječ Internet — ako vaša mreža koristi nestandardne privatne raspone, oni mogu biti pogrešno klasificirani, u kojem slučaju ručno navedite svoje interne raspone i blokirajte sve ostalo.

Provjerite rezultat

Najizravniji način za potvrdu odgovara li poslužitelj i dalje na CLDAP zahtjeve jest slanje ispravnog LDAP pinga s klijenta pridruženog domeni:

nltest /ping /server:DC_NAME

Time se šalje ispravno formiran CLDAP zahtjev i izvještava o odgovoru. Zamijenite DC_NAME imenom svog kontrolora domene.

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

portqry -n SERVER_NAME -p UDP -e 389

Ovisno o odgovoru, PortQry može prikazati LISTENING ili FILTERED. Imajte na umu da PortQry šalje paket za provjeru (probe packet) umjesto potpunog LDAP pinga za CLDAP, a usluga CLDAP-a ga možda neće prepoznati kao valjan zahtjev, pa može prikazati FILTERED čak i kada je priključak otvoren. Iz tog razloga, nltest /ping smatrajte autoritativnim testom, a PortQry grubom dodatnom provjerom.

Na kontroloru domene također provjerite radi li lokacija domene i dalje za interne klijente:

nltest /dsgetdc:example.com

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

Dodatne preporuke

Redovito ažurirajte Windows. Sigurnosna ažuriranja otklanjaju kritične ranjivosti same LDAP implementacije (kao što su propusti koji bi mogli omogućiti daljinsko izvršavanje koda) i štite poslužitelj od kompromitiranja. To je zasebna briga u odnosu na zlouporabu refleksije — zakrpavanje učvršćuje sam poslužitelj, dok gore navedeno ograničavanje opsega vatrozida sprječava da poslužitelj bude iskorišten kao reflektor protiv drugih.

Omogućite potpisivanje LDAP-a i vezivanje kanala na kontrolorima domene kako biste ojačali sigurnost LDAP-a općenito.

Za volumetrijsku zaštitu, ograničavanje brzine i filtriranje DDoS-a pripadaju perimetarskom vatrozidu ili uzvodnom pružatelju usluga, a ne samom Windows hostu.

Sažetak: kada je blokiranje UDP-a 389 prikladno?

• Poslužitelj nije kontrolor domene → nije potrebno poduzeti nikakvu radnju (UDP 389 ne sluša).
• Domenski kontroler iza vatrozida, neizložen internetu → nije potrebno poduzimati nikakve radnje; držite ga izvan javnog interneta.
• Domain controller izložen internetu → ograničite pravilo tako da blokira vanjske izvore, a pouzdane interne podmreže ostavi neometane.