Pourquoi désactiver LLMNR si vous utilisez un Wi-Fi public ?

Le protocole LLMNR est un élément familier des environnements Microsoft. Sur les réseaux Windows, il est activé par défaut. Si cela semblait logique autrefois, il est aujourd'hui souvent plus un casse-tête qu'une aide précieuse. C'est pourquoi il est important de savoir comment l'utiliser. comment désactiver LLMNR surtout si nous utilisons un réseau WiFi public.

Avant de prendre une décision, il est judicieux de comprendre ce qu'il fait et pourquoi il est recommandé de le désactiver. La bonne nouvelle est que le désactiver est facile. sur Windows (y compris Windows Server) et Linux, soit via des politiques, le Registre, Intune ou en réglant systemd-resolved.

Qu'est-ce que LLMNR et comment fonctionne-t-il ?

LLMNR sont les acronymes de Résolution de nom multidiffusion locale. Son but est résoudre les noms d'hôtes dans le segment local sans s'appuyer sur un serveur DNSEn d'autres termes, si une machine ne peut pas résoudre un nom via DNS, elle peut essayer d'interroger le voisinage en utilisant la multidiffusion pour voir si quelqu'un « comprend l'allusion ».

Ce mécanisme utilise le port UDP 5355 et est conçu pour fonctionner au sein du réseau local. La requête est envoyée par multidiffusion au réseau local, et tout ordinateur qui reconnaît le nom peut répondre en disant « C'est moi ». C'est une approche simple et rapide pour les environnements restreints ou improvisés où le DNS n'était pas disponible ou sa configuration était complexe.

En pratique, la requête LLMNR se déplace vers le segment local et les appareils qui écoutent ce trafic peuvent répondre s'ils pensent qu'ils sont à la bonne destination. Sa portée est limitée au lien local, d’où son nom et sa vocation de « patch » lorsqu’il n’existe pas de service de noms formel sur le réseau.

Pendant des années, cela s’est avéré utile, en particulier dans les petits réseaux ou les déploiements ad hoc. De nos jours, avec un DNS répandu et bon marché, le cas d'utilisation s'est tellement réduit qu'il est presque toujours judicieux de désactiver LLMNR et de vivre plus paisiblement.

Le LLMNR est-il vraiment nécessaire ? Risques et contexte

La question cruciale : dois-je le démonter ou le laisser ? Dans un contexte familial, la réponse la plus courante est : « Oui, n'hésitez pas à le démonter. » Dans une entreprise, il est pratique de valider l'impact:Si le DNS de l'environnement est correctement configuré et que les recherches fonctionnent, LLMNR ne fournit rien et expose à des risques inutiles.

Le plus gros problème est que LLMNR n'intègre pas de protection contre l'usurpation d'identitéUn attaquant sur votre propre sous-réseau peut se faire passer pour l'appareil ciblé et réagir rapidement ou de manière préférentielle, redirigeant la connexion et semant le chaos. Il s'agit d'une attaque classique de type « man-in-the-middle » (MitM).

Par analogie, cela rappelle la norme Wi-Fi WEP, qui est née sans tenir compte des attaques modernes et est devenue obsolète. Quelque chose de similaire se produit avec LLMNR:C'était utile dans le passé, mais aujourd'hui c'est une porte ouverte à la tromperie si vous le laissez en vie sur les réseaux d'entreprise.

De plus, entre les mains d’un adversaire disposant des bons outils, ils peuvent forcer vos ordinateurs à « chanter » des informations sensibles comme les hachages NTLMv2 lorsqu’ils pensent parler à un serveur légitime. Une fois que l'attaquant obtient ces hachages, peuvent essayer de les déchiffrer, avec un succès variable selon les politiques et la complexité du mot de passe, augmentant ainsi le risque d'une véritable intrusion.

Quand désactiver LLMNR ?

Dans la grande majorité des déploiements modernes, vous pouvez le désactiver sans rien casser. Si vos clients résolvent toujours par DNS Et si vous ne vous fiez pas à la « magie » du réseau local, la LLMNR est superflue. Il est néanmoins conseillé de valider la politique dans les environnements critiques avant de la déployer à l'ensemble de l'organisation.

Gardez à l’esprit que la décision n’est pas seulement technique : elle réduit également votre risque opérationnel et de conformité. La désactivation de LLMNR est un contrôle de durcissement simple, mesurable et efficace., exactement ce qu’exige tout système de sécurité raisonnable.

Désactiver LLMNR sous Windows

Voici les principales options disponibles pour désactiver LLMNR sous Windows :

Option 1 : Éditeur de stratégie de groupe local (gpedit.msc)

Sur des ordinateurs autonomes ou pour des tests rapides, vous pouvez utiliser l’éditeur de stratégie de groupe local. Appuyez sur WIN + R, tapez gpedit.msc et acceptez de l'ouvrir.

Ensuite, naviguez à travers : Configuration ordinateur > Modèles d'administration > Réseau. Dans certaines éditions, le décor apparaît sous Client DNS. Recherchez l'entrée « Désactiver la résolution de nom multidiffusion » (le nom peut varier légèrement) et définissez la politique sur « Activé ».

Dans Windows 10, le texte est généralement lu comme « Désactiver la résolution de nom multidiffusion ». Appliquez ou acceptez la modification et redémarrez votre ordinateur. pour garantir que les paramètres côté équipe sont appliqués correctement.

Option 2 : Registre Windows

Si vous préférez aller droit au but ou si vous avez besoin d’une méthode scriptable, vous pouvez créer la valeur de la politique dans le Registre. Ouvrez CMD ou PowerShell avec des autorisations d'administrateur et exécuter :

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

Avec cela, LLMNR sera désactivé au niveau de la politique. Redémarrez l'ordinateur pour fermer le cycle et empêcher les processus avec un état précédent de rester en mémoire.

Désactiver LLMNR avec GPO dans un domaine

Une autre façon de désactiver LLMNR consiste à appliquer la modification de manière centralisée à partir d’un contrôleur de domaine en ouvrant la console de gestion des stratégies de groupe. Créer un nouvel objet de stratégie de groupe (par exemple, « MY-GPO ») et modifiez-le.

Dans l'éditeur, suivez le chemin : Configuration ordinateur > Modèles d'administration > Réseau > Client DNS. Activer la politique « Désactiver la résolution de nom multidiffusion » Fermez l'éditeur pour enregistrer. Ensuite, liez l'objet de stratégie de groupe à l'unité d'organisation appropriée et forcez l'actualisation de la stratégie ou attendez la réplication normale.

C'est fait. Vous disposez désormais d'une politique de domaine qui réduit systématiquement le LLMNR. N'oubliez pas que la nomenclature exacte du réglage peut varier. légèrement entre les versions de Windows Server, mais l'emplacement est celui indiqué.

Intune : « Appliqué » mais gpedit affiche « Non configuré »

Une question courante : vous envoyez un profil de configuration depuis Intune, il vous indique qu’il a été appliqué correctement et lorsque vous ouvrez gpedit, vous voyez le paramètre comme « Non configuré ». Cela ne signifie pas nécessairement qu’il n’est pas actif.. Intune applique des paramètres via CSP/Registre qui ne sont pas toujours reflétés dans l'éditeur local comme « Configurés ».

Le moyen fiable de vérifier cela est de consulter le journal des politiques : S'il existe et est égal à 0, la valeur Activer la multidiffusion sur HKLM\Software\Policies\Microsoft\Windows NT\DNSClient, LLMNR est désactivé même si gpedit affiche « Non configuré ».

Si vous préférez garantir cela via un script (utile comme la correction dans Intune), voici un script PowerShell simple pour créer la valeur et la vérifier :

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

Cela couvre le cas où Intune indique qu'il a été appliqué, mais vous souhaitez une certitude maximale ou dépanner les appareils « escrocs ». Pour effectuer un audit en masse, combinez le script avec votre outil d'inventaire ou avec les rapports Intune/Defender pour Endpoint.

Désactiver LLMNR sous Linux (résolu par systemd)

Sur les distributions comme Ubuntu ou Debian qui utilisent systemd-resolved, vous pouvez « tuer » LLMNR directement. Modifier les paramètres du résolveur Donc:

sudo nano /etc/systemd/resolved.conf

Dans le fichier, définissez le paramètre correspondant afin qu'il soit sans ambiguïté. Par exemple:

[Resolve]
LLMNR=no

Enregistrez et redémarrez le service ou l'ordinateur : Le redémarrage du service est généralement suffisant, bien qu'un redémarrage soit également valable si cela vous convient mieux.

sudo systemctl restart systemd-resolved

Avec cela, systemd-resolved cessera d'utiliser LLMNR. Si vous utilisez une autre solution de résolution (ou d'autres distributions), vérifiez leur documentation : le modèle ne diffère pas trop et il existe toujours un « switch » équivalent.

À propos de NBT-NS et du pare-feu Windows

Désactiver LLMNR représente la moitié de la bataille. Responder et les outils similaires exploitent également le service de noms NetBIOS (NBT-NS), qui fonctionne sur les ports NetBIOS classiques (UDP 137/138 et TCP 139). Cela soulève une question fréquente : suffit-il de bloquer les ports dans le pare-feu, ou faut-il désactiver explicitement NBT‑NS ?

Si vous appliquez des règles strictes sur votre pare-feu local (entrant et sortant), bloquant 137/UDP, 138/UDP et 139/TCP, vous réduisez considérablement votre exposition. Cependant, la meilleure pratique dans les environnements d’entreprise consiste à désactiver NetBIOS sur TCP/IP. dans les interfaces, pour empêcher les réponses ou publicités indésirables si la politique du pare-feu change ou est modifiée par une application.

Sous Windows, il n’existe pas de GPO « d’usine » aussi direct que dans LLMNR, mais vous pouvez le faire via WMI ou le Registre. Ce PowerShell basé sur WMI le désactive sur tous les adaptateurs compatibles IP:

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

Si vous préférez les règles de pare-feu, allez-y, mais assurez-vous qu'elles sont bidirectionnelles et persistantes. Blocs 137/UDP, 138/UDP et 139/TCP et surveille qu'il n'y a pas de règles contradictoires dans d'autres GPO ou solutions EDR/AV qui gèrent le pare-feu.

Vérification : Comment vérifier que LLMNR et NBT-NS sont hors jeu

Pour LLMNR sur Windows, regardez le Registre : HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast doit exister et être égal à 0. Vérification rapide dans PowerShell serieuse:

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

Au niveau du trafic, une technique simple consiste à exécuter une recherche sur un nom inexistant et à utiliser Wireshark pour observer qu'aucun paquet UDP 5355 n'est émis. Si vous ne voyez pas de multidiffusion vers le segment local, tu es sur la bonne voie.

Sous Linux avec systemd-resolved, vérifiez l'état avec resolvectl ou systemctl : Assurez-vous que LLMNR est réglé sur « non » dans la configuration effective et que le service a été redémarré sans erreur.

Pour NBT‑NS, vérifiez que vos règles de pare-feu bloquent 137/UDP, 138/UDP et 139/TCP ou que NetBIOS est désactivé sur les adaptateurs. Vous pouvez également renifler le net pendant un moment pour vérifier qu'il n'y a pas de requêtes NetBIOS ou de publicités en ondes.

Questions fréquemment posées et nuances utiles

• Vais-je casser quelque chose en désactivant LLMNR ? Dans les réseaux dotés d'un DNS bien entretenu, ce n'est généralement pas le cas. Dans les environnements spécifiques ou hérités, validez d'abord avec un groupe pilote et communiquez la modification au support.
• Pourquoi gpedit affiche-t-il « Non configuré » même si Intune indique « Appliqué » ? Parce que l'éditeur local ne reflète pas toujours les états imposés par MDM ou CSP. La vérité réside dans le registre et les résultats réels, et non dans le texte de gpedit.
• Est-il obligatoire de désactiver NBT‑NS si je bloque NetBIOS sur le pare-feu ? Si le blocage est complet et robuste, le risque est considérablement réduit. Cependant, désactiver NetBIOS sur TCP/IP élimine les réponses au niveau de la pile et évite les surprises en cas de modification des règles. C'est donc l'option à privilégier.
• Existe-t-il des scripts prêts à l'emploi pour désactiver LLMNR ? Oui, via le Registre ou PowerShell, comme vous l'avez vu. Pour Intune, empaquetez le script en tant que correction et ajoutez une vérification de conformité.

La désactivation de LLMNR réduit la surface d'usurpation d'identité sur le réseau local et étouffe dans l'œuf les attaques de vol de hachage avec des outils comme Responder. Si vous bloquez ou désactivez également NBT‑NS et prenez soin de votre DNSVous disposerez d'un cocktail de sécurité simple et efficace : moins de bruit, moins de risques et un réseau bien mieux préparé pour une utilisation quotidienne.