Kial malŝalti LLMNR se vi uzas publikan Wifi-on?

La protokolo LLMNR estas konata vizaĝo en Microsoft-medioj. En retoj kie Vindozo estas la ĉefa subteno, ĝi estas ebligita defaŭlte, kaj kvankam ĝi iam havis sencon, hodiaŭ ĝi ofte estas pli kapdoloro ol helpo. Tial estas bone scii kiel uzi ĝin. kiel malŝalti LLMNR precipe se ni uzas publikan WiFi-reton.

Antaŭ ol fari iujn ajn decidojn, estas bone kompreni, kion ĝi faras kaj kial rekomendas malŝalti ĝin. La bona novaĵo estas, ke malŝalti ĝin estas facile. kaj en Vindozo (inkluzive de Windows Server) kaj en Linukso, ĉu per politikoj, Registro, Intune, aŭ per agordado de systemd-resolved.

Kio estas LLMNR kaj kiel ĝi funkcias?

LLMNR estas la inicialoj de Lig-loka plurdissenda nomrezolucioĜia celo estas solvi gastignomojn ene de la loka segmento sen dependi de DNS-serviloAlivorte, se maŝino ne povas solvi nomon per DNS, ĝi povas provi pridemandi la najbarecon uzante plurdissendadon por vidi ĉu iu "komprenas la sugeston".

Ĉi tiu mekanismo uzas la havenon UDP 5355 kaj estas desegnita por funkcii ene de la loka reto. La demando estas sendita per multdissendo al la tuja reto, kaj ĉiu komputilo kiu "rekonas" la nomon povas respondi dirante "tio estas mi." Ĉi tio estas rapida kaj simpla aliro por malgrandaj aŭ improvizitaj medioj kie DNS ne estis havebla aŭ ne havis sencon agordi.

En praktiko, la LLMNR-demando vojaĝas al la loka segmento, kaj aparatoj aŭskultantaj tiun trafikon povas respondi se ili kredas, ke ili estas la ĝusta celloko. Ĝia amplekso estas limigita al la loka ligo, kaj tial ĝia nomo kaj ĝia vivokupo kiel "peceto" kiam ne ekzistas formala nomservo en la reto.

Dum jaroj, precipe en pli malgrandaj retoj aŭ ad-hoc deplojoj, ĝi pruviĝis utila. Nuntempe, kun vasta kaj malmultekosta DNS, la uzkazo tiom mallarĝiĝis, ke preskaŭ ĉiam estas logike malŝalti LLMNR kaj vivi pli pace.

Ĉu la LLMNR vere necesas? Riskoj kaj kunteksto

La demando je miliono da dolaroj: ĉu mi deprenu ĝin aŭ lasu ĝin? En hejma medio, la plej ofta respondo estas "jes, bonvolu depreni ĝin." En firmao estas oportune validigi efikonSe la DNS de la ĉirkaŭaĵo estas ĝuste agordita kaj serĉoj funkcias, LLMNR provizas nenion kaj malkaŝas nenecesajn riskojn.

La plej granda problemo estas, ke LLMNR ne inkluzivas protekton kontraŭ imitadoAtakanto en via propra subreto povas "ŝajnigi esti" la cela aparato kaj respondi frue aŭ prefere, redirektante la konekton kaj kaŭzante kaoson. Ĝi estas klasika malnovmoda "homo-en-la-meza" (MitM) atakoscenaro.

Kiel analogecon, ĝi memorigas pri la normo Wi-Fi WEP, kiu naskiĝis sen konsideri modernajn atakojn kaj fariĝis malaktuala. Io simila okazas kun LLMNRĜi estis utila en la pasinteco, sed hodiaŭ ĝi estas malferma pordo al trompo se vi lasas ĝin viva en entreprenaj retoj.

Plie, en la manoj de malamiko kun la ĝustaj iloj, ili povas devigi viajn komputilojn "kanti" sentemajn informojn kiel NTLMv2-haŝojn kiam ili pensas, ke ili parolas al legitima servilo. Post kiam la atakanto akiras tiujn haŝojn, povas provi fendi ilin — kun varia sukceso depende de politikoj kaj la komplekseco de pasvortoj — pliigante la riskon de vera entrudiĝo.

Kiam malŝalti LLMNR?

En la vasta plimulto de modernaj deplojoj, vi povas malŝalti ĝin sen rompi ion ajn. Se viaj klientoj ĉiam solvas per DNS Kaj se vi ne fidas je "magio" en la loka reto, LLMNR estas superflua. Tamen, validigu en kritikaj medioj antaŭ ol puŝi la politikon al la tuta organizo.

Memoru, ke la decido ne estas nur teknika: ĝi ankaŭ reduktas vian funkcian kaj plenuman riskon. Malŝalti LLMNR estas simpla, mezurebla kaj efika hardiga kontrolo., ĝuste tion postulas ĉiu ajn prudenta sekureca kadro.

Malŝalti LLMNR en Vindozo

Jen la ĉefaj disponeblaj ebloj por malebligi LLMNR en Vindozo:

Opcio 1: Redaktilo de Lokaj Grupaj Politikoj (gpedit.msc)

Sur memstaraj komputiloj aŭ por rapida testado, vi povas uzi la Redaktilon de Lokaj Grupaj Politikoj. Premu WIN + R, tajpu gpedit.msc kaj akceptu por malfermi ĝin.

Poste, navigu tra: Komputila Agordo > Administraj Ŝablonoj > RetoEn iuj eldonoj, la scenaro aperas sub DNS-kliento. Trovu la eniron "Malŝalti plurdissendilon de nomo" (la nomo povas iomete varii) kaj agordu la politikon al "Ebligita".

En Vindozo 10 la teksto kutime legiĝas kiel "Malŝalti plurdissendan nomrezolucion." Apliku aŭ akceptu la ŝanĝon kaj rekomencu vian komputilon. por certigi, ke la teamflankaj agordoj estas ĝuste aplikitaj.

Opcio 2: Vindoza Registro

Se vi preferas iri rekte al la afero aŭ bezonas skripteblan metodon, vi povas krei la strategivaloron en la Registro. Malfermu CMD aŭ PowerShell kun administrantaj permesoj kaj efektivigu:

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

Per tio, LLMNR estos malŝaltita je la strategionivelo. Rekomencu la komputilon por fermi la ciklon kaj malhelpi ke procezoj kun antaŭa stato restu en la memoro.

Malŝalti LLMNR per GPO en domajno

Alia maniero malŝalti LLMNR estas apliki la ŝanĝon centre de domajna regilo malfermante la Grupan Politikadministran Konzolon. Krei novan GPO-on (ekzemple, “MIA-GPO”) kaj redakti ĝin.

En la redaktilo, sekvu la jenan vojon: Komputila Agordo > Administraj Ŝablonoj > Reto > DNS-Kliento. Ebligi la politikon "Malŝalti plurdisdonan nomrezolucion" kaj fermu la redaktilon por konservi. Poste, ligu la GPO-on al la taŭga OU kaj devigu la refreŝigon de la politiko aŭ atendu normalan replikadon.

Finita. Vi nun havas domajnan politikon kiu konstante reduktas LLMNR-on. Memoru, ke la preciza nomenklaturo de la alĝustigo povas varii. iomete inter versioj de Windows Server, sed la loko estas kiel indikite.

Intune: "Aplikita" sed gpedit montras "Ne Agordita"

Ofta demando: vi puŝas agordan profilon el Intune, ĝi diras al vi, ke ĝi estis aplikita ĝuste, kaj kiam vi malfermas gpedit, vi vidas la agordon kiel "Ne Agordita". Tio ne nepre signifas, ke ĝi ne estas aktiva.Intune aplikas agordojn per CSP/Registry, kiuj ne ĉiam estas reflektitaj en la loka redaktilo kiel "Agorditaj".

La fidinda maniero kontroli tion estas konsulti la Strategian Registron: Se ĝi ekzistas kaj egalas al 0, la valoro Ebligi Multelsendon ŝaltita HKLM\Programaro\Politikoj\Microsoft\Windows NT\DNSClient, LLMNR estas malŝaltita kvankam gpedit montras "Ne konfigurita".

Se vi preferas certigi tion per skripto (utila kiel Remediation en Intune), jen simpla PowerShell-skripto por krei la valoron kaj kontroli ĝin:

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

Ĉi tio kovras la kazon, kie Intune diras, ke ĝi estis aplikita, sed vi volas maksimuman certecon aŭ solvi problemojn pri "friponaj" aparatoj. Por amase kontroli, kombinu la skripton kun via stokregistrilo aŭ kun raportoj de Intune/Defender por Finpunktoj.

Malŝalti LLMNR en Linukso (solvita de systemd)

En distribuaĵoj kiel Ubuntu aŭ Debian, kiuj uzas systemd-solvitan, vi povas rekte "mortigi" LLMNR. Redakti la agordojn de la solvilo Do:

sudo nano /etc/systemd/resolved.conf

En la dosiero, agordu la respondan parametron tiel ke ĝi estas nedubebla. Ekzemple:

[Resolve]
LLMNR=no

Konservu kaj rekomencu la servon aŭ komputilon: Rekomenci la servon kutime sufiĉas, kvankam restartigo ankaŭ validas se ĝi estas pli oportuna por vi.

sudo systemctl restart systemd-resolved

Kun tio, systemd-resolved ĉesos uzi LLMNR. Se vi uzas alian solvon (aŭ aliaj distribuaĵoj), kontrolu ilian dokumentaron: la ŝablono ne tro diferencas kaj ĉiam ekzistas ekvivalenta "ŝaltilo".

Pri NBT-NS kaj Vindoza Fajromuro

Malŝalti LLMNR estas duono de la batalo. Respondilo kaj similaj iloj ankaŭ ekspluatas NetBIOS-nomservon (NBT-NS), kiu funkcias per klasikaj NetBIOS-pordoj (UDP 137/138 kaj TCP 139). Tio levas la demandon, kiun multaj homoj faras: ĉu sufiĉas bloki pordojn en la fajromuro, aŭ ĉu oni devas eksplicite malŝalti NBT-NS?

Se vi aplikas striktajn regulojn al via loka fajromuro — kaj alvenantan kaj elirantan — blokante 137/UDP, 138/UDP, kaj 139/TCP, vi multe reduktas vian riskon. Tamen, plej bona praktiko en entreprenaj medioj estas malŝalti NetBIOS super TCP/IP. en interfacoj, por malhelpi nedeziratajn respondojn aŭ reklamojn se la fajromurpolitiko ŝanĝiĝas aŭ estas modifita de aplikaĵo.

En Vindozo, ne ekzistas "fabrika" GPO tiel rekta kiel en LLMNR, sed vi povas fari ĝin per WMI aŭ Registro. Ĉi tiu WMI-bazita PowerShell malŝaltas ĝin ĉe ĉiuj IP-ebligitaj adaptiloj:

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

Se vi preferas regulojn pri fajromuro, daŭrigu, sed certigu, ke ili estas dudirektaj kaj konstantaj. Blokoj 137/UDP, 138/UDP kaj 139/TCP kaj kontrolas, ke ne ekzistas konfliktaj reguloj en aliaj GPO-oj aŭ EDR/AV-solvoj, kiuj administras la fajromuron.

Konfirmo: Kiel kontroli, ke LLMNR kaj NBT-NS ne plu funkcias

Por LLMNR en Vindozo, rigardu la Registron: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast devas ekzisti kaj egali al 0. Rapida Kontrolo en PowerShell Mi estus:

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

Je la trafiknivelo, simpla tekniko estas serĉi neekzistantan nomon kaj uzi Wireshark por observi, ke neniuj UDP 5355-pakaĵetoj estas eligitaj. Se vi ne vidas plurelsendon al la loka segmento, vi estas sur la ĝusta vojo.

En Linukso kun systemd-resolved, kontrolu la staton per resolvectl aŭ systemctl: Certigu, ke LLMNR estas agordita al "ne" en la efika agordo kaj ke la servo estis rekomencita sen eraroj.

Por NBT-NS, konfirmu, ke viaj fajromuraj reguloj blokas 137/UDP, 138/UDP, kaj 139/TCP aŭ ke NetBIOS estas malŝaltita sur la adaptiloj. Vi ankaŭ povas flari la reton por iom da tempo por kontroli, ke ne estas NetBIOS-petoj aŭ reklamoj en la aero.

Oftaj demandoj kaj utilaj nuancoj

• Ĉu mi ion rompos malŝaltante LLMNR? En retoj kun bone prizorgata DNS, tio tipe ne okazas. En specialaj aŭ heredaĵaj medioj, unue validigu en pilotgrupo kaj komuniku la ŝanĝon al subteno.
• Kial gpedit montras "Ne Agordita" kvankam Intune diras "Devigita"? Ĉar la loka redaktilo ne ĉiam reflektas statojn truditajn de MDM aŭ CSP. La vero estas en la Registro kaj la faktaj rezultoj, ne en la gpedit-teksto.
• Ĉu estas devige malŝalti NBT-NS se mi blokas NetBIOS ĉe la fajromuro? Se la blokado estas kompleta kaj fortika, vi multe reduktas la riskon. Tamen, malŝalti NetBIOS per TCP/IP forigas staknivelajn respondojn kaj evitas surprizojn se la reguloj ŝanĝiĝas, do ĝi estas la preferinda opcio.
• Ĉu ekzistas iuj skriptoj pretaj por malŝalti LLMNR? Jes, per Registro aŭ PowerShell, kiel vi vidis. Por Intune, pakigu la skripton kiel Riparadon kaj aldonu konformecan kontrolon.

Malŝalti LLMNR reduktas la falsan surfacon en la loka reto kaj tuj malhelpas haŝkaperajn atakojn per iloj kiel Responder. Se vi ankaŭ blokas aŭ malŝaltas NBT-NS kaj prizorgas vian DNS-onVi havos simplan kaj efikan sekurecan koktelon: malpli da bruo, malpli da risko, kaj reton multe pli bone preparitan por ĉiutaga uzo.