Blokiranje povezave UDP do vrat 389 prek požarnega zidu

Pregled

LDAP (Lightweight Directory Access Protocol) je protokol aplikacijske plasti, ki stoji za Active Directory. Običajno deluje prek TCP, vendar ima tudi različico brez povezave — CLDAP (Connectionless LDAP) — ki deluje prek UDP na vratih 389. Odjemalci Windows uporabljajo CLDAP za iskanje krmilnikov domene („LDAP ping“, ki ga izvaja storitev DC Locator). Sodobne različice sistema Windows lahko v številnih primerih preklopijo na odkrivanje prek DNS in LDAP prek TCP, vendar se CLDAP prek UDP 389 še vedno uporablja za operacije DC Locator in pridružitev domeni.

Varnostna težava je zloraba z odbijanjem (ojačanjem). Napadalec pošlje majhno, ponarejeno zahtevo CLDAP na vrata UDP 389 strežnika in ponaredi izvorni naslov IP tako, da je videti, kot da zahteva prihaja od žrtve. Strežnik nato pošlje veliko večji odgovor na naslov žrtve. Pomnoženo prek številnih izpostavljenih strežnikov to preplavi žrtev s prometom. V preteklosti so bili opaženi faktorji ojačanja, ki presegajo 50×, odvisno od velikosti odgovora LDAP — zato se izpostavljeni strežniki uporabljajo kot odbojniki.

Cilj tega vodnika je preprečiti, da bi vaš strežnik deloval kot tak odbojnik — ne da bi pri tem motili legitimne funkcije Active Directory.

Korak 1: Ugotovite, ali je vaš strežnik krmilnik domene

To je najpomembnejši korak, saj določa, kaj (če sploh) morate blokirati.

Pri standardni namestitvi Windows Server vrata UDP 389 običajno uporabljajo le Active Directory Domain Services, potem ko je strežnik povišan v krmilnik domene. Običajen Windows Server (spletni, aplikacijski, datotečni strežnik itd.) privzeto ne posluša na UDP 389, zato ga ni mogoče zlorabiti kot odbojnik CLDAP, razen če druga aplikacija (kot je AD LDS ali storitev LDAP tretje osebe) zagotavlja storitev CLDAP na teh vratih.

Odprite PowerShell kot skrbnik in preverite dejansko vlogo strežnika v domeni:

(Get-CimInstance Win32_ComputerSystem).DomainRole

Razlaga rezultata:

• 0 — Samostojna delovna postaja (Standalone Workstation)
• 1 — Delovna postaja član (Member Workstation)
• 2 — Samostojni strežnik (Standalone Server)
• 3 — Strežnik član (Member Server)
• 4 — Krmilnik domene (zaradi zgodovinske združljivosti poročan kot „Backup Domain Controller“ — to vrednost vrnejo vsi sodobni krmilniki domene Active Directory)
• 5 — Krmilnik domene z vlogo FSMO emulatorja PDC (zaradi zgodovinske združljivosti poročan kot „Primary Domain Controller“)

Če rezultat ni 4 ali 5, strežnik ni krmilnik domene.

Prav tako lahko preverite, ali kaj dejansko posluša na UDP 389:

Get-NetUDPEndpoint -LocalPort 389 -ErrorAction SilentlyContinue

Če ta ukaz ne vrne ničesar, Windows ne posluša na vratih UDP 389, zato strežnik ne zagotavlja storitev CLDAP in ni izpostavljen temu napadu.

Če vaš strežnik NI krmilnik domene

Nič ne posluša na UDP 389, zato strežnika ni mogoče zlorabiti kot odbojnik LDAP. Za to specifično grožnjo sprememba požarnega zidu ni potrebna.

Če želite dokumentirati svojo varnostno politiko ali uveljaviti izrecno pravilo zavrnitve, lahko spodnje pravilo požarnega zidu kljub temu ustvarite. Ker nobena storitev ne posluša na vratih UDP 389, pravilo nima praktičnega učinka.

Če vaš strežnik JE krmilnik domene

Krmilnik domene dejansko posluša na UDP 389 in ga je mogoče zlorabiti kot odbojnik — vendar je UDP 389 hkrati bistven za normalno delovanje domene.

Opozorilo: Na krmilniku domene ne blokirajte na slepo celotnega vhodnega prometa UDP 389. Odjemalci, pridruženi domeni, uporabljajo CLDAP (UDP 389) za iskanje krmilnika domene, ista vrata pa so potrebna za pridružitev domeni. Splošna blokada lahko prepreči odjemalcem iskanje krmilnika domene ter zmoti prijavo in operacije pridružitve domeni.

Pravilen pristop na krmilniku domene:

V idealnem primeru krmilnik domene sploh ne bi smel biti dosegljiv iz interneta. Zloraba z odbijanjem prihaja od zunaj, zato je najčistejša rešitev, da DC ostane za obodnim požarnim zidom in da UDP 389 ni javno izpostavljen.

Če mora biti strežnik izpostavljen, ne blokirajte UDP 389 globalno. Namesto tega ga blokirajte samo iz zunanjih/nezaupanja vrednih obsegov IP, pri čemer notranja domenska podomrežja pustite zunaj blokade. To ustavi ponarejene zunanje zahteve (ki povzročajo odbijanje), medtem ko notranji odjemalci še naprej delujejo. To storite z nastavitvami Obseg (Scope) pravila, opisanimi spodaj.

Isto načelo obsega velja za krmilnike domene samo za branje (RODC).

Ustvarjanje pravila požarnega zidu (blokiranje vhodnega prometa UDP 389)

Odprite požarni zid Windows in v levem meniju izberite Napredne nastavitve:

V meniju na levi strani izberite Vhodna pravila:

V zgornjem meniju kliknite Akcija → Novo pravilo...:

Odpre se čarovnik za ustvarjanje pravila. Izberite vrsto pravila Vrata in kliknite Naprej >:

Na naslednji strani izberite UDP, nato pod Posebna lokalna vrata vnesite 389 in kliknite Naprej >:

Na naslednji strani izberite Blokiraj povezavo in kliknite Naprej >:

Na koncu pravilu dodelite ime, na primer UDP LDAP block, in kliknite Dokončaj:

Isto pravilo je mogoče ustvariti iz PowerShell, kar je priročno za skriptiranje ali uporabo na več strežnikih:

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

Opozorilo: Na krmilniku domene se tu ne ustavite. Zgornje pravilo blokira UDP 389 iz vseh virov, kar bo zmotilo iskanje krmilnika domene za notranje odjemalce. Določiti morate njegov obseg (naslednji korak).

Določitev obsega pravila (potrebno na krmilniku domene)

Po ustvarjanju pravila odprite njegove Lastnosti in pojdite na zavihek Obseg (Scope). Pod Oddaljeni naslov IP izberite Ti naslovi IP in dodajte zunanje ali nezaupanja vredne obsege, ki jih želite blokirati. Sem ne dodajajte svojih notranjih domenskih podomrežij — vsak obseg, naveden pod „Oddaljeni naslov IP“, je obseg, ki ga bo pravilo blokiralo, zato bi navedba notranjih podomrežij blokirala vaše lastne odjemalce. Lokalni naslov IP pustite nastavljen na Kateri koli naslov IP.

Na ta način se blokada uporablja samo za nezaupanja vredne zunanje vire, ki jih navedete, medtem ko notranji odjemalci (ki niso navedeni) ostanejo nespremenjeni.

V PowerShell je mogoče isti obseg uporabiti z vgrajeno ključno besedo Internet. Ključna beseda Internet ujema oddaljene naslove, ki jih požarni zid Windows razvrsti kot zunanje, pri čemer izključi lokalni računalnik, povratno zanko (loopback) in običajne obsege lokalnega omrežja. To blokira zunanji promet in pusti notranje odjemalce nespremenjene:

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

Na pravilno konfiguriranem krmilniku domene je aktivni profil požarnega zidu običajno Domena. Omejitev pravila na profila Javno in Zasebno preprečuje, da bi vplivalo na normalen domenski promet. Na krmilniku domene je kljub temu najvarneje, da svoja notranja podomrežja izrecno določite v Obsegu pravila, namesto da se zanašate le na ključno besedo Internet — če vaše omrežje uporablja nestandardne zasebne obsege, so lahko napačno razvrščeni; v tem primeru ročno navedite svoje notranje obsege in blokirajte vse drugo.

Preverjanje rezultata

Opozorilo: Za preverjanje UDP 389 ne uporabljajte Test-NetConnection — preverja samo povezave TCP in bo dal zavajajoče rezultate za UDP.

Najbolj neposreden način za potrditev, ali strežnik še vedno odgovarja na zahteve CLDAP, je pošiljanje pravilnega LDAP ping z odjemalca, pridruženega domeni:

nltest /ping /server:DC_NAME

To pošlje pravilno oblikovano zahtevo CLDAP in poroča o odgovoru. DC_NAME zamenjajte z imenom svojega krmilnika domene.

Kot sekundarno preverjanje lahko z drugega računalnika uporabite PortQry (brezplačno Microsoftovo orodje ukazne vrstice):

portqry -n SERVER_NAME -p UDP -e 389

Glede na odgovor lahko PortQry poroča LISTENING ali FILTERED. Upoštevajte, da PortQry pošlje preizkusni paket namesto popolnega CLDAP LDAP ping, in storitev CLDAP ga morda ne prepozna kot veljavno zahtevo, zato lahko poroča FILTERED, tudi ko so vrata odprta. Zato obravnavajte nltest /ping kot merodajni preizkus, PortQry pa kot grobo dopolnilno preverjanje.

Na krmilniku domene tudi potrdite, da iskanje domene še vedno deluje za notranje odjemalce:

nltest /dsgetdc:example.com

example.com zamenjajte z imenom svoje domene. Uspešen odgovor pomeni, da odjemalci še vedno lahko najdejo krmilnik domene. Upoštevajte, da uspešen dsgetdc sam po sebi ne dokazuje, da CLDAP prek UDP deluje, saj lahko DC Locator preklopi na poizvedbe DNS in LDAP prek TCP, če CLDAP ni na voljo, odvisno od izvedene operacije — zato je zgornje preverjanje nltest /ping bolj neposreden preizkus.

Dodatna priporočila

Windows naj bo vedno popolnoma posodobljen. Varnostne posodobitve odpravljajo kritične ranljivosti v sami implementaciji LDAP (kot so napake, ki bi lahko omogočile oddaljeno izvajanje kode) in ščitijo strežnik pred ogrožanjem. To je ločeno vprašanje od zlorabe z odbijanjem — popravki utrjujejo sam strežnik, medtem ko zgornja določitev obsega požarnega zidu preprečuje, da bi se strežnik uporabljal kot odbojnik proti drugim.

Omogočite podpisovanje LDAP in vezavo kanala na krmilnikih domene za splošno utrjevanje LDAP.

Za zaščito pred volumetričnimi napadi omejevanje hitrosti in filtriranje DDoS sodita na obodni požarni zid ali k nadrejenemu ponudniku (upstream), ne na sam gostitelj Windows.

Povzetek: kdaj je blokiranje UDP 389 primerno?

• Strežnik ni krmilnik domene → ukrep ni potreben (UDP 389 ne posluša).
• Krmilnik domene za požarnim zidom, ni izpostavljen internetu → ukrep ni potreben; naj bo zunaj javnega interneta.
• Krmilnik domene, izpostavljen internetu → določite obseg pravila tako, da blokira zunanje vire, pri čemer zaupanja vredna notranja podomrežja ostanejo nespremenjena.