Qué es el SMBv1 y por qué deberías asegurarte de que está desactivado

Cuando surgen problemas para acceder a una carpeta compartida o una impresora en red, muchos expertos afirman que «es cosa del SMB». Y así es. Server Message Block y, en concreto, SMBv1, han sido durante décadas el corazón del intercambio de archivos en Windows, pero hoy son también una de sus mayores fuentes de problemas de seguridad.

Aunque SMBv1 parece un tecnicismo de esos que solo preocupan a admins de sistemas, lo cierto es que este protocolo está directamente relacionado con ataques de ransomware tan sonados como WannaCry o infecciones basadas en EternalBlue. Entender qué es, qué lo diferencia de SMBv2/SMBv3 y cómo activarlo o desactivarlo en Windows 10, Windows 11 y Windows Server es básico para no dejar la puerta abierta a un desastre.

Qué es SMB y cómo encaja SMBv1 dentro del protocolo

 

SMB (Server Message Block) es un protocolo de red de tipo cliente-servidor diseñado para compartir archivos, carpetas, impresoras y otros recursos entre equipos dentro de una red local (LAN) o, desde hace años, también a través de redes IP más amplias.

Su funcionamiento se basa en que un cliente SMB solicita acceso a un recurso remoto y un servidor SMB responde: abrir un archivo, listar el contenido de un directorio, mandar un documento a imprimir, mapear una unidad de red, etc. Esta comunicación se realiza mediante un intercambio de mensajes de petición y respuesta que se apoyan normalmente en el protocolo TCP.

En sus orígenes, SMB se apoyaba sobre NetBIOS y el puerto 139, limitado a redes locales. Con la llegada de Windows 2000, Microsoft trasladó el protocolo directamente sobre TCP/IP usando el puerto 445, lo que permite la comunicación SMB a través de redes IP sin necesidad de NetBIOS.

El protocolo no es exclusivo de Windows: Samba implementa SMB/CIFS en sistemas Unix y Linux, permitiendo que equipos Linux actúen como servidores y clientes SMB totalmente compatibles con Windows. Otras implementaciones destacadas son Netsmb en sistemas BSD, librerías como YNQ para sistemas embebidos o soluciones NAS como FreeNAS y ConnectedNAS (Android), que utilizan SMB para compartir datos.

Origen y evolución de SMB: de SMBv1 a SMB 3.1.1

La historia de SMB es larga. IBM creó el protocolo en los años 80 y Microsoft lo adoptó en su producto LAN Manager. Con el tiempo, la implementación de SMB 1.0 por parte de Microsoft se rebautizó como CIFS (Common Internet File System), un término que todavía se sigue usando, aunque en realidad hace referencia a esa primera generación del protocolo.

La implementación inicial de SMB/CIFS tenía múltiples carencias: mucho ruido de protocolo (demasiados comandos), baja eficiencia en redes con latencia y poca escalabilidad. Era válida para gestionar archivos pequeños en redes locales sencillas, pero se quedaba corta en escenarios más complejos o lejanos.

En paralelo, el proyecto Samba nació con el objetivo de revertir por ingeniería inversa el protocolo SMB/CIFS y ofrecer un servidor compatible para sistemas Unix y Linux. Esto permitió a clientes MS-DOS y posteriores versiones de Windows acceder a recursos alojados en máquinas no Windows.

SMBv1 o SMB/CIFS versión 1: la rama obsoleta

SMBv1 es la primera versión del protocolo, desarrollada a partir de 1983. Inicialmente dependía de NetBIOS, aunque en versiones posteriores de Windows se permitió ejecutarlo directamente sobre TCP/IP. Todas las versiones antiguas de Windows (como Windows XP, Windows Server 2003, etc.) utilizan SMBv1 por defecto.

Con el paso del tiempo se han ido descubriendo importantes fallos de seguridad y limitaciones de rendimiento en SMBv1. Microsoft lo considera hoy un protocolo inseguro y obsoleto: en Windows 10 (versiones recientes), Windows 11 y Windows Server 2016/2019/2022, SMBv1 ya no se instala de serie o viene deshabilitado.

Aun así, muchos dispositivos antiguos como ciertos NAS domésticos, impresoras multifunción o routers siguen usando solo SMBv1. En esos casos, el usuario se ve tentado a reactivarlo en su PC, asumiendo sin saberlo un riesgo considerable.

SMB 2.0 y 2.1: salto de rendimiento y eficiencia

Para resolver las limitaciones del protocolo inicial, Microsoft lanzó SMB 2.0 con Windows Vista y Windows Server 2008. Esta versión supuso un rediseño profundo, reduciendo el número de comandos y subcomandos de cientos a menos de una veintena, minimizando el tráfico innecesario.

Entre las mejoras clave de SMBv2 destacan: lecturas y escrituras de mayor tamaño, agrupación de solicitudes (pipelining), soporte para múltiples acciones en una sola petición, almacenamiento en caché de propiedades de archivos y carpetas e identificadores duraderos, que permiten reconectar tras pequeños cortes sin rehacer toda la sesión.

SMB 2.0 también introduce firmado de mensajes con HMAC-SHA256 en lugar de MD5, una escalabilidad mucho mayor en número de usuarios, recursos y archivos abiertos, soporte de tamaños de bloque más grandes (ideal para redes Gigabit, 10 GbE o superiores) y compatibilidad con enlaces simbólicos.

Posteriormente, SMB 2.1 llegó con Windows 7 y Windows Server 2008 R2, con optimizaciones adicionales, como nuevos mecanismos de bloqueo oportunista para mejorar aún más el rendimiento en entornos con alta concurrencia.

SMB 3.0, 3.0.2 y 3.1.1: seguridad y centros de datos virtualizados

Con Windows 8 y Windows Server 2012 apareció SMB 3.0 (originalmente llamado SMB 2.2). Esta versión se orientó especialmente al uso en centros de datos virtualizados y escenarios de alta disponibilidad, con mejoras tanto de rendimiento como de resiliencia.

Entre sus novedades encontramos: SMB Direct (SMB sobre RDMA) para un acceso de altísimo rendimiento y baja latencia, SMB Multichannel (múltiples conexiones por sesión para aprovechar varias interfaces de red), conmutación por error transparente en clústeres y, algo clave, cifrado de extremo a extremo del tráfico SMB.

A nivel de seguridad, SMB 3.0 permite cifrar el tráfico de datos y obliga a que la autenticación del usuario se realice de forma segura, evitando credenciales en texto claro. Si el hardware lo soporta (AES-NI u otras aceleraciones), y conviene comprobar drivers en Windows, el impacto en rendimiento puede ser mínimo incluso con cifrado activado.

Con Windows 8.1 y Windows Server 2012 R2 se introdujo SMB 3.0.2, con mejoras incrementales y la posibilidad de deshabilitar explícitamente SMB 1.0, favoreciendo así entornos donde solo se negocien versiones modernas del protocolo.

La última iteración es SMB 3.1.1, presente en Windows 10 y Windows Server 2016 en adelante. Esta versión añade verificación de integridad previa a la autenticación con SHA-256, cifrado AES-128-GCM (además de CCM) y obliga a que las negociaciones de clientes SMB 2.0 o superiores se hagan de forma segura. El objetivo es endurecer al máximo la fase crítica de establecimiento de la sesión.

Qué es exactamente SMBv1 y por qué es tan inseguro

SMBv1, también conocido como SMB 1.0 o CIFS, es el dialecto más antiguo del protocolo SMB. Durante años fue la base del uso compartido de archivos y de la comunicación entre procesos en entornos Windows, de ahí que todavía muchos equipos antiguos y dispositivos heredados lo exijan.

El problema es que SMBv1 arrastra debilidades estructurales que lo hacen extremadamente vulnerable frente a ataques de denegación de servicio (DoS) y, especialmente, a vulnerabilidades de ejecución remota de código (RCE). Entre sus carencias destacan la ausencia de mecanismos modernos de cifrado, una negociación poco robusta y un diseño que no contemplaba las amenazas actuales.

En redes reales suele ocurrir que, por compatibilidad, todas las versiones de SMB quedan habilitadas a la vez. Un atacante puede forzar un «downgrade» de la comunicación a SMBv1 aunque existan versiones más nuevas disponibles, y aprovechar así la superficie de ataque de la versión antigua.

Microsoft considera SMBv1 tan problemático que ha dejado de instalarlo por defecto en Windows 10 (ediciones modernas), Windows 11 y Windows Server 2019 en adelante. En Windows 10 Home y Pro se llegó a incluir, pero la tendencia es retirarlo y desinstalarlo automáticamente si no se utiliza durante un tiempo.

Relación de SMBv1 con EternalBlue, WannaCry y otros exploits

El nombre de SMBv1 se hizo tristemente famoso por su papel en el ataque global de ransomware WannaCry en 2017. Este malware se apoyó en un exploit denominado EternalBlue, presuntamente desarrollado por la NSA y filtrado públicamente.

EternalBlue explota una vulnerabilidad crítica en la implementación de SMBv1 en Windows, permitiendo a un atacante ejecutar código arbitrario de forma remota en el equipo víctima, sin necesidad de credenciales válidas. Basta con que el puerto 445 esté accesible y el sistema no esté parcheado.

WannaCry aprovechó esta falla para propagarse de forma masiva y automática en redes corporativas y domésticas, cifrando archivos y pidiendo un rescate. Se habla de más de 200.000 equipos infectados en 150 países y pérdidas económicas de miles de millones de dólares.

No es el único caso. Se han identificado otras vulnerabilidades graves ligadas a SMBv3, como SMBGhost (CVE-2020-0796) y SMBleed (CVE-2020-1206), relacionadas con la función de descompresión del servidor SMBv3. Aunque no afectan directamente a SMBv1, demuestran que el ecosistema SMB es un objetivo constante para los atacantes.

En el caso de SMBleed, la falla en la función Srv2DecompressData permite filtrar memoria del kernel y manipular la compresión, especialmente peligrosa cuando se combina con SMBGhost para lograr ejecución remota de código. Los sistemas sin parchear que exponen el puerto 445 a redes no confiables son un blanco especialmente jugoso.

Por tanto, más allá de EternalBlue y WannaCry, cualquier organización que mantenga SMBv1 activo y sin proteger está aceptando un riesgo alto y totalmente evitable en su superficie de ataque.

Funciones que se pierden al deshabilitar SMBv1, SMBv2 o SMBv3

Antes de desactivar protocolos a lo loco conviene entender qué funcionalidades dependen de cada versión. SMBv1 apenas ofrece características que justifiquen su uso hoy en día, más allá de la compatibilidad con equipos muy antiguos.

En cambio, SMBv2 y SMBv3 introducen un amplio conjunto de mejoras de rendimiento, resiliencia y seguridad. Deshabilitarlos completamente puede causar problemas serios en entornos que dependen de estas características avanzadas.

Si deshabilitas SMBv3 en un servidor, por ejemplo, se pierden funciones como: conmutación por error transparente en clústeres, escalabilidad horizontal en servidores de archivos, SMB Multichannel, SMB Direct (RDMA), cifrado de extremo a extremo, arrendamiento de directorios (caché avanzada) y optimizaciones para E/S aleatoria.

Al deshabilitar SMBv2 se desactivan capacidades esenciales como: agrupación de solicitudes, lecturas/escrituras de mayor tamaño, almacenamiento en caché de propiedades, identificadores duraderos, firma de mensajes reforzada con HMAC-SHA256, soporte para grandes MTU, mejora de eficiencia energética y diversas optimizaciones de escalabilidad.

En Windows 8 y Windows Server 2012, las pilas de SMBv2 y SMBv3 van de la mano, de modo que al habilitar o deshabilitar SMBv2 también estás afectando a SMBv3. Esto hay que tenerlo en cuenta a la hora de hacer pruebas o endurecer configuraciones.

Cómo saber qué versión de SMB tienes en Windows

Para tomar decisiones con criterio, lo primero es comprobar qué versiones de SMB están instaladas y activas en tu equipo Windows. Hay varias formas de hacerlo, siendo PowerShell y el Registro de Windows las más comunes.

Comprobar SMB en Windows 10 y Windows 8.1 con PowerShell

Abre PowerShell con permisos de administrador y ejecuta estos comandos:

Para SMBv1 en Windows 10 / 8.1 (cliente y servidor):

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Para SMBv2/SMBv3 en Windows 10 / 8.1 (lado servidor):

Get-SmbServerConfiguration | Select EnableSMB2Protocol

Si el valor devuelto es True, ese protocolo está habilitado; si es False, está deshabilitado.

Comprobar SMB en Windows 7 mediante Registro

En Windows 7 no existe el componente opcional SMB1Protocol, así que la comprobación se hace inspeccionando la clave de Registro LanmanServer:

Para SMBv1:

Get-Item HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}

Para SMBv2:

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters | ForEach-Object {Get-ItemProperty $_.pspath}

Si no existe el valor SMB1 o SMB2 explícito, se asume el valor por defecto (habilitado). Si existen, un valor 0 implica deshabilitado y 1 habilitado.

Comprobar SMB mediante Editor del Registro

Otra opción es abrir regedit y navegar hasta:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

En esta clave, los valores SMB1 y SMB2 de tipo REG_DWORD determinan si el servidor SMB tiene activadas esas versiones. De nuevo, 0 significa deshabilitado y 1 habilitado; si no existe el valor, la configuración por defecto suele ser habilitado.

Cómo habilitar o deshabilitar SMBv1, SMBv2 y SMBv3 en Windows

Windows ofrece varias vías para gestionar el estado de los protocolos SMB: características opcionales, PowerShell, Registro, servicios e incluso Directiva de grupo para despliegues masivos. La recomendación actual es mantener SMBv2/SMBv3 habilitados y desactivar SMBv1 siempre que sea posible.

Gestionar SMBv1 con PowerShell (cliente y servidor)

En Windows 10 y versiones actuales de Windows Server puedes usar Get-WindowsOptionalFeature, Disable-WindowsOptionalFeature y Enable-WindowsOptionalFeature:

• Detectar SMBv1:
  Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
• Deshabilitar SMBv1:
  Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
• Habilitar SMBv1 (no recomendado salvo necesidad extrema):
  Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Estos comandos requieren ejecutarse en una consola de PowerShell con privilegios elevados. Tras habilitar o deshabilitar normalmente se recomienda reiniciar el sistema.

Gestionar SMBv2/SMBv3 con PowerShell (lado servidor)

Para SMBv2 y SMBv3, que comparten gran parte de la pila, se utilizan los cmdlets de configuración del servidor SMB:

Comprobar si SMBv2/3 está activo:

Get-SmbServerConfiguration | Select EnableSMB2Protocol

Habilitar SMBv2/3:

Set-SmbServerConfiguration -EnableSMB2Protocol $true

Deshabilitar SMBv2/3 (solo para pruebas muy controladas):

Set-SmbServerConfiguration -EnableSMB2Protocol $false

Para funciones exclusivas de SMBv3, como el cifrado de datos, puedes comprobar y cambiar el estado de EncryptData:

Ver si el cifrado SMBv3 está activo:

Get-SmbServerConfiguration | Select EncryptData

Habilitar cifrado de datos SMBv3:

Set-SmbServerConfiguration -EncryptData $true

Habilitar o deshabilitar SMB en el lado cliente con sc.exe

En clientes SMB (Windows y Windows Server actuando como clientes) también puedes ajustar el uso de SMBv1 y SMBv2/3 modificando dependencias y servicios con sc.exe:

SMBv1 en cliente SMB

• Detectar: sc.exe qc lanmanworkstation
• Deshabilitar: sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi y sc.exe config mrxsmb10 start= disabled
• Habilitar: sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi y sc.exe config mrxsmb10 start= auto

SMBv2/SMBv3 en cliente SMB

• Detectar: sc.exe qc lanmanworkstation
• Deshabilitar: sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi y sc.exe config mrxsmb20 start= disabled
• Habilitar: sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi y sc.exe config mrxsmb20 start= auto

Configurar SMB mediante el Editor del Registro

Si prefieres o necesitas hacerlo vía Registro, tanto en servidores como en clientes Windows puedes crear o modificar las claves SMB1 y SMB2 bajo la rama LanmanServer:

Ruta para servidor SMB:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

En esta ruta configura entradas con estas propiedades:

• Nombre: SMB1 o SMB2
• Tipo: REG_DWORD
• Datos: 0 = Deshabilitado, 1 = Habilitado

Si el valor no existe, se asume normalmente como habilitado (especialmente en versiones antiguas). Tras cualquier cambio en estas claves es recomendable reiniciar el sistema para que LanmanServer aplique la nueva configuración.

Deshabilitar SMBv1 de forma centralizada con Directiva de grupo

En entornos de dominio es habitual querer desplegar la desactivación de SMBv1 en masa, sin tener que ir equipo por equipo. Para ello, la Directiva de grupo (GPO) es la herramienta idónea.

La idea básica es modificar las claves de servicios mrxsmb10 y LanmanWorkstation en todos los equipos objetivo, de forma que el controlador SMBv1 no arranque y su dependencia desaparezca de la Workstation.

Pasos generales en la Consola de administración de directivas de grupo:

1. Editar el GPO que quieres usar y navegar a Configuración del equipo > Preferencias > Configuración de Windows > Registro.
2. Crear un nuevo «Elemento del Registro» para deshabilitar el controlador mrxsmb10:
   Clave: SYSTEM\CurrentControlSet\Services\mrxsmb10
   Nombre del valor: Start
   Tipo: REG_DWORD
   Datos: 4 (Deshabilitado)
3. Crear otro elemento para reemplazar DependOnService de LanmanWorkstation:
   Clave: SYSTEM\CurrentControlSet\Services\LanmanWorkstation
   Nombre del valor: DependOnService
   Tipo: REG_MULTI_SZ
   Datos: Bowser, MRxSmb20, NSI (eliminando MRxSMB10 de la lista)
4. Forzar la aplicación de la GPO con gpupdate /force o esperar a la siguiente actualización de directivas y, finalmente, reiniciar los equipos destino.

Con esto, el servicio cliente SMBv1 quedará completamente deshabilitado en el dominio, reduciendo de golpe el riesgo de ataques basados en esta versión del protocolo.

Activar o desactivar SMBv1 desde el Panel de control de Windows 10

Si no te apetece liarte con PowerShell, en Windows 10 puedes gestionar SMBv1 desde «Programas y características», en las características opcionales de Windows.

El flujo es sencillo:

• Abrir Panel de control > Programas y características.
• Pulsar en «Activar o desactivar las características de Windows».
• Localizar la entrada «Compatibilidad con el protocolo para compartir archivos SMB 1.0/CIFS».
• Marcarla para habilitar SMBv1 (cliente, servidor y eliminación automática) o desmarcarla para deshabilitarla por completo.
• Aceptar los cambios y reiniciar el equipo cuando lo solicite.

En instalaciones actuales de Windows 10, SMBv1 ya no se instala automáticamente. Si actualizaste desde una versión antigua donde sí estaba habilitado, es posible que siga activo y convenga desactivarlo manualmente.

SMB, Samba, CIFS y alternativas como NFS

En muchas guías se mezclan conceptos como SMB, CIFS y Samba, así que conviene aclararlos. CIFS es, estrictamente, el nombre que Microsoft dio a su implementación de SMB 1.0. Por tanto, CIFS es un dialecto concreto dentro de SMB, no un protocolo distinto.

Samba, por su parte, es la implementación libre de SMB/CIFS en sistemas GNU/Linux y Unix. Permite que un servidor Linux actúe como un servidor de archivos y autenticación compatible con clientes Windows, e incluso como controlador de dominio. En su fichero de configuración /etc/samba/smb.conf puedes definir, entre otras cosas, las versiones mínima y máxima del protocolo que se usarán tanto para el servidor como para el cliente.

Un ejemplo típico para forzar solo SMBv2 y SMBv3 en Samba sería algo como:


min protocol = SMB2
client min protocol = SMB2
max protocol = SMB3
client max protocol = SMB3

En cuanto a alternativas, NFS (Network File System) es el protocolo equivalente en el mundo Unix. Sirve también para acceder a sistemas de archivos remotos como si fueran locales, pero no es compatible a nivel de protocolo con SMB/CIFS. En entornos mixtos Windows/Linux lo habitual es usar Samba para hablar SMB con los clientes Windows, y NFS para clientes Linux puros.

Cuándo es inevitable usar SMBv1 y cómo mitigar riesgos

En un mundo ideal, se deshabilitaría SMBv1 en todas partes y se migrarían los dispositivos heredados. En la práctica, muchas empresas se topan con impresoras de leasing antiguas, NAS sin soporte, scanners o aplicaciones legacy que solo funcionan con SMBv1.

En esos casos, si no queda otra que reactivarlo, conviene aplicar una serie de medidas de contención y endurecimiento:

• Limitar SMBv1 solo a los equipos que realmente lo necesitan y nunca habilitarlo de forma global.
• Segmentar la red para que los dispositivos que requieren SMBv1 queden aislados del resto, con cortafuegos internos y reglas estrictas.
• Asegurarse de que todos los parches de seguridad relacionados con SMB están aplicados en servidores y clientes.
• Bloquear o filtrar el puerto 445 hacia/desde Internet en firewalls perimetrales para evitar exposiciones innecesarias.
• Reforzar el puesto que expone SMBv1 con soluciones antiransomware, backup frecuente y monitorización de actividad sospechosa.

El objetivo es que, aunque tengas que usar SMBv1 en un rincón de la red, un posible incidente quede acotado y no paralice toda la organización.

Conocer la evolución de SMB, las diferencias entre sus versiones y las herramientas de Windows para auditar, habilitar o deshabilitar SMBv1, v2 y v3 permite tomar decisiones conscientes: mantener la compatibilidad cuando no hay más remedio, pero priorizar siempre la seguridad, minimizar la superficie expuesta y apoyarse en protocolos modernos y cifrados allá donde sea posible.