Wêrom LLMNR útskeakelje as jo iepenbiere Wi-Fi brûke?

It LLMNR-protokol is in bekend gesicht yn Microsoft-omjouwings. Yn netwurken dêr't Windows de steunpilaar is, is it standert ynskeakele, en hoewol it eartiids sin hie, is it hjoed faak mear in hoofdpijn as in help. Dêrom is it in goed idee om te witten hoe't jo it brûke moatte. hoe LLMNR útskeakelje foaral as wy in iepenbier WiFi-netwurk brûke.

Foardat jo besluten nimme, is it in goed idee om te begripen wat it docht en wêrom it oan te rieden is om it út te skeakeljen. It goede nijs is dat it útskeakeljen maklik is. op sawol Windows (ynklusyf Windows Server) as Linux, fia belied, Registry, Intune, of troch it ôfstimmen fan systemd-resolved.

Wat is LLMNR en hoe wurket it?

LLMNR is it akronym foar Link-Lokale Multicast Namme-resolúsjeIt doel dêrfan is hostnammen binnen it lokale segmint oplosse sûnder te fertrouwen op in DNS-tsjinnerMei oare wurden, as in masine in namme net fia DNS oplosse kin, kin it besykje de buert te freegjen mei multicast om te sjen oft immen "de hint begrypt".

Dit meganisme brûkt de haven UDP 5355 en is ûntworpen om te operearjen binnen it lokale netwurk. De fraach wurdt ferstjoerd fia multicast nei it direkte netwurk, en elke kompjûter dy't de namme "herkent" kin reagearje troch te sizzen "dat bin ik". Dit is in rappe en ienfâldige oanpak foar lytse of ymprovisearre omjouwings wêr't DNS net beskikber wie of gjin sin hie om te konfigurearjen.

Yn 'e praktyk reizget de LLMNR-fraach nei it lokale segmint, en apparaten dy't nei dat ferkear harkje kinne reagearje as se leauwe dat se de juste bestimming binne. Syn omfang is beheind ta de lokale keppeling, en dêrfandinne syn namme en syn ropping as in "patch" as der gjin formele nammetsjinst op it netwurk is.

Jierrenlang, foaral yn lytsere netwurken of ad-hoc-ynstallaasjes, bliek it nuttich. Tsjintwurdich, mei wiidfersprate en goedkeape DNS, it gebrûksgefal is sa beheind dat it hast altyd sin hat om LLMNR út te skeakeljen en freedsumer te libjen.

Is de LLMNR echt needsaaklik? Risiko's en kontekst

De fraach fan in miljoen dollar: moat ik it delhelje of litte? Yn in húshâldlike omjouwing is it meast foarkommende antwurd "ja, fiel jo frij om it del te heljen." Yn in bedriuw is it handich om ynfloed te falidearjenAs de DNS fan 'e omjouwing goed ynsteld is en sykaksjes wurkje, leveret LLMNR neat en stelt it ûnnedige risiko's bleat.

It grutste probleem is dat LLMNR befettet gjin beskerming tsjin imitaasjeIn oanfaller op jo eigen subnet kin it doelapparaat "imitearje" en betiid of mei foarkar reagearje, wêrtroch't de ferbining omlaat wurdt en gaos feroarsake wurdt. It is in klassike âlderwetske "man-in-the-middle" (MitM) oanfalsscenario.

As analogy docht tinken oan 'e Wi-Fi WEP-standert, dy't ûntstie sûnder rekken te hâlden mei moderne oanfallen en ferâldere rekke is. Der bart wat ferlykbers mei LLMNRIt wie yn it ferline nuttich, mar hjoed is it in iepen doar foar ferrifeljen as jo it yn libben litte op bedriuwsnetwurken.

Derneist kinne se, yn 'e hannen fan in tsjinstanner mei de juste ark, jo kompjûters twinge om gefoelige ynformaasje lykas NTLMv2-hashes te "sjongen" as se tinke dat se mei in legitime server prate. Sadree't de oanfaller dy hashes krijt, kinne besykje se te kraken - mei wikseljend súkses ôfhinklik fan belied en wachtwurdkompleksiteit - wêrtroch it risiko op in echte ynbraak tanimt.

Wannear moat LLMNR útskeakele wurde?

Yn 'e grutte mearderheid fan moderne ynstallaasjes kinne jo it útskeakelje sûnder wat te brekken. As jo ​​kliïnten altyd oplosse fia DNS En as jo net fertrouwe op "magy" op it lokale netwurk, is LLMNR oerstallich. Falidearje dochs yn krityske omjouwings foardat jo it belied nei de hiele organisaasje trochjaan.

Hâld der rekken mei dat de beslissing net allinich technysk is: it ferminderet ek jo operasjonele en neilibingsrisiko. It útskeakeljen fan LLMNR is in ienfâldige, mjitbere en ynfloedrike ferhurdingskontrôle., krekt wat elk ferstannich feiligensraamwurk freget.

LLMNR útskeakelje yn Windows

Hjir binne de wichtichste opsjes beskikber om LLMNR yn Windows út te skeakeljen:

Opsje 1: Lokale groepsbeliedseditor (gpedit.msc)

Op standalone kompjûters of foar flugge testen kinne jo de Local Group Policy Editor brûke. Druk op WIN + R, typ gpedit.msc en akseptearje om it te iepenjen.

Navigearje dan troch: Kompjûterkonfiguraasje > Behearsjabloanen > NetwurkYn guon edysjes ferskynt de ynstelling ûnder DNS-kliïnt. Sykje de yngong "Utskeakelje multicast-namme-resolúsje" (namme kin wat ferskille) en stel it belied yn op "Ynskeakele".

Yn Windows 10 wurdt de tekst meastentiids lêzen as "Multicast-namme-resolúsje útskeakelje". Tapasse of akseptearje de feroaring en start jo kompjûter op 'e nij. om te soargjen dat de ynstellings oan 'e teamkant korrekt tapast wurde.

Opsje 2: Windows-register

As jo ​​leaver direkt nei it punt komme wolle of in skriptbere metoade nedich binne, kinne jo de beliedswearde yn it register oanmeitsje. Iepenje CMD of PowerShell mei tagongsrjochten foar behearders en útfiere:

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

Hjirmei sil LLMNR útskeakele wurde op beliedsnivo. Start de kompjûter opnij om de syklus te sluten en foarkomme dat prosessen mei in eardere steat yn it ûnthâld bliuwe.

LLMNR útskeakelje mei GPO yn in domein

In oare manier om LLMNR út te skeakeljen is om de feroaring sintraal ta te passen fanút in domeincontroller troch de Groepsbeliedbehearkonsole te iepenjen. Meitsje in nij GPO oan (bygelyks "MY-GPO") en bewurkje it.

Folgje yn 'e bewurker it paad: Kompjûterkonfiguraasje > Behearsjabloanen > Netwurk > DNS-kliïnt. Skeakelje it belied "Multicast-namme-resolúsje útskeakelje" yn en slút de bewurker om op te slaan. Ferbine dan it GPO mei de passende OU en twinge de beliedsferfarsking of wachtsje op normale replikaasje.

Klear. Jo hawwe no in domeinbelied dat LLMNR konsekwint ferminderet. Tink derom dat de krekte nomenklatuer fan 'e oanpassing kin ferskille. in bytsje tusken ferzjes fan Windows Server, mar de lokaasje is lykas oanjûn.

Intune: "Tapast", mar gpedit lit "Net konfigurearre" sjen

In faak stelde fraach: jo stjoere in konfiguraasjeprofyl fanút Intune, it fertelt jo dat it korrekt tapast is, en as jo gpedit iepenje, sjogge jo de ynstelling as "Net konfigurearre". Dit betsjut net needsaaklik dat it net aktyf is.Intune past ynstellings ta fia CSP/Registry dy't net altyd werjûn wurde yn 'e lokale bewurker as "Konfigurearre".

De betroubere manier om dit te kontrolearjen is om it Beleidslogboek te rieplachtsjen: As it bestiet en gelyk is oan 0, dan is de wearde Multicast ynskeakelje HKLM\Software\Beleid\Microsoft\Windows NT\DNSClient, LLMNR is útskeakele, ek al toant gpedit "Net konfigurearre".

As jo ​​dit leaver fia in skript garandearje wolle (nuttich lykas Remediation yn Intune), is hjir in ienfâldich PowerShell-skript om de wearde te meitsjen en te ferifiearjen:

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

Dit omfettet it gefal wêr't Intune seit dat it tapast is, mar jo wolle maksimale wissichheid of problemen mei "rogue" apparaten oplosse wolle. Om yn bulk te kontrolearjen, kombinearje it skript mei jo ynventarisaasjetool of mei Intune/Defender foar Endpoint-rapporten.

LLMNR útskeakelje op Linux (systemd-oplost)

Op distribúsjes lykas Ubuntu of Debian dy't systemd-resolved brûke, kinne jo LLMNR direkt "deadzje". Bewurkje de resolver-ynstellings Sa:

sudo nano /etc/systemd/resolved.conf

Yn it bestân, stel de oerienkommende parameter yn sadat it ûndûbelsinnich is. Bygelyks:

[Resolve]
LLMNR=no

Bewarje en start de tsjinst of kompjûter opnij op: It opnij starten fan 'e tsjinst is meastentiids genôch, hoewol in opnij starte ek jildich is as it handiger foar jo is.

sudo systemctl restart systemd-resolved

Dêrmei sil systemd-resolved ophâlde mei it brûken fan LLMNR. As jo ​​in oare resolúsje-oplossing brûke (of oare distribúsjes), kontrolearje har dokumintaasje: it patroan ferskilt net tefolle en d'r is altyd in lykweardige "switch".

Oer NBT-NS en Windows Firewall

It útskeakeljen fan LLMNR is de helte fan 'e striid. Responder en ferlykbere ark meitsje ek gebrûk fan NetBIOS Name Service (NBT-NS), dy't wurket oer klassike NetBIOS-poarten (UDP 137/138 en TCP 139). Dit ropt de fraach op dy't in protte minsken stelle: is it genôch om poarten yn 'e firewall te blokkearjen, of moatte jo NBT-NS eksplisyt útskeakelje?

As jo ​​strange regels tapasse op jo lokale firewall - sawol ynkommende as útgeande - dy't 137/UDP, 138/UDP en 139/TCP blokkearje, ferminderje jo jo bleatstelling sterk. De bêste praktyk yn bedriuwsomjouwings is lykwols om NetBIOS oer TCP/IP út te skeakeljen. yn ynterfaces, om net winske reaksjes of advertinsjes te foarkommen as it firewallbelied feroaret of wurdt oanpast troch in applikaasje.

Yn Windows is der gjin "fabryk" GPO sa direkt as yn LLMNR, mar jo kinne it dwaan fia WMI of Registry. Dizze WMI-basearre PowerShell skeakelt it út op alle IP-ynskeakele adapters:

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

As jo ​​firewallregels leaver hawwe, gean dan fierder, mar soargje derfoar dat se bidireksjoneel en persistent binne. Blokken 137/UDP, 138/UDP en 139/TCP en hâldt tafersjoch dat der gjin tsjinstridige regels binne yn oare GPO's of EDR/AV-oplossingen dy't de firewall beheare.

Ferifikaasje: Hoe kinne jo kontrolearje dat LLMNR en NBT-NS net yn gebrûk binne

Foar LLMNR op Windows, sjoch nei it register: HKLM\Software\Beleid\Microsoft\Windows NT\DNSClient\EnableMulticast moat bestean en gelyk wêze oan 0. Fluch kontrolearje yn PowerShell soe wêze:

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

Op ferkearsnivo is in ienfâldige technyk om in sykaksje út te fieren nei in net-besteande namme en Wireshark te brûken om te observearjen dat gjin UDP 5355-pakketten wurde útfierd. As jo ​​gjin multicast nei it lokale segmint sjogge, do bist op it goede spoar.

Op Linux mei systemd-resolved, kontrolearje de status mei resolvectl of systemctl: Soargje derfoar dat LLMNR ynsteld is op "nee" yn 'e effektive konfiguraasje en dat de tsjinst sûnder flaters op 'e nij starte is.

Foar NBT-NS, befêstigje dat jo firewallregels 137/UDP, 138/UDP en 139/TCP blokkearje of dat NetBIOS útskeakele is op 'e adapters. Jo kinne ek in skoftke oan it net snuffelje om te kontrolearjen dat der gjin NetBIOS-oanfragen of advertinsjes yn 'e loft binne.

Faak stelde fragen en nuttige nuânses

• Sil ik wat ferneatigje troch LLMNR út te skeakeljen? Yn netwurken mei goed ûnderhâlden DNS is dit meastal net it gefal. Yn spesjale of âlde omjouwings, falidearje earst yn in pilotgroep en kommunisearje de feroaring oan stipe.
• Wêrom toant gpedit "Net konfigurearre" sels as Intune "Hânhavene" seit? Omdat de lokale bewurker net altyd de steaten wjerspegelet dy't oplein binne troch MDM of CSP. De wierheid leit yn it register en de werklike resultaten, net yn 'e gpedit-tekst.
• Is it ferplicht om NBT-NS út te skeakeljen as ik NetBIOS op 'e firewall blokkearje? As de blokkearring folslein en robúst is, ferminderje jo it risiko sterk. Dochs elimineert it útskeakeljen fan NetBIOS oer TCP/IP antwurden op stacknivo en foarkomt ferrassingen as de regels feroarje, dus it is de foarkar opsje.
• Binne der skripts klear om LLMNR út te skeakeljen? Ja, fia it register of PowerShell, lykas jo sjoen hawwe. Foar Intune, pak it skript yn as Remediation en foegje neilibingskontrôle ta.

It útskeakeljen fan LLMNR ferminderet it spoofing-oerflak op it lokale netwurk en ûnderdrukt hash-grabbing-oanfallen mei ark lykas Responder yn 'e kiem. As jo ​​ek NBT-NS blokkearje of útskeakelje en jo DNS fersoargjeJo sille in ienfâldige en effektive befeiligingscocktail hawwe: minder lûd, minder risiko, en in netwurk dat folle better taret is op deistich gebrûk.