Blokiranje UDP-povezave na vrata 389 prek požarnega zidu

V tem vodniku je pojasnjeno, kako zaščititi strežnik Windows Server pred zlorabo v okviru DDoS-napadov z odbojem/amplifikacijo prek protokola LDAP (CLDAP) na UDP-vratih 389 ter kako to varno izvesti glede na vlogo strežnika.

Pregled

LDAP (Lightweight Directory Access Protocol) je protokol na aplikacijski plasti, na katerem temelji Active Directory. Običajno deluje prek protokola TCP, vendar ima tudi različico brez povezave – CLDAP (Connectionless LDAP) –, ki deluje prek protokola UDP na vratih 389. Windowsovi odjemalci uporabljajo CLDAP za iskanje krmilnikov domene (t. i. »LDAP ping«, ki ga izvaja storitev DC Locator). Sodobne različice sistema Windows se v mnogih primerih lahko zatečejo k iskanju na podlagi DNS in TCP LDAP, vendar se CLDAP prek UDP 389 še vedno uporablja za delovanje storitve DC Locator in pridruževanje domeni.

Varnostni problem je zloraba odboja (amplifikacije). Napadalec pošlje majhno, ponarejeno zahtevo CLDAP na UDP-vrata 389 strežnika, pri čemer ponaredi izvorni IP-naslov, tako da izgleda, kot da je zahteva prišla od žrtve. Strežnik nato pošlje veliko večji odgovor na naslov žrtve. Če se to pomnoži z več izpostavljenimi strežniki, žrtev preplavi promet. V preteklosti so bili opazovani faktorji ojačitve, ki so presegali 50-kratno vrednost, odvisno od velikosti LDAP-odgovora, zato se izpostavljeni strežniki uporabljajo kot reflektorji.

Cilj tega vodnika je preprečiti, da bi vaš strežnik deloval kot tak odbojnik – brez motenja legitimnih funkcij Active Directoryja.

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

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

V standardni namestitvi strežnika Windows Server UDP-vrata 389 običajno uporabljajo le storitve domene Active Directory, potem ko je bil strežnik povišan v krmilnik domene. Običajni strežnik Windows Server (spletni, aplikacijski, datotečni strežnik itd.) privzeto ne posluša na UDP 389, zato ga ni mogoče zlorabiti kot CLDAP-reflektor, razen če druga aplikacija (kot sta AD LDS ali LDAP-storitev tretje osebe) na tem vratu zagotavlja storitev CLDAP.

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

(Get-CimInstance Win32_ComputerSystem).DomainRole

Razlaga rezultata:

• 0 — Samostojna delovna postaja
• 1 — Članska delovna postaja
• 2 — Samostojni strežnik
• 3 — Članski strežnik
• 4 — krmilnik domene (prikazan kot »rezervni krmilnik domene« zaradi združljivosti s starejšimi različicami — to vrednost vrnejo vsi sodobni krmilniki domene Active Directory)
• 5 — Domenski krmilnik z vlogo FSMO »Emulator PDC« (zaradi združljivosti s starejšimi različicami se prikazuje kot »Primarni domenski krmilnik«)

Č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 prisluhne na UDP-vratu 389, zato strežnik ne zagotavlja storitev CLDAP in ni izpostavljen temu napadu.

Če vaš strežnik NI domenski krmilnik

Na UDP 389 nič ne posluša, zato strežnika ni mogoče zlorabiti kot LDAP-reflektor. Za to konkretno grožnjo ni potrebna nobena sprememba požarnega zidu.

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

Če je vaš strežnik DOMENSKI KONTROLER

Domenski krmilnik dejansko posluša na UDP 389 in ga je mogoče zlorabiti kot reflektor – vendar je UDP 389 nujen tudi za normalno delovanje domene.

Pravilen pristop na domenskem krmilniku:

V idealnem primeru domenski krmilnik sploh ne bi smel biti dosegljiv iz interneta. Zloraba odboja prihaja od zunaj, zato je najčistejša rešitev, da domenski krmilnik ostane za perimetrskim požarnim zidom in da se UDP 389 ne izpostavi javno.

Če mora biti strežnik izpostavljen, ne blokirajte UDP 389 globalno. Namesto tega ga blokirajte le iz zunanjih/nezanesljivih območij IP-naslovov, pri čemer notranja podomrežja domene izključite iz blokade. To ustavi ponarejene zunanje zahteve (ki povzročajo odboj), hkrati pa omogoča delovanje notranjih odjemalcev. To se izvede s pomočjo nastavitev obsega pravila, ki so opisane spodaj.

Enako načelo obsega velja tudi za krmilnike domene, namenjene le za branje (RODC).

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

Odprite požarni zid Windows Defender in v meniju na levi strani izberite »Napredne nastavitve«:

V meniju na levi strani izberite »Pravila za dohodni promet «:

V zgornjem meniju kliknite »Dejanje« → »Novo pravilo...«:

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

Na naslednji strani izberite UDP, nato v polju »Določena lokalna vrata« vnesite 389 in kliknite »Naprej >«:

Na naslednji strani izberite »Blokiraj povezavo« in kliknite »Naprej >«:

Na koncu pravilu dodajte ime, na primer »Blokiranje UDP LDAP«, in kliknite »Dokončaj«:

Enako pravilo lahko ustvarite tudi v PowerShellu, kar je priročno za pisanje skriptov ali uporabo na več strežnikih:

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

Omejite obseg pravila (obvezno na domenskem krmilniku)

Ko je pravilo ustvarjeno, odprite njegove »Lastnosti« in prejdite na zavihek »Obseg «. V polju »Oddaljeni IP-naslov« izberite »Ti IP-naslovi « in dodajte zunanja ali nezaupljiva območja, ki jih želite blokirati. Tukaj ne dodajajte svojih notranjih podomrežij domene – vsak razpon, naveden pod »Oddaljen IP-naslov«, je razpon, ki ga bo pravilo blokiralo, zato bi navedba notranjih podomrežij blokirala vaše lastne odjemalce. Nastavitev »Lokalni IP-naslov« pustite na »Kateri koli IP-naslov«.

Tako se blokada nanaša le na nezaupljive zunanje vire, ki jih določite, medtem ko notranje odjemalce (ki niso navedeni) to ne prizadene.

V PowerShellu lahko isti obseg uporabite z vgrajeno ključno besedo »Internet «. Ključna beseda »Internet« se ujema z oddaljenimi naslovi, ki jih požarni zid sistema Windows razvršča kot zunanje, pri čemer izključuje lokalni računalnik, naslov za povratno zanko in običajna območja lokalnega omrežja. To blokira zunanji promet, notranje odjemalce pa pusti neprizadete:

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 nastavljenem krmilniku domene je aktivni profil požarnega zidu običajno »Domena«. Omejitev pravila na profila »Javni« in »Zasebni« prepreči, da bi vplivalo na običajni promet v domeni. Na domenskem krmilniku je še vedno najvarneje, da notranja podomrežja izrecno opredelite v obsegu pravila, namesto da se zanašate le na ključno besedo »Internet« – če vaše omrežje uporablja nestandardna zasebna območja, se lahko ta napačno razvrstijo; v tem primeru ročno navedite svoja notranja območja in blokirajte vse ostalo.

Preverite rezultat

Najbolj neposreden način za potrditev, ali strežnik še vedno odgovarja na zahteve CLDAP, je pošiljanje ustreznega LDAP-pinga iz odjemalca, priključenega na domeno:

nltest /ping /server:DC_NAME

To pošlje pravilno oblikovano CLDAP-zahtevo in poroča o odgovoru. Nadomestite DC_NAME z imenom vašega domenskega krmilnika.

Kot dodatno preverjanje lahko uporabite PortQry (brezplačno Microsoftovo orodje za ukazno vrstico) z drugega računalnika:

portqry -n SERVER_NAME -p UDP -e 389

Glede na odgovor lahko PortQry poroča o stanju LISTENING ali FILTERED. Upoštevajte, da PortQry pošlje preizkusni paket namesto popolnega CLDAP LDAP ping-a, storitev CLDAP pa ga morda ne prepozna kot veljavno zahtevo, zato lahko poroča FILTERED, tudi če je vrata odprta. Zaradi tega obravnavajte nltest /ping kot avtoritativni test, PortQry pa kot grobo dodatno preverjanje.

Na krmilniku domene preverite tudi, ali lokacija domene še vedno deluje za notranje odjemalce:

nltest /dsgetdc:example.com

Zamenjajte example.com z imenom vaše domene. Uspešen odgovor pomeni, da odjemalci še vedno lahko najdejo domenski krmilnik. Upoštevajte, da uspešen ukaz »dsgetdc« sam po sebi ne dokazuje, da CLDAP prek UDP deluje, saj se DC Locator lahko, odvisno od izvajane operacije, zateče k poizvedbam DNS in TCP LDAP, če CLDAP ni na voljo – zato je zgornji preizkus z ukazom »nltest /ping« bolj neposreden.

Dodatna priporočila

Poskrbite, da je Windows popolnoma posodobljen. Varnostne posodobitve odpravljajo kritične ranljivosti v sami implementaciji LDAP (kot so pomanjkljivosti, ki bi lahko omogočile oddaljeno izvajanje kode) in ščitijo strežnik pred zlorabo. To je ločena skrb od zlorabe refleksije – namestitev popravkov okrepi sam strežnik, medtem ko zgoraj opisano omejevanje požarnega zidu preprečuje, da bi bil strežnik uporabljen kot reflektor proti drugim.

Omogočite podpisovanje LDAP in vezavo kanalov na krmilnikih domene, da na splošno okrepite varnost LDAP.

Za volumetrično zaščito morata omejevanje hitrosti in filtriranje DDoS potekati na obrobnem požarnem zidu ali pri ponudniku na višji stopnji, ne pa na samem gostitelju sistema Windows.

Povzetek: kdaj je blokiranje UDP 389 primerno?

• Strežnik ni domenski krmilnik → ukrepi niso potrebni (UDP 389 ne posluša).
• Domenski krmilnik za požarnim zidom, ki ni izpostavljen internetu → ni potrebno ukrepati; ohranite ga izven javnega interneta.
• Domenski krmilnik, izpostavljen internetu → omejite pravilo tako, da blokira zunanje vire, hkrati pa ne vpliva na zaupanja vredna notranja podomrežja.