Miért tiltod le az LLMNR-t, ha nyilvános Wi-Fi-t használsz?

Utolsó frissítés: 20/10/2025

  • Az LLMNR hamisításnak és hash-rögzítésnek teszi ki az embereket; letiltása csökkenti a belső kockázatokat.
  • Könnyű letiltás: GPO/Rendszerleíró adatbázis Windows rendszeren és a systemd szerkesztése megoldva Linux rendszeren.
  • Kiegészíti az NBT-NS blokkolásával vagy letiltásával, valamint a beállításjegyzék/forgalom általi ellenőrzéssel.
LLMNR letiltása

Az LLMNR protokoll ismerős arc a Microsoft környezetekben. Azokban a hálózatokban, ahol a Windows a főszereplő, alapértelmezés szerint engedélyezve van, és bár egykor értelmes volt, ma már gyakran inkább fejfájást okoz, mint segítséget. Ezért jó ötlet tudni, hogyan kell használni. hogyan lehet letiltani az LLMNR-t Különösen akkor, ha nyilvános WiFi hálózatot használunk.

Mielőtt bármilyen döntést hozna, érdemes megérteni, hogy mit csinál, és miért ajánlott letiltani. A jó hír az, hogy a letiltása egyszerű. mind Windows (beleértve a Windows Servert), mind Linux rendszeren, akár szabályzatokon, beállításjegyzéken, Intune-on keresztül, akár a systemd-resolved finomhangolásával.

Mi az LLMNR és hogyan működik?

LLMNR a rövidítése Link-Local Multicast névfeloldásA célja az a helyi szegmensen belüli hostnevek feloldása DNS-kiszolgáló igénybevétele nélkülMás szóval, ha egy gép nem tud DNS-en keresztül feloldani egy nevet, megpróbálhatja lekérdezni a környéket multicast segítségével, hogy lássa, van-e valaki, aki „érti a célzást”.

Ez a mechanizmus a portot használja UDP 5355 és úgy tervezték, hogy a helyi hálózaton belül működjön. A lekérdezés multicast módon kerül elküldésre. a közvetlen hálózathoz, és bármely számítógép, amely „felismeri” a nevet, válaszolhat azzal, hogy „ez én vagyok”. Ez egy gyors és egyszerű megközelítés kis vagy improvizált környezetekben, ahol a DNS nem volt elérhető, vagy nem volt értelme konfigurálni.

A gyakorlatban az LLMNR lekérdezés a helyi szegmensbe jut, és az ezt a forgalmat figyelő eszközök válaszolhatnak, ha úgy vélik, hogy ők a megfelelő célállomás. Hatálya a helyi kapcsolatra korlátozódik., és innen ered a neve, valamint a „javításként” való hivatása, amikor nincs hivatalos névszolgáltatás a hálózaton.

Évekig hasznosnak bizonyult, különösen kisebb hálózatokban vagy eseti telepítésekben. Manapság, széles körben elterjedt és olcsó DNS-sel, a felhasználási eset annyira leszűkült, hogy szinte mindig van értelme kikapcsolni az LLMNR-t és békésebben élni.

LLMNR letiltása

Valóban szükséges az LLMNR? Kockázatok és kontextus

A millió dolláros kérdés: vegyem le, vagy hagyjam? Családi környezetben a leggyakoribb válasz az, hogy „igen, nyugodtan vegyem le”. Egy vállalatnál kényelmes a hatás validálásaHa a környezet DNS-e megfelelően van beállítva és a keresések működnek, az LLMNR semmit sem nyújt, és felesleges kockázatokat jelent.

A legnagyobb probléma az Az LLMNR nem tartalmaz védelmet a személyazonossággal való visszaélés ellen.Egy támadó a saját alhálózatodon „megszemélyesítheti” a céleszközt, és korán vagy előnyben részesítve reagálhat, átirányítva a kapcsolatot és káoszt okozva. Ez egy klasszikus, régi vágású „közbeékelődéses” (MitM) támadási forgatókönyv.

Exkluzív tartalom – Kattintson ide  IP-cím nyomon követése

Hasonlatként felidézi a Wi-Fi WEP szabványt, amely a modern támadások figyelembevétele nélkül született, és mára elavulttá vált. Valami hasonló történik az LLMNR-relRégebben hasznos volt, de ma már nyitott ajtót nyit a megtévesztésnek, ha életben hagyod a vállalati hálózatokon.

Ezenkívül egy megfelelő eszközökkel rendelkező támadó kezében arra kényszerítheti a számítógépeket, hogy „énekeljenek” érzékeny információkat, például NTLMv2 hasheket, amikor azt hiszik, hogy egy legitim szerverrel kommunikálnak. Miután a támadó megszerzi ezeket a hash-eket, megpróbálhatják feltörni őket – változó sikerrel a szabályzatoktól és a jelszó bonyolultságától függően –, növelve ezzel a valódi behatolás kockázatát.

Mikor kell letiltani az LLMNR-t?

A modern telepítések túlnyomó többségében letiltható anélkül, hogy bármi is meghibásodna. Ha az ügyfeleid mindig DNS-sel oldják fel a feladatokat És ha nem a helyi hálózaton lévő „varázslatra” hagyatkozol, az LLMNR felesleges. Ennek ellenére kritikus környezetekben ellenőrizd, mielőtt a szabályzatot a teljes szervezetre kiterjesztenéd.

Ne feledd, hogy a döntés nem csupán technikai jellegű: csökkenti a működési és megfelelőségi kockázatokat is. Az LLMNR letiltása egy egyszerű, mérhető és hatásos edzésvezérlő., pontosan amit minden értelmes biztonsági keretrendszer megkövetel.

LLMNR

Az LLMNR letiltása Windows rendszerben

Íme a főbb lehetőségek az LLMNR letiltására Windows rendszerben:

1. lehetőség: Helyi csoportházirend-szerkesztő (gpedit.msc)

Önálló számítógépeken vagy gyors teszteléshez használhatja a Helyi csoportházirend-szerkesztőt. Nyomd meg a WIN + R billentyűt, majd írd be gpedit.msc fájlt, és fogadja el a megnyitásához.

Ezután navigáljon a következők között: Számítógép konfigurációja > Felügyeleti sablonok > HálózatNéhány kiadásban a beállítás a következő címszó alatt jelenik meg: DNS kliens. Keresse meg a „Multicast névfeloldás letiltása” bejegyzést. (a név kissé eltérhet), és állítsa a szabályzatot „Engedélyezve” értékre.

Windows 10 rendszerben a szöveg általában így olvasható: „Többcímes névfeloldás letiltása”. Alkalmazza vagy fogadja el a módosítást, és indítsa újra a számítógépet. hogy a csapatoldali beállítások helyesen legyenek alkalmazva.

2. lehetőség: Windows rendszerleíró adatbázis

Ha inkább a lényegre térnénk, vagy szkriptelhető metódusra van szükségünk, létrehozhatjuk a házirend értékét a beállításjegyzékben. Nyissa meg a CMD-t vagy PowerShell rendszergazdai engedélyekkel és hajtsd végre:

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

Ezzel az LLMNR szabályzatszinten letiltásra kerül. Indítsa újra a számítógépet a ciklus bezárásához és megakadályozzák, hogy egy korábbi állapotú folyamatok a memóriában maradjanak.

LLMNR letiltása csoportházirenddel egy tartományban

Az LLMNR letiltásának egy másik módja, hogy a módosítást központilag, egy tartományvezérlőről alkalmazzuk a Csoportházirend-kezelő konzol megnyitásával. Hozzon létre egy új csoportházirend-objektumot (például „MY-GPO”) és szerkessze.

A szerkesztőben kövesd az elérési utat: Számítógép konfigurációja > Felügyeleti sablonok > Hálózat > DNS-kliens. Engedélyezze a „Multicast névfeloldás letiltása” házirendet és zárja be a szerkesztőt a mentéshez. Ezután csatolja a csoportházirend-objektumot a megfelelő szervezeti egységhez, és kényszerítse a szabályzat frissítését, vagy várja meg a normál replikációt.

Exkluzív tartalom – Kattintson ide  Az Apple lépést tesz a minialkalmazásokkal kapcsolatban: 15%-os jutalék és új szabályok

Kész. Most már van egy olyan domainszabályzata, amely következetesen vágja le az LLMNR-t. Ne feledje, hogy a beállítás pontos elnevezése eltérő lehet. kissé eltér a Windows Server verziói között, de a helyszín a jelzett.

Intune: „Alkalmazva”, de a gpedit „Nincs konfigurálva” üzenetet mutat.

Gyakori kérdés: ha letöltesz egy konfigurációs profilt az Intune-ból, az jelzi, hogy helyesen lett alkalmazva, és amikor megnyitod a gpedit-et, a beállítás „Nincs konfigurálva”-ként jelenik meg. Ez nem feltétlenül jelenti azt, hogy nem aktív.Az Intune a CSP/beállításjegyzéken keresztül alkalmazza azokat a beállításokat, amelyek nem mindig jelennek meg a helyi szerkesztőben „Konfiguráltként”.

Ennek megbízható ellenőrzési módja a szabályzatnapló megtekintése: Ha létezik és egyenlő 0-val, akkor az érték Többcélú címzés engedélyezése bekapcsolva HKLM\Szoftver\Házirendek\Microsoft\Windows NT\DNSClient, az LLMNR le van tiltva, annak ellenére, hogy a gpedit a „Nincs konfigurálva” értéket mutatja.

Ha ezt szkripten keresztül szeretnéd biztosítani (ez hasznos, mint az Intune-ban a Remediation), itt egy egyszerű PowerShell szkript az érték létrehozásához és ellenőrzéséhez:

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

Ez arra az esetre vonatkozik, amikor az Intune szerint a hiba alkalmazásra került, de Ön maximális bizonyosságot szeretne, vagy „hamis” eszközök hibáit szeretné elhárítani. Tömeges auditáláshoz kombináld a szkriptet a leltáreszközöddel vagy az Intune/Defender for Endpoint jelentésekkel.

LLMNR letiltása Linuxon (systemd-megoldás)

Az olyan disztribúciókon, mint az Ubuntu vagy a Debian, amelyek systemd-resolved-et használnak, közvetlenül „leállíthatod” az LLMNR-t. A feloldó beállításainak szerkesztése Így:

sudo nano /etc/systemd/resolved.conf

A fájlban állítsd be a megfelelő paramétert úgy, hogy az egyértelmű legyen. Például:

[Resolve]
LLMNR=no

Mentse el és indítsa újra a szolgáltatást vagy a számítógépet: A szolgáltatás újraindítása általában elegendő, bár az újraindítás is érvényes, ha az kényelmesebb az Ön számára.

sudo systemctl restart systemd-resolved

Ezzel a systemd-resolved leállítja az LLMNR használatát. Ha más felbontási megoldást használ (vagy más disztribúciók esetén) ellenőrizd a dokumentációjukat: a minta nem különbözik túlságosan, és mindig van egy azzal egyenértékű „kapcsoló”.

Az NBT-NS és a Windows tűzfal bemutatása

Az LLMNR letiltása már a siker fele. A Responder és hasonló eszközök a NetBIOS Name Service (NBT-NS) titkait is kihasználják., amely klasszikus NetBIOS portokon (UDP 137/138 és TCP 139) keresztül működik. Ez sokakban felveti a kérdést: elég-e blokkolni a portokat a tűzfalon, vagy explicit módon le kell tiltani az NBT-NS-t?

Ha szigorú szabályokat alkalmaz a helyi tűzfalon – mind a bejövő, mind a kimenő forgalmat –, amelyek blokkolják a 137/UDP, 138/UDP és 139/TCP protokollokat, akkor jelentősen csökkentheti a kitettséget. Vállalati környezetekben azonban a legjobb gyakorlat a NetBIOS TCP/IP feletti letiltása. a felületeken, hogy megakadályozzák a nem kívánt válaszokat vagy hirdetéseket, ha a tűzfalszabályzat megváltozik, vagy egy alkalmazás módosítja azt.

Exkluzív tartalom – Kattintson ide  Trójai ló: mi ez és hogyan lehet megvédeni magát

Windowsban nincs olyan közvetlen „gyári” csoportházirend-objektum, mint az LLMNR-ben, de ezt megteheted WMI-n vagy beállításjegyzéken keresztül. Ez a WMI-alapú PowerShell minden IP-címmel rendelkező adapteren letiltja.:

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

Ha a tűzfalszabályokat részesíted előnyben, nyugodtan tegyél, de ügyelj arra, hogy azok kétirányúak és állandóak legyenek. 137/UDP, 138/UDP és 139/TCP blokkok és figyeli, hogy nincsenek-e ütköző szabályok a tűzfalat kezelő más csoportházirendekben vagy EDR/AV megoldásokban.

Ellenőrzés: Hogyan ellenőrizhető, hogy az LLMNR és az NBT-NS nincsenek játékban

Windows rendszeren az LLMNR esetében tekintse meg a beállításjegyzéket: HKLM\Szoftver\Házirendek\Microsoft\Windows NT\DNSClient\Multicast engedélyezése léteznie kell, és egyenlőnek kell lennie 0-val. Gyors ellenőrzés a PowerShellben lenne:

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

Forgalmi szinten egy egyszerű technika, hogy nem létező névre keresünk rá, és a Wireshark segítségével megfigyeljük, hogy nem jelennek meg UDP 5355 csomagok. Ha nem látja a multicastingot a helyi szegmensbe, jó úton jársz.

Linuxon systemd-resolved paranccsal ellenőrizd az állapotot a resolvectl vagy a systemctl paranccsal: Győződjön meg arról, hogy az LLMNR beállítása „nem” a hatályos konfigurációban, és hogy a szolgáltatás hibák nélkül újraindult.

NBT-NS esetén ellenőrizze, hogy a tűzfalszabályok blokkolják-e a 137/UDP, 138/UDP és 139/TCP protokollokat, vagy hogy a NetBIOS le van-e tiltva az adaptereken. Egy ideig szagolgathatod a netet is hogy ellenőrizze, nincsenek-e NetBIOS-kérések vagy hirdetések az adásban.

Gyakran ismételt kérdések és hasznos részletek

  • Elronthatok valamit az LLMNR letiltásával? A jól karbantartott DNS-sel rendelkező hálózatokban ez jellemzően nem így van. Speciális vagy régi környezetekben először egy kísérleti csoportban kell validálni, majd a változást közölni az ügyfélszolgálattal.
  • Miért mutatja a gpedit a „Nincs konfigurálva” értéket, miközben az Intune szerint „Kényszerített”? Mivel a helyi szerkesztő nem mindig tükrözi az MDM vagy a CSP által előírt állapotokat. Az igazság a beállításjegyzékben és a tényleges eredményekben rejlik, nem a gpedit szövegben.
  • Kötelező letiltani az NBT-NS-t, ha blokkolom a NetBIOS-t a tűzfalon? Ha a blokkolás teljes és robusztus, jelentősen csökkenthető a kockázat. A NetBIOS TCP/IP feletti letiltása azonban kiküszöböli a verem szintű válaszokat, és elkerüli a meglepetéseket, ha a szabályok megváltoznak, így ez az előnyösebb megoldás.
  • Vannak olyan szkriptek, amelyek készen állnak az LLMNR letiltására? Igen, a beállításjegyzéken vagy a PowerShellen keresztül, ahogy látta. Az Intune esetében csomagolja be a szkriptet Remediation-ként, és adja hozzá a megfelelőség-ellenőrzést.

Az LLMNR kikapcsolása csökkenti a hamisítási felületet a helyi hálózaton, és már a kezdetektől fogva elhárítja a hash-elkapó támadásokat olyan eszközökkel, mint a Responder. Ha az NBT-NS-t is blokkolja vagy letiltja, és gondoskodik a DNS-érőlEgy egyszerű és hatékony biztonsági koktélt kapsz: kevesebb zaj, kevesebb kockázat, és egy sokkal jobban felkészített hálózat a mindennapi használatra.