Miks keelata LLMNR, kui kasutate avalikku WiFi-ühendust?

LLMNR-protokoll on Microsofti keskkondades tuttav nägu. Võrkudes, kus Windows on peamine operatsioonisüsteem, on see vaikimisi lubatud ja kuigi see oli kunagi mõistlik, on see tänapäeval pigem peavalu kui abi. Seetõttu on hea teada, kuidas seda kasutada. kuidas LLMNR-i keelata eriti kui kasutame avalikku WiFi-võrku.

Enne otsuste langetamist on hea mõista, mida see teeb ja miks on soovitatav see keelata. Hea uudis on see, et selle keelamine on lihtne. nii Windowsis (sh Windows Serveris) kui ka Linuxis, kas poliitikate, registri, Intune'i või systemd-resolved'i häälestamise kaudu.

Mis on LLMNR ja kuidas see toimib?

LLMNR on lühend Lingi-kohaliku multisaate nimelahendusSelle eesmärk on lahendada hostinimesid kohalikus segmendis ilma DNS-serverile toetumataTeisisõnu, kui masin ei suuda nime DNS-i kaudu lahendada, saab see proovida naabruskonnalt multisaadet kasutades päringut teha, et näha, kas keegi "vihjest aru saab".

See mehhanism kasutab porti UDP 5355 ja on loodud töötama kohalikus võrgus. Päring saadetakse multisaate teel vahetu võrguga ja iga arvuti, mis nime „ära tunneb“, saab vastata, öeldes „see olen mina“. See on kiire ja lihtne lähenemisviis väikeste või improviseeritud keskkondade jaoks, kus DNS polnud saadaval või selle seadistamine polnud mõttekas.

Praktikas liigub LLMNR päring kohalikku segmenti ja seda liiklust kuulavad seadmed saavad vastata, kui nad usuvad, et nad on õige sihtkoht. Selle ulatus piirdub kohaliku lingiga, ja sellest ka selle nimi ning kutsumus „paigana“ olukorras, kus võrgus puudub ametlik nimeteenus.

Aastaid, eriti väiksemates võrkudes või ad-hoc juurutustes, osutus see kasulikuks. Tänapäeval on laialt levinud ja odav DNS, on kasutusjuhtum nii palju kitsenenud, et peaaegu alati on mõistlik LLMNR välja lülitada ja rahulikumalt elada.

Kas LLMNR on tõesti vajalik? Riskid ja kontekst

Miljoni dollari küsimus: kas peaksin selle maha võtma või alles jätma? Koduses keskkonnas on kõige levinum vastus "jah, võtke see julgelt maha". Ettevõttes on mugav mõju valideeridaKui keskkonna DNS on õigesti seadistatud ja otsingud toimivad, siis LLMNR ei paku midagi ja tekitab ebavajalikke riske.

Suurim probleem on see LLMNR ei sisalda kaitset isikuandmete võltsimise eestRündaja teie enda alamvõrgus saab sihtseadet "esitada" ja reageerida varem või eelisjärjekorras, suunates ühenduse ümber ja põhjustades kaost. See on klassikaline vanakooli "vahepealse mehe" (MitM) rünnaku stsenaarium.

Analoogiana meenutab see Wi-Fi WEP-standardit, mis sündis tänapäevaseid rünnakuid arvestamata ja on nüüdseks vananenud. Midagi sarnast juhtub ka LLMNR-igaSee oli minevikus kasulik, aga tänapäeval on see avatud uks pettusele, kui see ettevõtte võrkudes ellu jätta.

Lisaks saavad nad õigete tööriistadega vastase käes sundida teie arvuteid "laulma" tundlikku teavet, näiteks NTLMv2 räsi, kui nad arvavad, et suhtlevad legitiimse serveriga. Kui ründaja on need räsiväärtused kätte saanud, võivad proovida neid murda – erineva eduga, olenevalt poliitikatest ja parooli keerukusest –, suurendades seeläbi reaalse sissetungi ohtu.

Millal LLMNR keelata?

Enamikus tänapäevastes juurutustes saab selle keelata ilma midagi rikkumata. Kui teie kliendid lahendavad alati DNS-i abil Ja kui te ei looda kohalikus võrgus olevatele "maagiatele", on LLMNR üleliigne. Sellegipoolest valideerige poliitika enne kogu organisatsioonile levitamist kriitilistes keskkondades.

Pea meeles, et see otsus pole ainult tehniline: see vähendab ka sinu tegevusalast ja vastavusriski. LLMNR-i keelamine on lihtne, mõõdetav ja mõjus karastava kontrolli meede., just seda, mida iga mõistlik turvaraamistik nõuab.

Keela LLMNR Windowsis

Siin on peamised valikud LLMNR-i keelamiseks Windowsis:

1. variant: Kohaliku grupipoliitika redaktor (gpedit.msc)

Eraldiseisvates arvutites või kiireks testimiseks saate kasutada kohaliku grupipoliitika redaktorit. Vajutage WIN + R, tippige gpedit.msc ja nõustu selle avamisega.

Seejärel navigeeri järgmistes osades: Arvuti konfiguratsioon > Haldusmallid > VõrkMõnes väljaandes kuvatakse säte jaotises DNS-klient. Leidke kirje „Keela multisaate nimede lahendamine” (nimi võib veidi erineda) ja määrake poliitika väärtuseks „Lubatud“.

Windows 10-s loetakse teksti tavaliselt järgmiselt: „Keela multisaadetise nimelahendus”. Rakenda või nõustu muudatusega ja taaskäivita arvuti. et tagada meeskonnapoolsete sätete õige rakendamine.

2. variant: Windowsi register

Kui eelistate otse asja juurde minna või vajate skriptitavat meetodit, saate poliitika väärtuse registris luua. Ava CMD või PowerShell administraatori õigustega ja teostada:

REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /f
REG ADD "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /v "EnableMulticast" /t REG_DWORD /d 0 /f

Sellega keelatakse LLMNR poliitika tasandil. Tsükli sulgemiseks taaskäivitage arvuti ja takistada varasema olekuga protsesside mällu jäämist.

Keela LLMNR domeenis GPO abil

Teine viis LLMNR-i keelamiseks on muudatuse rakendamine domeenikontrolleri kaudu tsentraalselt, avades grupipoliitika halduskonsooli. Loo uus GPO (näiteks „MY-GPO”) ja redigeeri seda.

Redaktoris järgige teed: Arvuti konfiguratsioon > Administratiivmallid > Võrk > DNS-klient. Luba poliitika „Keela multisaadetise nimelahendus” ja sulgege redaktor salvestamiseks. Seejärel linkige rühmapoliitika objekt sobiva OU-ga ja sundige poliitikat värskendama või oodake tavapärast replikatsiooni.

Valmis. Nüüd on teil domeenipoliitika, mis järjekindlalt LLMNR-i katkestab. Pidage meeles, et korrigeerimise täpne nomenklatuur võib erineda. Windows Serveri versioonide vahel veidi erinev, kuid asukoht on näidatud.

Intune: „Rakendati”, aga gpedit kuvab „Pole konfigureeritud”

Levinud küsimus: kui Intune'ist konfiguratsiooniprofiili laadid, siis see ütleb sulle, et see rakendati õigesti, aga gpedit'i avades näed sätet „Pole konfigureeritud”. See ei tähenda tingimata, et see pole aktiivne.Intune rakendab CSP/registri kaudu sätteid, mis ei kajastu kohalikus redaktoris alati olekus „Konfigureeritud“.

Selle kontrollimiseks on kõige usaldusväärsem viis vaadata poliitikalogi: Kui see on olemas ja võrdne 0-ga, siis väärtus Luba multisaade sisse lülitatud HKLM\Tarkvara\Poliitikad\Microsoft\Windows NT\DNSClient, LLMNR on keelatud, kuigi gpedit kuvab teadet „Pole konfigureeritud”.

Kui eelistate seda skripti abil tagada (kasulik nagu Intune'i parandus), on siin lihtne PowerShelli skript väärtuse loomiseks ja kontrollimiseks:

New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient" -Name "EnableMulticast" -PropertyType DWord -Value 0 -Force | Out-Null
(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

See hõlmab juhtumit, kus Intune väidab, et seda rakendati, kuid soovite maksimaalset kindlust või tõrkeotsingut „petturlike” seadmete puhul. Hulgiauditeerimiseks ühendage skript oma inventuuri tööriistaga või Intune'i/Defenderi abil lõpp-punkti aruannete jaoks.

Keela LLMNR Linuxis (systemd-lahendusega)

Selliste distributsioonide nagu Ubuntu või Debian puhul, mis kasutavad systemd-resolved'i, saate LLMNR-i otse "tappa". Resolveri sätete muutmine Niisiis:

sudo nano /etc/systemd/resolved.conf

Failis määrake vastav parameeter nii, et see oleks üheselt mõistetav. Näiteks:

[Resolve]
LLMNR=no

Salvesta ja taaskäivita teenus või arvuti: Teenuse taaskäivitamisest piisab tavaliselt, kuigi taaskäivitamine on samuti kehtiv, kui see on teile mugavam.

sudo systemctl restart systemd-resolved

Sellega lõpetab systemd-resolved LLMNR-i kasutamise. Kui kasutate mõnda muud lahendust (või teiste distributsioonide) puhul kontrollige nende dokumentatsiooni: muster ei erine liiga palju ja alati on olemas samaväärne „lüliti“.

Teave NBT-NS ja Windowsi tulemüüri kohta

LLMNR-i keelamine on pool võitu. Responder ja sarnased tööriistad kasutavad ära ka NetBIOS-i nimeteenust (NBT-NS)., mis töötab klassikaliste NetBIOS-portide (UDP 137/138 ja TCP 139) kaudu. See tõstatab küsimuse, mida paljud inimesed küsivad: kas piisab portide blokeerimisest tulemüüris või tuleb NBT-NS selgesõnaliselt keelata?

Kui rakendate oma kohalikus tulemüüris rangeid reegleid – nii sissetulevat kui ka väljaminevat –, mis blokeerivad 137/UDP, 138/UDP ja 139/TCP, vähendate oluliselt oma kokkupuudet rünnakutega. Ettevõttekeskkondades on parim tava NetBIOS TCP/IP kaudu keelata. liidestes soovimatute vastuste või reklaamide vältimiseks, kui tulemüüripoliitika muutub või rakendus seda muudab.

Windowsis pole nii otsest „tehase” rühmapoliitika objekti nagu LLMNR-is, aga seda saab teha WMI või registri kaudu. See WMI-põhine PowerShell keelab selle kõigil IP-toega adapteritel.:

Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter "IPEnabled=TRUE" | ForEach-Object { $_.SetTcpipNetbios(2) } 

Kui eelistate tulemüürireegleid, siis tehke seda, aga veenduge, et need oleksid kahesuunalised ja püsivad. Plokid 137/UDP, 138/UDP ja 139/TCP ja jälgib, et teistes tulemüüri haldavates rühmapoliitika objektides või EDR/AV-lahendustes ei oleks vastuolulisi reegleid.

Kontrollimine: kuidas kontrollida, et LLMNR ja NBT-NS on mängust väljas

LLMNR-i kohta Windowsis vaadake registrit: HKLM\Tarkvara\Poliitikad\Microsoft\Windows NT\DNSClient\EnableMulticast peab eksisteerima ja olema võrdne 0-ga. Kiire kontroll PowerShellis oleks:

(Get-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\DNSClient").EnableMulticast

Liikluse tasandil on lihtne tehnika otsida olematut nime ja kasutada Wiresharki, et jälgida, et UDP 5355 pakette ei väljastataks. Kui te ei näe multisaadet kohalikku segmenti, oled õigel teel.

Linuxis, kus on systemd-resolved, kontrollige olekut resolvectl või systemctl abil: Veenduge, et LLMNR on seatud väärtusele „ei“ kehtivas konfiguratsioonis ja et teenus taaskäivitati ilma vigadeta.

NBT-NS puhul veenduge, et teie tulemüürireeglid blokeerivad 137/UDP, 138/UDP ja 139/TCP või et NetBIOS on adapteritel keelatud. Samuti võid mõnda aega netti nuusutada et kontrollida, kas eetris pole NetBIOS-i päringuid ega reklaame.

Korduma kippuvad küsimused ja kasulikud nüansid

• Kas LLMNR-i keelamine rikub midagi? Hästi hooldatud DNS-iga võrkudes see tavaliselt nii ei ole. Spetsiaalsetes või pärandkeskkondades valideerige esmalt pilootgrupis ja edastage muudatus tugiteenusele.
• Miks gpedit kuvab teadet „Pole konfigureeritud”, kuigi Intune’i teade on „Jungitud”? Sest kohalik redaktor ei kajasta alati MDM-i või CSP poolt määratud olekuid. Tõde peitub registris ja tegelikes tulemustes, mitte gpedit-tekstis.
• Kas NBT-NS-i keelamine on kohustuslik, kui ma tulemüüril NetBIOS-i blokeerin? Kui blokeerimine on täielik ja kindel, vähendate riski oluliselt. NetBIOS-i keelamine TCP/IP kaudu kõrvaldab siiski pinu tasemel vastused ja väldib üllatusi reeglite muutumisel, seega on see eelistatud valik.
• Kas LLMNR-i keelamiseks on olemas valmis skripte? Jah, nagu olete näinud, registri või PowerShelli kaudu. Intune'i puhul pakkige skript paranduspaketina ja lisage vastavuskontroll.

LLMNR-i väljalülitamine vähendab kohalikus võrgus võltsimispinda ja peatab räsi haaramise rünnakud selliste tööriistadega nagu Responder juba eos. Kui blokeerite või keelate ka NBT-NS-i ja hoolitsete oma DNS-i eestTeil on lihtne ja tõhus turvakokteil: vähem müra, vähem riski ja võrk, mis on igapäevaseks kasutamiseks palju paremini ette valmistatud.