Qué es NetBIOS y sus alternativas modernas DNS y mDNS

En muchas redes domésticas y de empresa todavía aparecen términos como NetBIOS, DNS o mDNS, a veces mezclados como si fueran lo mismo, cuando en realidad cumplen papeles muy distintos. Si llevas años usando Windows, seguro que has visto nombres de equipos compartiendo carpetas o impresoras sin tener ni idea de qué protocolo había detrás haciéndolo posible.

La realidad es que NetBIOS fue durante décadas la forma estándar de identificar equipos en redes Windows, pero hoy está claramente desfasado, introduce riesgos de seguridad y existen alternativas modernas mucho más robustas como DNS y mDNS. Entender bien cómo funciona cada uno, dónde encaja y cuándo conviene desactivarlo es clave para evitar quebraderos de cabeza y problemas de seguridad en tu red.

Qué es NetBIOS y cómo funciona realmente

NetBIOS (Network Basic Input/Output System) no es un protocolo de transporte en sí mismo, sino una interfaz de programación y un conjunto de servicios pensados para que las aplicaciones se comuniquen en red sin preocuparse de los detalles de bajo nivel. Nació en los años 80, mucho antes de que TCP/IP se estandarizara en el entorno Windows.

En el modelo OSI, NetBIOS se sitúa en la capa 5 (capa de sesión), por lo que necesita apoyarse en otros protocolos para mover los datos (como TCP o UDP) tanto en redes cableadas LAN como en redes inalámbricas. No define un formato de datos propio de transporte; lo que hace es facilitar a las aplicaciones la apertura de sesiones, el envío de mensajes y la gestión de errores.

Desde el punto de vista del usuario, NetBIOS se usaba para algo tan simple como “ver el nombre del ordenador” en la red. Cada equipo dentro de una red con soporte NetBIOS tiene un nombre único, que es el que aparece cuando navegas por recursos compartidos o grupos de trabajo en versiones antiguas de Windows.

Aunque hoy se considera una tecnología en fase final de vida, sigue estando activada por defecto en muchas instalaciones de Windows por motivos de compatibilidad hacia atrás. Eso implica que, aunque apenas la utilices, esa funcionalidad está ahí, visible y potencialmente explotable a nivel de seguridad.

NetBIOS ofrece tres servicios principales, cada uno en un puerto concreto y con un rol muy definido dentro de la comunicación en red:

• Servicio de sesión: es un servicio orientado a conexión que puede trabajar en modo cliente/servidor o peer-to-peer. Se apoya en TCP y utiliza el puerto 139. Gestiona la apertura, mantenimiento y cierre de sesiones entre dos equipos que intercambian datos.
• Servicio de datagramas: proporciona un mecanismo sin conexión, usando mensajes tipo datagrama que normalmente se envían en broadcast. Funciona sobre UDP en el puerto 138 y es el que genera buena parte del tráfico de difusión clásico de las redes Windows antiguas.
• Servicio de nombres: se encarga de registrar y resolver nombres NetBIOS en direcciones IP. Cuando se ejecuta sobre TCP/IP, se basa en UDP puerto 137. Este servicio puede apoyarse en archivos locales como LMHOSTS o en un servidor WINS (Windows Internet Name Service), que actúa como base de datos dinámica de nombres.

Ventajas e inconvenientes de seguir usando NetBIOS

Aunque NetBIOS esté anticuado, todavía arrastra algunas ventajas que explican por qué sigue activo en tantos equipos Windows, sobre todo en entornos donde conviven sistemas viejos y nuevos.

Entre los puntos a favor de NetBIOS podemos destacar varios aspectos prácticos que, durante años, hicieron la vida más fácil a los administradores y usuarios:

• Resolución automática de nombres sin configuración compleja: en redes pequeñas, NetBIOS permite que los equipos se vean por nombre sin tener que montar un servidor DNS ni tocar demasiada configuración. Para el usuario “de a pie” era cómodo: encender el PC y ver que la carpeta compartida del otro equipo simplemente aparecía.
• Integración profunda con Windows clásico: NetBIOS viene habilitado en todas las sesiones de Windows heredadas y fue la base de muchas aplicaciones de red, especialmente en la época de Windows NT, 2000 o XP. Por eso hay software antiguo que todavía lo necesita.
• Abstracción para los desarrolladores: al ofrecer una interfaz estándar, los programadores no tenían que reinventar rutinas de recuperación ante errores de enrutamiento o problemas de direccionamiento de bajo nivel.

Sin embargo, la lista de desventajas pesa hoy bastante más que la de beneficios, especialmente desde el punto de vista de seguridad y escalabilidad:

• No define un formato estándar de datos para sus transmisiones, lo que lo hace poco flexible frente a arquitecturas modernas donde se busca interoperabilidad entre muchas pilas de red y sistemas diferentes.
• Escala mal en redes grandes: el uso intensivo de broadcast y datagramas sin conexión tiende a sobrecargar la red cuando el número de equipos crece, generando tráfico innecesario y dificultando la gestión.
• Es un protocolo considerado inseguro y obsoleto: arrastra vulnerabilidades históricas, carece de los controles modernos de endurecimiento y, en general, supone una superficie de ataque adicional que muchos administradores prefieren eliminar deshabilitándolo.

Efectos de desactivar NetBIOS en el rendimiento y la seguridad

Apagar NetBIOS en un equipo Windows moderno suele tener más impacto en la seguridad que en el rendimiento, y casi siempre para bien. Pero conviene entender qué se puede romper por el camino.

Desde el punto de vista de rendimiento, normalmente el cambio no es dramático. NetBIOS se usa para resolver nombres en la red local y para que determinados dispositivos intercambien información. Las versiones actuales de Windows confían sobre todo en DNS y en TCP/IP puro, por lo que NetBIOS queda casi en segundo plano.

Al deshabilitarlo, se reduce la superficie expuesta a ataques como denegaciones de servicio (DoS) o intentos de enumerar recursos y dispositivos. Un atacante puede aprovechar servicios NetBIOS abiertos para saturar la red, obtener nombres y direcciones IP internas o incluso intentar acceder a carpetas compartidas mal configuradas.

El mayor riesgo está en compatibilidades con aplicaciones antiguas: programas de gestión, bases de datos heredadas o herramientas muy viejas pueden depender del transporte SMB 1.0 sobre NetBIOS. Si desactivas NetBIOS de golpe, algunas de estas aplicaciones podrían volverse lentas, fallar de manera intermitente o dejar directamente de funcionar.

También pueden verse afectadas las funcionalidades de compartición en red como impresoras, unidades mapeadas o recursos compartidos que todavía anuncian o resuelven nombres mediante NetBIOS. Si esos recursos no están correctamente registrados en DNS ni utilizan protocolos más modernos, podrían volverse inaccesibles.

Lo recomendable es hacer un pequeño inventario o análisis previo: comprobar qué aplicaciones y equipos todavía usan NetBIOS (por ejemplo, capturando tráfico con herramientas como Wireshark) y valorar, caso por caso, si se puede migrar su funcionamiento a SMB más moderno, DNS o mDNS antes de pulsar el “botón rojo” y apagarlo en toda la red.

Peligros de NetBIOS en redes públicas y entornos poco controlados

Tener NetBIOS activo en una red pública (WiFi de cafetería, aeropuerto, hotel, etc.) es directamente una mala idea, porque expone datos sobre tu equipo y puede facilitar ataques sin que te des ni cuenta.

Uno de los principales riesgos es el acceso no autorizado a recursos compartidos: si tu portátil comparte alguna carpeta o impresora a través de protocolos ligados a NetBIOS, un ciberdelincuente en la misma red podría intentar localizar esos recursos y entrar en ellos si la configuración de permisos no es estricta.

Otro peligro es el espionaje en red o información de reconocimiento. Mediante NetBIOS se puede descubrir el nombre del equipo, posibles grupos de trabajo, a veces el sistema operativo y su dirección IP. Esta información, aunque parezca inocente, ayuda a un atacante a construir un mapa de la red y seleccionar objetivos.

NetBIOS también se ha explotado para difundir malware: gusanos, ransomware y otros tipos de código malicioso han utilizado sus vulnerabilidades y la facilidad de enumerar equipos para saltar de un dispositivo a otro en redes internas mal segmentadas.

Por todo ello, en redes que no controlas conviene minimizar al máximo los servicios legacy. Desactivar NetBIOS, apagar recursos compartidos innecesarios y usar siempre cortafuegos activos es casi obligatorio si te conectas habitualmente a WiFi públicas.

Nombres NetBIOS y resolución de nombres con DNS

Uno de los puntos que más confusión genera es la diferencia entre nombres NetBIOS y nombres DNS. Aunque a veces coinciden, no son lo mismo ni se resuelven de la misma forma.

Un nombre de equipo NetBIOS suele ser una única etiqueta, una cadena simple que identifica al host en el ámbito NetBIOS. Por ejemplo, «SERVIDOR01» o «PORTATIL-MARIA». Este nombre se registra a través del servicio de nombres NetBIOS y se anuncia por broadcast o mediante WINS.

DNS, en cambio, trabaja con nombres de dominio compuestos por varias partes: un nombre de host y un nombre de dominio que juntos forman el FQDN (Fully Qualified Domain Name). Por ejemplo, «servidor01.empresa.local» o «fileserver.corp.ejemplo.com». Esta estructura jerárquica se diseñó pensando en grandes redes e Internet.

En muchos productos (como SunLink Server y entornos similares) se combinan ambos mundos: el software toma el nombre NetBIOS del equipo y lo concatena con el dominio DNS para generar el FQDN, lo que garantiza interoperabilidad entre aplicaciones pensadas para NetBIOS y las basadas en TCP/IP puro.

Para resolver nombres en redes TCP/IP, los equipos pueden recurrir a varios métodos además de simples queries DNS a servidores externos:

• WINS (Windows Internet Name Service): mantiene una base de datos dinámica que asocia nombres NetBIOS con direcciones IP. Es útil en entornos con muchas subredes donde los broadcasts puros no son prácticos.
• Resolución por broadcast NetBIOS (b-node): definida en los RFC 1001/1002, hace que cada equipo difunda su nombre por la red IP y responda a las peticiones que lo consultan. Simple, pero muy ruidoso a escala.
• Resolución por DNS estándar: se usa para buscar asociaciones entre nombres DNS y direcciones IP, especialmente cuando se accede a servicios fuera de la subred local. Algunas soluciones heredadas, como ciertos servidores de archivos, pueden no aprovechar esto directamente.
• Archivos LMHOSTS y HOSTS: permiten definir manualmente correspondencias estáticas. LMHOSTS se utiliza con NetBIOS sobre TCP/IP para nombres de equipos Microsoft; HOSTS se usa para nombres DNS generales en aplicaciones tipo Windows Sockets.

Una anécdota muy habitual en redes mixtas es que un mismo equipo responda bien por IP y por nombre NetBIOS, pero no por nombre DNS. En estos casos, suele haber diferencias de versión de SMB y problemas de negociación de protocolo (por ejemplo, un cliente con SMB1 deshabilitado frente a un servidor muy antiguo) que explican errores del estilo «SMB1 deshabilitado — no hay grupo de trabajo disponible» al listar recursos con smbclient.

mDNS: la alternativa ligera para redes locales sin servidor DNS

Cuando hablamos de redes pequeñas sin un servidor DNS propio, entra en juego mDNS (multicast DNS), una tecnología pensada para que los dispositivos se descubran entre sí sin un servidor centralizado, utilizando multicast en lugar de un servidor de nombres tradicional.

mDNS forma parte del concepto Zero Configuration Networking (Zeroconf), impulsado inicialmente por Apple a principios de los 2000. Apple lo implementó en su tecnología Bonjour para que Macs, impresoras y otros dispositivos se encuentren de forma automática en la red local.

Con el tiempo, mDNS se estandarizó en el RFC 6762 de la IETF y se incorporó también a Linux y, más adelante, a Windows. Hoy en día, dispositivos como Chromecast o altavoces inteligentes se basan en mDNS para anunciar servicios y ser detectados sin que el usuario configure nada.

El funcionamiento básico de mDNS es sencillo pero muy efectivo. Cuando un dispositivo quiere resolver un nombre del estilo equipo.local, envía una consulta UDP a la dirección multicast 224.0.0.251 (IPv4) o ff02::fb (IPv6) por el puerto 5353. Todos los equipos que escuchan en esa dirección reciben la consulta.

Si alguno de esos equipos es el dueño del nombre solicitado, responde mediante otro mensaje multicast indicando la correspondencia entre el nombre y su dirección IP. Todos los participantes en la red reciben esa respuesta, actualizan su caché mDNS y, mientras la información siga siendo válida, no hace falta repetir la consulta para ese nombre.

Para evitar saturar la red, mDNS incluye mecanismos de ahorro de tráfico. Por ejemplo, el cliente que tiene una respuesta en caché puede “anunciar” lo que cree que es correcto, y solo si el poseedor real del nombre detecta que la información está obsoleta envía su propia respuesta. Así se limita el número de mensajes necesarios para mantener actualizadas las cachés.

Es importante tener en cuenta que mDNS se limita prácticamente al dominio especial «.local». Los nombres de host con esta extensión se resuelven vía multicast en la red local, pero otros TLD como «.com» o «.es» no se procesan mediante mDNS, sino que se dejan para la resolución DNS clásica. Por tanto, mDNS no sirve para resolver direcciones web públicas.

En el ecosistema Windows la evolución de los protocolos de resolución local ha sido la siguiente:

• En versiones hasta Windows XP predominaba el uso de NetBIOS Name Service con broadcast para anunciar nombres, lo que generaba bastante ruido de red.
• Desde Windows Vista se introdujo LLMNR (Link-Local Multicast Name Resolution), que cambiaba el broadcast por multicast, pero seguía siendo una tecnología principalmente pensada para entornos Windows.
• A partir de Windows 10, Microsoft apuesta por mDNS, heredado del mundo Unix-like, para ofrecer una mayor compatibilidad con dispositivos de terceros y seguir la línea de los estándares abiertos.

Por tanto, si lo que quieres es una red doméstica moderna donde los equipos se descubran por nombre sin montar un servidor DNS, la combinación de DNS del router para el acceso a Internet y mDNS para servicios locales es mucho más limpia y estándar que seguir dependiendo de NetBIOS.

Convenciones de nombres NetBIOS y DNS en Windows y Active Directory

En entornos profesionales, elegir bien los nombres de equipos, dominios y unidades organizativas es algo más serio de lo que parece. Windows y Active Directory aplican reglas bastante estrictas sobre qué caracteres son válidos, longitudes máximas y nombres reservados, tanto para NetBIOS como para DNS.

Para los nombres de equipo NetBIOS se aplican, a grandes rasgos, las siguientes reglas:

• Caracteres permitidos: todos los caracteres alfanuméricos (ASCII) y el punto, siempre que el nombre no empiece por punto. Como en la práctica el nombre NetBIOS suele coincidir con el hostname DNS, también hereda varias restricciones de este último.
• Caracteres prohibidos: no se permiten, entre otros, barra invertida (\), barra normal (/), dos puntos (:), asterisco (*), interrogación (?), comillas dobles («), menor que (<), mayor que (>), barra vertical (|) o coma (,).
• Longitud: mínimo 1 carácter y máximo 15 caracteres efectivos. Windows reserva internamente el 16.º carácter para identificar servicios.
• Mayúsculas y minúsculas: aunque NetBIOS distingue entre ellas, Windows utiliza nombres en mayúsculas y, en la práctica, el sistema no es sensible a mayúsculas/minúsculas.
• Punto como separador de ámbito: un punto puede dividir el nombre en identificador de ámbito NetBIOS y nombre de equipo, pero el uso de ámbitos es una reliquia que no se recomienda en bosques modernos de Active Directory.

Los nombres de host DNS y los nombres de dominio DNS tienen su propio conjunto de normas que buscan garantizar compatibilidad con los RFC y con servidores que no sean de Microsoft:

• Caracteres válidos: letras A-Z, números 0-9, guion (-) y punto (.) para separar etiquetas dentro del nombre de dominio.
• Caracteres no permitidos: se excluyen caracteres como coma, tilde, dos puntos, exclamación, arroba, almohadilla, dólar, porcentaje, acento circunflejo, ampersand, apóstrofo, paréntesis, llaves, subrayado y espacios en blanco, entre otros.
• Reglas de formato: el primer carácter debe ser alfanumérico; el último no puede ser guion ni punto. Además, nombres que contengan solo números no son válidos para equipos miembros de un dominio AD por restricciones de DNS.
• Longitud máxima: cada etiqueta del nombre (entre puntos) puede tener hasta 63 caracteres; el FQDN completo puede llegar hasta 255 caracteres en DNS y hay límites prácticos como que el FQDN de un controlador de dominio no exceda unos 155 bytes por temas de rutas SYSVOL.

Windows también mantiene una tabla de palabras reservadas que no deberían usarse como nombres de cuentas, dominios o sitios (por ejemplo, SYSTEM, SERVER, ANONYMOUS, USERS, INTERNET, DOMAIN, COMPANY, etc.). Ignorar estas recomendaciones puede provocar problemas raros con relaciones de confianza, replicación o scripts que dan por hecho que esos nombres se refieren a entidades especiales.

Otro concepto delicado es el de los espacios de nombres separados, que aparecen cuando el sufijo DNS principal del equipo no coincide con el dominio DNS al que pertenece. Esto puede suceder al actualizar antiguos controladores de dominio NT 4.0 a bosques Windows modernos o al renombrar dominios sin ajustar el sufijo primario de los equipos.

En un espacio de nombres separado, el controlador de dominio registra sus registros SRV en la zona de su dominio, pero registra su host A en otra zona distinta (la asociada a su sufijo DNS principal). Esto puede liar al servicio DNS al localizar controladores y generar comportamientos extrañas en la resolución de nombres.

Como buenas prácticas generales para nombres DNS en infraestructuras Active Directory, se suele recomendar:

• Usar nombres fáciles de recordar y que indiquen propósito u organización del equipo.
• Alinear el nombre del dominio AD con el sufijo DNS principal de los equipos.
• Evitar TLD genéricos (.com, .net, .org) para intranets que puedan chocar con nombres públicos.
• No utilizar el TLD .local para nuevos bosques, ya que está estrechamente asociado a mDNS.
• Reducir la profundidad jerárquica de dominios a no más de cinco niveles desde la raíz para simplificar gestión.

En cuanto a nombres de unidades organizativas (OU) y sitios de Active Directory, las restricciones son más relajadas, pero la recomendación es la misma: escoger nombres descriptivos, razonablemente cortos y que no lleven a confusiones futuras (por ejemplo, evitar que una OU raíz tenga el mismo nombre que un futuro subdominio).

NetBIOS en entornos empresariales modernos

Aunque NetBIOS ya no sea la estrella de la fiesta, todavía aguanta vivo en muchas empresas, sobre todo allí donde se sigue dependiendo de aplicaciones heredadas o sistemas antiguos como Windows XP o Windows Server 2003.

En más de una organización siguen corriendo aplicaciones de negocio críticas desarrolladas en los años 90 o principios de los 2000, desde software de gestión hasta sistemas de bases de datos que fueron diseñados pensando en SMB 1.0 sobre NetBIOS. Migrarlas requiere tiempo, presupuesto y pruebas, así que muchas empresas prefieren “no tocar” mientras todo funcione.

El problema es que en el contexto actual la seguridad es una prioridad absoluta. NetBIOS y SMB 1.0 forman parte de la superficie de ataque favorita de muchos malware y herramientas de intrusión, porque permiten enumerar dispositivos, descubrir recursos compartidos mal protegidos e incluso inyectar o propagar código malicioso.

En redes donde ya existe Active Directory y DNS bien configurado, NetBIOS suele ser redundante. Los controladores de dominio y los clientes pueden resolver nombres vía DNS, autenticar con Kerberos y usar SMB en versiones modernas sin necesidad de tirar de servicios legacy.

Lo razonable en una empresa es que los administradores de sistemas hagan un análisis previo: revisar qué equipos y aplicaciones siguen usando NetBIOS (por ejemplo, con capturas de tráfico o revisando los puertos 137-139), documentar esas dependencias y planificar su sustitución por soluciones soportadas.

La experiencia de muchas organizaciones muestra que mantener NetBIOS operativo en redes corporativas normalmente genera más quebraderos de cabeza que ventajas, especialmente cuando hay requisitos fuertes de cumplimiento, auditoría o segmentación de red.

Cómo desactivar NetBIOS en Windows 10 y 11 paso a paso

En equipos modernos con Windows 10 u 11 es bastante sencillo desactivar NetBIOS, y además se puede hacer de varias maneras: a través de la configuración TCP/IP, del Editor del Registro o usando la línea de comandos con WMI.

Desactivar NetBIOS desde las propiedades TCP/IP

El método más directo para muchos usuarios es usar la interfaz gráfica de red, tocando la configuración avanzada del adaptador que esté en uso (Wi-Fi o Ethernet).

1. Abre el menú Inicio y entra en Configuración > Red e Internet.
2. Haz clic en Cambiar opciones del adaptador para ver las interfaces de red disponibles.
3. Sobre el adaptador que uses (Wi-Fi o LAN), pulsa con el botón derecho y selecciona Propiedades.
4. Selecciona Protocolo de Internet versión 4 (TCP/IPv4) y pulsa en Propiedades.
5. En la ventana que aparece, ve a Opciones avanzadas y abre la pestaña WINS.
6. Marca la opción Deshabilitar NetBIOS sobre TCP/IP, acepta todos los cuadros de diálogo y cierra.

Desde ese momento, ese adaptador dejará de usar NetBIOS. Si en el futuro necesitas volver a activarlo, basta con repetir los mismos pasos y seleccionar la opción de habilitar o dejar que la configuración la controle el DHCP.

Deshabilitar NetBIOS desde el Editor del Registro

Si prefieres un control más fino o quieres aplicar el cambio mediante scripts o GPO, puedes hacerlo a través del Registro de Windows, modificando el valor de configuración correspondiente al adaptador.

1. Abre el menú Inicio, escribe Editor del Registro y ejecútalo (o pulsa Win + R, escribe regedit y acepta).
2. Navega hasta la clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces.
3. Dentro verás varias claves Tcpip, una por cada adaptador. Selecciona la que corresponda al interfaz en el que quieres desactivar NetBIOS.
4. En el panel derecho, localiza el valor NetbiosOptions y haz doble clic sobre él.
5. Cambia su valor a 2 para deshabilitar NetBIOS sobre TCP/IP y guarda los cambios.

Tras aplicar este ajuste, NetBIOS quedará desactivado para el adaptador seleccionado. El procedimiento es similar para Windows 10 y Windows 11, y puede integrarse en scripts de automatización para múltiples equipos.

Desactivar NetBIOS desde el Símbolo del sistema

Otra vía muy útil en entornos de administración es emplear WMI desde la línea de comandos, sobre todo si quieres automatizarlo o documentar el cambio paso a paso.

1. Abre una ventana de Símbolo del sistema (cmd), ya sea desde el menú Inicio o con Win + R y escribiendo cmd.
2. Ejecuta el comando:
   wmic nicconfig get caption,index,TcpipNetbiosOptions
3. Anota el índice del adaptador en el que quieres desactivar NetBIOS (la columna index).
4. Lanza el comando:
   wmic nicconfig where index=X call SetTcpipNetbios 2
   sustituyendo X por el número de índice del adaptador (por ejemplo, 4).

Con este comando, NetBIOS sobre TCP/IP queda desactivado en el adaptador escogido. Es una forma rápida de aplicar el cambio en varios equipos mediante scripts o herramientas de gestión remota.

Deshabilitar NetBIOS desde el servidor DHCP

Si gestionas una red con servidor DHCP propio, también puedes forzar el comportamiento de NetBIOS desde el lado del servidor, de modo que todos los clientes que obtengan IP de ese ámbito reciban la instrucción de desactivar NetBIOS.

1. En el servidor, ve a Inicio > Programas > Herramientas administrativas > DHCP.
2. En el panel de navegación, despliega tu servidor, luego el Ámbito correspondiente y entra en Opciones de ámbito.
3. Pulsa en Configurar opciones y ve a la pestaña Opciones avanzadas.
4. En la lista Clase de proveedor, elige Opciones de Microsoft Windows 2000 (o la que corresponda para tus clientes).
5. Asegúrate de que la clase de usuario sea la predeterminada (Clase de usuario).
6. Activa la casilla 001 Opción deshabilitar NetBIOS de Microsoft en las opciones disponibles.
7. En el área de Entrada de datos, introduce 0x2 y confirma con Aceptar.

Desde ese momento, los clientes que reciban configuración de ese ámbito de DHCP interpretarán que deben desactivar NetBIOS sobre TCP/IP, alineando así el comportamiento de toda la red sin tener que tocar cada equipo uno a uno.

Por qué merece la pena desactivar NetBIOS hoy

Más allá de los detalles técnicos, la gran razón para plantearse desactivar NetBIOS es la seguridad. Es un protocolo antiguo, poco mantenido y que permanece activo por defecto en muchos sistemas sin que nadie lo necesite realmente.

Muchos ataques modernos se apoyan en protocolos obsoletos, ya sea porque no reciben parches, porque no incorporan medidas de protección actuales o simplemente porque la gente los deja activados por inercia. A esto se suma el hecho de que NetBIOS viene habilitado desde el primer arranque en numerosos equipos con Windows, generando una puerta más para explorar por parte del atacante.

Eso no quiere decir que NetBIOS sea “maligno” por diseño, sino que ha pasado su fecha de caducidad. Igual que no tiene sentido usar versiones viejas de WinRAR con vulnerabilidades conocidas o suites de Office sin soporte, tampoco tiene mucha lógica seguir confiando en un protocolo que la propia plataforma ha ido reemplazando por alternativas más seguras.

En un contexto en el que DNS, mDNS, SMB moderno y Active Directory cubren todas las necesidades de resolución de nombres y compartición, mantener NetBIOS operativo suele ser más un lastre que un beneficio. Si detectas que ya no hay dependencias claras (o puedes sustituir las que quedan), deshabilitarlo es un paso sencillo para reforzar la seguridad general de la red.

Se trata de ir cerrando puertas viejas que no aportan nada: revisar qué servicios están realmente en uso, apagar lo que se ha quedado obsoleto y apoyarse en estándares modernos como DNS y mDNS para que los equipos se sigan encontrando, pero de forma más robusta y segura, tanto en casa como en la oficina.