Por qué desactivar LLMNR si usas Wi-Fi público

El protocolo LLMNR es un viejo conocido de los entornos Microsoft. En redes donde Windows es protagonista, se activa por defecto y, aunque en su día tuvo sentido, hoy suele ser más un quebradero de cabeza que una ayuda. Por eso es conveniente saber cómo desactivar LLMNR espcialmente si estamos usando una red WiFi pública.

Antes de tomar ninguna decisión conviene entender qué hace y por qué se recomienda deshabilitarlo. La buena noticia es que desactivarlo es sencillo tanto en Windows (incluidos Windows Server) como en Linux, ya sea mediante políticas, Registro, Intune o ajustando systemd-resolved.

Qué es LLMNR y cómo funciona

LLMNR son las siglas de Link-Local Multicast Name Resolution. Su finalidad es resolver nombres de host dentro del segmento local sin depender de un servidor DNS. En otras palabras, si una máquina no puede resolver un nombre por DNS, puede probar a preguntar al vecindario usando multidifusión para ver si alguien “se da por aludido”.

Este mecanismo utiliza el puerto UDP 5355 y está pensado para operar en el ámbito de la red local. La consulta se envía por multidifusión a la red inmediata y cualquier equipo que “reconozca” el nombre puede contestar diciendo “ese soy yo”. Es un enfoque rápido y simple para entornos pequeños o improvisados en los que no había DNS disponible o no compensaba configurarlo.

En la práctica, la consulta LLMNR viaja al segmento local y los equipos que escuchan ese tráfico pueden responder si creen ser el destino correcto. Su alcance se limita al enlace local, y de ahí su denominación y su vocación de “parche” cuando no hay un servicio de nombres formal en la red.

Durante años, especialmente en redes de menor envergadura o en despliegues ad-hoc, resultó útil. Hoy en día, con DNS extendido y barato, el caso de uso se ha reducido tanto que casi siempre compensa apagar LLMNR y vivir más tranquilos.

¿Realmente hace falta LLMNR? Riesgos y contexto

La pregunta del millón: ¿me lo cargo o lo dejo? En un entorno doméstico, la respuesta más habitual es “sí, quítalo sin miedo”. En una empresa conviene validar impacto: si el DNS del entorno está bien montado y las búsquedas funcionan, LLMNR no aporta nada y expone riesgos innecesarios.

El mayor problema es que LLMNR no incorpora protección frente a suplantación. Un atacante en tu misma subred puede “hacerse pasar” por el equipo buscado y responder antes o de manera preferente, redirigiendo la conexión y sembrando el caos. Es un escenario clásico de ataque de tipo “hombre en el medio” (MitM) a la vieja usanza.

Como analogía, recuerda el estándar Wi‑Fi WEP, que nació sin contemplar ataques modernos y quedó obsoleto. Con LLMNR ocurre algo parecido: fue útil en otra época, pero hoy es una puerta abierta al engaño si lo dejas vivo en redes corporativas.

Además, en manos de un adversario con las herramientas adecuadas, puede forzar que tus equipos “canten” información sensible como los hashes NTLMv2 cuando crean estar hablando con un servidor legítimo. Una vez el atacante obtiene esos hashes, puede probar a crackearlos —con éxito dispar según políticas y complejidad de contraseñas—, elevando el riesgo de una intrusión real.

¿Cuándo desactivar LLMNR?

En la inmensa mayoría de despliegues modernos, puedes desactivarlo sin que se rompa nada. Si tus clientes siempre resuelven por DNS y no dependes de “magias” en la red local, LLMNR sobra. Aun así, valida en entornos críticos antes de empujar la política a toda la organización.

Piensa que la decisión no es sólo técnica: también reduce tu riesgo operativo y de cumplimiento. Desactivar LLMNR es un control de endurecimiento sencillo, medible y con impacto, justo lo que pide cualquier marco de seguridad sensato.

Desactivar LLMNR en Windows

He aquñi las principales opciones que existen para desactivar LLMNR en Windows:

Opción 1: Editor de directivas de grupo local (gpedit.msc)

En equipos independientes o para pruebas rápidas, puedes usar el Editor de directivas de grupo local. Pulsa WIN + R, escribe gpedit.msc y acepta para abrirlo.

Después, navega por: Configuración del equipo > Plantillas administrativas > Red. En algunas ediciones, el ajuste aparece bajo Cliente DNS. Busca la entrada “Desactivar la resolución de nombres de multidifusión” (el nombre puede variar ligeramente) y establece la directiva como “Habilitada”.

En Windows 10 el texto suele leerse como “Desactivar resolución de nombres de multidifusión”. Aplica o acepta el cambio y reinicia el equipo para asegurarte de que la configuración del lado de equipo se aplique correctamente.

Opción 2: Registro de Windows

Si prefieres ir al grano o necesitas un método scriptable, puedes crear el valor de política en el Registro. Abre CMD o PowerShell con permisos de administrador y ejecuta:

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

Con eso, LLMNR quedará desactivado a nivel de política. Reinicia el equipo para cerrar el ciclo y evitar que queden procesos con estado previo en memoria.

Desactivar LLMNR con GPO en un dominio

Otra manera de desactivar LLMNR: aplicar el cambio de forma centralizada desde un controlador de dominio, abre la Consola de Administración de Directivas de Grupo. Crea un nuevo GPO (por ejemplo, “MY-GPO”) y edítalo.

En el editor, sigue la ruta: Configuración del equipo > Plantillas administrativas > Red > Cliente DNS. Habilita la directiva “Desactivar la resolución de nombres de multicast” y cierra el editor para guardar. Después, vincula el GPO a la OU adecuada y fuerza la actualización de directivas o espera la replicación normal.

Listo. Ya tienes una política de dominio que corta LLMNR de forma consistente. Recuerda que la nomenclatura exacta del ajuste puede variar ligeramente entre versiones de Windows Server, pero la ubicación es la indicada.

Intune: “Aplicado” pero en gpedit aparece “No configurado”

Una duda habitual: empujas un perfil de configuración desde Intune, te dice que se aplicó correctamente y, al asomarte a gpedit, ves el ajuste como “No configurado”. Esto no significa necesariamente que no esté activo. Intune aplica parámetros mediante CSP/Registro que no siempre se reflejan en el editor local como “Configurado”.

La forma fiable de comprobarlo es consultar el Registro de Políticas: si existe y vale 0 el valor EnableMulticast en HKLM\Software\Policies\Microsoft\Windows NT\DNSClient, LLMNR está deshabilitado aunque gpedit muestre “No configurado”.

Si prefieres garantizarlo por script (útil como Remediation en Intune), aquí tienes un PowerShell sencillo para crear el valor y verificarlo:

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

Esto cubre el caso en el que Intune diga que se aplicó, pero quieras máxima certeza o solucionar equipos “rebeldes”. Para auditar en masa, combina el script con tu herramienta de inventario o con reportes de Intune/Defender for Endpoint.

Desactivar LLMNR en Linux (systemd-resolved)

En distribuciones como Ubuntu o Debian que usan systemd-resolved, puedes “matar” LLMNR de forma directa. Edita la configuración del resolvedor así:

sudo nano /etc/systemd/resolved.conf

En el archivo, establece el parámetro correspondiente para que quede sin ambigüedades. Por ejemplo:

[Resolve]
LLMNR=no

Guarda y reinicia el servicio o el equipo: reiniciar el servicio suele bastar, aunque un reboot también es válido si te resulta más cómodo.

sudo systemctl restart systemd-resolved

Con eso, systemd-resolved dejará de usar LLMNR. Si empleas otra solución de resolución (o en otras distros), revisa su documentación: el patrón no difiere demasiado y siempre hay un “interruptor” equivalente.

Sobre NBT‑NS y el cortafuegos de Windows

Desactivar LLMNR es la mitad del trabajo. Responder y herramientas similares también explotan NetBIOS Name Service (NBT‑NS), que funciona sobre los puertos clásicos de NetBIOS (UDP 137/138 y TCP 139). Aquí surge la pregunta que muchos se hacen: ¿basta con bloquear los puertos en el firewall o hay que deshabilitar NBT‑NS explícitamente?

Si aplicas reglas estrictas en el cortafuegos local —tanto de entrada como de salida— bloqueando 137/UDP, 138/UDP y 139/TCP, reduces mucho la exposición. No obstante, la mejor práctica en entornos empresariales es deshabilitar NetBIOS sobre TCP/IP en las interfaces, para evitar respuestas o anuncios no deseados si cambia la política de firewall o alguna aplicación la modifica.

En Windows, no hay un GPO “de fábrica” tan directo como en LLMNR, pero puedes hacerlo vía WMI o Registro. Este PowerShell basado en WMI lo deshabilita en todos los adaptadores con IP habilitada:

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

Si prefieres reglas de firewall, adelante, pero asegúrate de que son bidireccionales y persistentes. Bloquea 137/UDP, 138/UDP y 139/TCP y supervisa que no haya reglas contradictorias en otras GPO o en soluciones EDR/AV que gestionen el firewall.

Verificación: cómo comprobar que LLMNR y NBT‑NS están fuera de juego

Para LLMNR en Windows, mira el Registro: HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableMulticast debe existir y valer 0. La comprobación rápida en PowerShell sería:

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

A nivel de tráfico, una técnica simple es lanzar una búsqueda a un nombre inexistente y observar con Wireshark que no salgan paquetes UDP 5355. Si no ves multidifusión al segmento local, vas por buen camino.

En Linux con systemd-resolved, revisa el estado con resolvectl o systemctl: asegúrate de que LLMNR figure como “no” en la configuración efectiva y que el servicio se reinició sin errores.

Para NBT‑NS, confirma que tus reglas de firewall bloquean 137/UDP, 138/UDP y 139/TCP o que NetBIOS esté deshabilitado en los adaptadores. También puedes esnifar la red un rato para comprobar que no hay peticiones o anuncios NetBIOS al aire.

Preguntas frecuentes y matices útiles

• ¿Romperé algo al deshabilitar LLMNR? En redes con DNS bien mantenido, lo normal es que no. En entornos especiales o legados, valida primero en un grupo piloto y comunica el cambio a soporte.
• ¿Por qué gpedit muestra “No configurado” aunque Intune diga “Aplicado”? Porque el editor local no siempre refleja estados impuestos por MDM o CSP. La verdad está en el Registro y en los resultados efectivos, no en el texto de gpedit.
• ¿Es obligatorio deshabilitar NBT‑NS si bloqueo NetBIOS en el firewall? Si el bloqueo es completo y robusto, reduces mucho el riesgo. Aun así, deshabilitar NetBIOS sobre TCP/IP elimina respuestas a nivel de pila y evita sorpresas si cambian las reglas, así que es la opción preferible.
• ¿Hay scripts listos para deshabilitar LLMNR? Sí, por Registro o PowerShell, como has visto. Para Intune, empaqueta el script como Remediation y añade comprobación de cumplimiento.

Apagando LLMNR reduces la superficie de suplantación en la red local y cortas de raíz ataques de captura de hashes con herramientas como Responder. Si además bloqueas o deshabilitas NBT‑NS y cuidas tu DNS, tendrás un cóctel de seguridad sencillo y eficaz: menos ruido, menos riesgos y una red bastante más preparada para el día a día.