Varför inaktivera LLMNR om du använder offentligt Wi-Fi?

LLMNR-protokollet är ett välbekant ansikte i Microsoft-miljöer. I nätverk där Windows är den vanligaste funktionaliteten är det aktiverat som standard, och även om det en gång var logiskt är det idag ofta mer av en huvudvärk än en hjälp. Därför är det en bra idé att veta hur man använder det. hur man inaktiverar LLMNR särskilt om vi använder ett offentligt WiFi-nätverk.

Innan du fattar några beslut är det en bra idé att förstå vad den gör och varför det rekommenderas att inaktivera den. Den goda nyheten är att det är enkelt att inaktivera det. på både Windows (inklusive Windows Server) och Linux, antingen via policyer, registret, Intune eller genom att finjustera systemd-löst.

Vad är LLMNR och hur fungerar det?

LLMNR är initialerna till Länklokal multicast-namnupplösningDess syfte är matcha värdnamn inom det lokala segmentet utan att förlita sig på en DNS-serverMed andra ord, om en maskin inte kan matcha ett namn via DNS, kan den försöka fråga grannskapet med hjälp av multicast för att se om någon "förstår ledtråden".

Denna mekanism använder porten UDP 5355 och är utformad för att fungera inom det lokala nätverket. Frågan skickas via multicast till det omedelbara nätverket, och vilken dator som helst som "känner igen" namnet kan svara genom att säga "det är jag". Detta är en snabb och enkel metod för små eller improviserade miljöer där DNS inte var tillgängligt eller inte var meningsfullt att konfigurera.

I praktiken går LLMNR-frågan till det lokala segmentet, och enheter som lyssnar på den trafiken kan svara om de tror att de är rätt destination. Dess omfattning är begränsad till den lokala länken, och därav dess namn och dess kallelse som en "patch" när det inte finns någon formell namntjänst i nätverket.

I åratal, särskilt i mindre nätverk eller ad hoc-implementeringar, visade det sig vara användbart. Numera, med utbredd och billig DNS, användningsfallet har minskat så mycket att det nästan alltid är vettigt att stänga av LLMNR och leva mer fredligt.

Är LLMNR verkligen nödvändig? Risker och kontext

Miljondollarfrågan: ska jag ta ner den eller låta den vara kvar? I en hemmiljö är det vanligaste svaret "ja, det är bara att ta ner den". I ett företag är det bekvämt att validera effektenOm miljöns DNS är korrekt konfigurerad och sökningar fungerar, tillhandahåller LLMNR ingenting och exponerar onödiga risker.

Det största problemet är det LLMNR innehåller inget skydd mot identitetsstöldEn angripare på ditt eget subnät kan "imitera" för att vara målenheten och reagera tidigt eller med förtur, vilket omdirigerar anslutningen och orsakar kaos. Det är ett klassiskt gammaldags "man-in-the-middle" (MitM) attackscenario.

Som en analogi påminner det om Wi-Fi WEP-standarden, som föddes utan att ta hänsyn till moderna attacker och har blivit föråldrad. Något liknande händer med LLMNRDet var användbart förr i tiden, men idag är det en öppen dörr för bedrägeri om du lämnar det vid liv på företagsnätverk.

Dessutom kan en motståndare med rätt verktyg tvinga dina datorer att "sjunga" känslig information som NTLMv2-hashar när de tror att de kommunicerar med en legitim server. När angriparen får tag på dessa hashkoder, kan försöka knäcka dem – med varierande framgång beroende på policyer och lösenordskomplexitet – vilket ökar risken för ett verkligt intrång.

När ska man inaktivera LLMNR?

I de allra flesta moderna installationer kan du inaktivera den utan att något går sönder. Om dina klienter alltid löser problem via DNS Och om du inte förlitar dig på "magi" i det lokala nätverket är LLMNR överflödigt. Validera dock i kritiska miljöer innan du implementerar policyn i hela organisationen.

Tänk på att beslutet inte bara är tekniskt: det minskar också din operativa risk och din efterlevnadsrisk. Att inaktivera LLMNR är en enkel, mätbar och effektfull härdningskontroll., precis vad ett rimligt säkerhetsramverk kräver.

Inaktivera LLMNR i Windows

Här är de viktigaste alternativen som finns tillgängliga för att inaktivera LLMNR i Windows:

Alternativ 1: Redigerare för lokal grupprincip (gpedit.msc)

På fristående datorer eller för snabba tester kan du använda den lokala grupprincipredigeraren. Tryck WIN + R, skriv gpedit.msc och acceptera för att öppna den.

Navigera sedan igenom: Datorkonfiguration > Administrativa mallar > NätverkI vissa utgåvor visas inställningen under DNS-klient. Hitta posten "Inaktivera multicast-namnmatchning" (namnet kan variera något) och ställ in policyn till ”Aktiverad”.

I Windows 10 läses texten vanligtvis som "Inaktivera multicast-namnmatchning". Tillämpa eller acceptera ändringen och starta om datorn. för att säkerställa att inställningarna på teamsidan tillämpas korrekt.

Alternativ 2: Windows-registret

Om du föredrar att gå rakt på sak eller behöver en skriptbar metod kan du skapa policyvärdet i registret. Öppna CMD eller PowerShell med administratörsbehörighet och kör:

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

Med detta kommer LLMNR att inaktiveras på policynivå. Starta om datorn för att avsluta cykeln och förhindra att processer med ett tidigare tillstånd finns kvar i minnet.

Inaktivera LLMNR med GPO i en domän

Ett annat sätt att inaktivera LLMNR är att tillämpa ändringen centralt från en domänkontrollant genom att öppna grupprinciphanteringskonsolen. Skapa ett nytt grupgruppsobjekt (till exempel ”MITT-GPU”) och redigera den.

Följ sökvägen i redigeraren: Datorkonfiguration > Administrativa mallar > Nätverk > DNS-klient. Aktivera policyn "Inaktivera multicast-namnmatchning" och stäng redigeraren för att spara. Länka sedan grupprincipobjektet till lämplig organisationsenhet och tvinga fram policyuppdateringen eller vänta på normal replikering.

Klart. Du har nu en domänpolicy som konsekvent minskar LLMNR. Kom ihåg att den exakta nomenklaturen för justeringen kan variera. något mellan versioner av Windows Server, men platsen är som angiven.

Intune: ”Tillämpad” men gpedit visar ”Inte konfigurerad”

En vanlig fråga: när du skickar en konfigurationsprofil från Intune får du veta att den har tillämpats korrekt, och när du öppnar gpedit ser du inställningen som "Inte konfigurerad". Detta betyder inte nödvändigtvis att den inte är aktiv.Intune tillämpar inställningar via CSP/Registry som inte alltid återspeglas i den lokala redigeraren som "Konfigurerad".

Det tillförlitliga sättet att kontrollera detta är att konsultera policyloggen: Om den existerar och är lika med 0, värdet Aktivera Multicast på HKLM\Programvara\Policyer\Microsoft\Windows NT\DNSClient, LLMNR är inaktiverat trots att gpedit visar "Inte konfigurerad".

Om du föredrar att säkerställa detta via ett skript (användbart som Remediation i Intune), här är ett enkelt PowerShell-skript för att skapa värdet och verifiera det:

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

Detta täcker fallet där Intune säger att det tillämpades, men du vill ha maximal säkerhet eller felsöka "oseriösa" enheter. För att granska i bulk, kombinera skriptet med ditt lagerverktyg eller med Intune/Defender för slutpunktsrapporter.

Inaktivera LLMNR på Linux (systemd-löst)

På distributioner som Ubuntu eller Debian som använder systemd-resolved kan du "döda" LLMNR direkt. Redigera resolverinställningarna Så:

sudo nano /etc/systemd/resolved.conf

I filen, ange motsvarande parameter så att den är entydig. Till exempel:

[Resolve]
LLMNR=no

Spara och starta om tjänsten eller datorn: Det räcker vanligtvis med att starta om tjänsten, även om en omstart också är giltig om det passar dig bättre.

sudo systemctl restart systemd-resolved

Med det kommer systemd-resolved att sluta använda LLMNR. Om du använder en annan upplösning (eller andra distributioner), kontrollera deras dokumentation: mönstret skiljer sig inte så mycket och det finns alltid en motsvarande "switch".

Om NBT-NS och Windows-brandväggen

Att inaktivera LLMNR är halva arbetet. Responder och liknande verktyg utnyttjar även NetBIOS Name Service (NBT-NS), som fungerar över klassiska NetBIOS-portar (UDP 137/138 och TCP 139). Detta väcker frågan som många ställer sig: räcker det att blockera portar i brandväggen, eller måste man explicit inaktivera NBT-NS?

Om du tillämpar strikta regler på din lokala brandvägg – både inkommande och utgående – som blockerar 137/UDP, 138/UDP och 139/TCP, minskar du din exponering avsevärt. Bästa praxis i företagsmiljöer är dock att inaktivera NetBIOS via TCP/IP. i gränssnitt, för att förhindra oönskade svar eller annonser om brandväggspolicyn ändras eller modifieras av ett program.

I Windows finns det inget "fabriks"-GPO lika direkt som i LLMNR, men du kan göra det via WMI eller Registry. Denna WMI-baserade PowerShell inaktiverar den på alla IP-aktiverade adaptrar:

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

Om du föredrar brandväggsregler, gör det, men se till att de är dubbelriktade och beständiga. Block 137/UDP, 138/UDP och 139/TCP och övervakar att det inte finns några motstridiga regler i andra GPO:er eller EDR/AV-lösningar som hanterar brandväggen.

Verifiering: Hur man kontrollerar att LLMNR och NBT-NS är ur spel

För LLMNR på Windows, titta i registret: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast måste existera och vara lika med 0. Snabbkontroll i PowerShell skulle:

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

På trafiknivå är en enkel teknik att söka efter ett icke-existerande namn och använda Wireshark för att observera att inga UDP 5355-paket matas ut. Om du inte ser multicast till det lokala segmentet, du är på rätt spår.

På Linux med systemd-resolved, kontrollera statusen med resolvectl eller systemctl: Se till att LLMNR är inställt på "nej" i den effektiva konfigurationen och att tjänsten startades om utan fel.

För NBT-NS, bekräfta att dina brandväggsregler blockerar 137/UDP, 138/UDP och 139/TCP eller att NetBIOS är inaktiverat på adaptrarna. Du kan också nosa på nätet en stund för att kontrollera att det inte finns några NetBIOS-förfrågningar eller reklam i etern.

Vanliga frågor och användbara nyanser

• Kommer jag att förstöra något genom att inaktivera LLMNR? I nätverk med väl underhållen DNS är detta vanligtvis inte fallet. I speciella eller äldre miljöer, validera först i en pilotgrupp och kommunicera ändringen till supporten.
• Varför visar gpedit "Inte konfigurerad" trots att Intune anger "Tvingad"? Eftersom den lokala redigeraren inte alltid återspeglar tillstånd som införs av MDM eller CSP. Sanningen finns i registret och de faktiska resultaten, inte i gpedit-texten.
• Är det obligatoriskt att inaktivera NBT-NS om jag blockerar NetBIOS i brandväggen? Om blockeringen är fullständig och robust minskar du risken avsevärt. Att inaktivera NetBIOS över TCP/IP eliminerar dock svar på stacknivå och undviker överraskningar om reglerna ändras, så det är det bästa alternativet.
• Finns det några färdiga skript för att inaktivera LLMNR? Ja, via registret eller PowerShell, som du har sett. För Intune, paketera skriptet som Remediation och lägg till efterlevnadskontroll.

Att stänga av LLMNR minskar förfalskningsytan på det lokala nätverket och kväver hash-grabbing-attacker med verktyg som Responder i sin linda. Om du även blockerar eller inaktiverar NBT-NS och tar hand om din DNSDu får en enkel och effektiv säkerhetscocktail: mindre brus, mindre risk och ett nätverk som är mycket bättre förberett för daglig användning.