SMB1 vs SMB2/3: Qué deshabilitar (y por qué debería importarte)

Conclusión: qué deshabilitar

Deshabilita SMB1 en todas partes. En servidores y en clientes. Luego verifica que realmente haya desaparecido.
Hazlo por seguridad, sí, pero también por fiabilidad. El diseño ruidoso de SMB1, su negociación frágil y la falta de salvaguardas modernas convierten pequeñas
rarezas de red en fallos visibles para los usuarios.

Haz esto

• Deshabilita el servidor SMB1 en servidores Windows y en appliances Samba.
• Deshabilita el cliente SMB1 en equipos de escritorio/VDI Windows a menos que tengas una excepción documentada y con fecha límite.
• Permite SMB2 y SMB3 (incluido SMB 3.1.1) y aplica seguridad sensata: firma donde sea necesaria, cifrado solo donde esté justificado.
• Rastrea los últimos equipos con SMB1 (escáneres, copiadoras antiguas, dispositivos embebidos) y planifica su retiro como cualquier otro riesgo.

Una opinión directa desde operaciones

La única razón válida para mantener SMB1 activado es “hemos aceptado el riesgo, lo hemos aislado, lo hemos registrado y tenemos una fecha de eliminación”.
Cualquier otra cosa es solo procrastinación con un cable de red conectado.

Broma #1: SMB1 es como mantener una mosquitera en un submarino porque a tu tío abuelo le gustaba “el aire fresco”.

Algunos hechos e historia que importan

No necesitas memorizar la arqueología del protocolo, pero un puñado de hechos concretos cambiará cómo diagnosticas y cómo vendes el cambio internamente.

1. SMB1 precede los modelos de amenaza modernos. Sus raíces se remontan a la red para PC de IBM y a los primeros diseños de la era LAN Manager de Microsoft.
2. SMB2 llegó con Windows Vista/Server 2008. No fue una “actualización menor”; fue un rediseño orientado a reducir la verbosidad y mejorar el rendimiento.
3. SMB3 se lanzó con Windows 8/Server 2012. Trajo características pensadas para centros de datos: cifrado, multicanal y SMB Direct (RDMA).
4. La propagación de WannaCry se aceleró por la exposición de SMB1. Ese incidente movió permanentemente “deshabilitar SMB1” de buenas prácticas a higiene mínima.
5. SMB 3.1.1 mejoró la negociación de seguridad. Introdujo protecciones de integridad pre-autenticación que dificultan trucos de degradación/mitm.
6. La firma SMB existía antes pero ganó relevancia. A menudo se exige por seguridad y puede convertirse en una limitación de rendimiento en CPUs débiles.
7. SMB es con estado y sensible a la latencia. Un poco de RTT está bien; la variabilidad y la pérdida de paquetes son lo que lo hacen gritar.
8. Los “dialectos” SMB se negocian por conexión. Puedes deshabilitar SMB1 y aún ver clientes fallar si no pueden negociar SMB2+.
9. Samba no es “SMB de Windows”, pero habla el mismo idioma. Samba puede implementar características SMB3 según la versión/opciones de compilación y el soporte del kernel.

SMB1 vs SMB2 vs SMB3: qué cambió realmente

SMB1: ruidoso, frágil y demasiado confiado

SMB1 es el mundo antiguo. Tiende a realizar muchas operaciones de solicitud/respuesta pequeñas. Eso significa más viajes de ida y vuelta, lo que amplifica la latencia.
También significa más puntos donde los middleboxes pueden interferir y más oportunidades para que aparezcan errores oscuros.

SMB1 además carece de defensas modernas. Incluso cuando lo enmarcas como “la red es interna”, apuestas a que nada no fiable podrá alcanzarlo.
Esa apuesta se pierde en el momento en que un portátil trae malware a la VPN, un firewall mal configurado abre un camino o una VLAN plana permite que un puesto de trabajo
hable con todo.

SMB2: menos viajes, mejores semánticas

SMB2 redujo sustancialmente la sobrecarga del protocolo. Mejoró el batching y el pipelining. Eso no es “agradable de tener”; es por qué SMB2 rinde mucho mejor
en enlaces tipo WAN, núcleos ocupados y redes virtualizadas.

Operativamente, SMB2+ también mejora la historia de observabilidad. A menudo puedes consultar dialectos negociados, estado de firma y detalles de sesión con más claridad,
lo que convierte “está lento” en algo medible.

SMB3: seguridad y funciones para centro de datos (con puntas afiladas)

SMB3 añade cosas que realmente quieres en entornos modernos: cifrado (por recurso o por sesión), multicanal (múltiples rutas de red por sesión)
y SMB Direct (RDMA) si estás en el mundo Windows/HCI.

Pero las funciones de SMB3 también pueden crear nuevos modos de fallo:
multicanal puede exponer enrutamiento asimétrico, offloads malos en NICs o mala configuración de switches;
el cifrado puede convertirse en un cuello de botella de CPU;
los requisitos de firma pueden convertir un NAS débil en un radiador que además sirve archivos.

La cita

“idea parafraseada” — Werner Vogels: construyes fiabilidad asumiendo que las cosas fallarán y diseñando para ello, no esperando que el camino feliz se mantenga.

Qué deshabilitar (y qué mantener)

Deshabilitar el soporte del protocolo SMB1

SMB1 debe estar deshabilitado en servidores y clientes. Punto. Aquí es donde algunos entornos dicen “pero la copiadora…”.
Perfecto. Pon la copiadora en una VLAN cuarentenada, dale un recurso dedicado con ACL estrictas y programa su reemplazo.
No mantengas SMB1 activado en toda la flota porque un dispositivo embebido quedó atrapado en 2009.

Mantén SMB2 y SMB3, pero sé deliberado con firma y cifrado

La firma SMB ayuda a prevenir la manipulación y algunos juegos de relevo de credenciales. Pero la firma consume CPU.
En servidores modernos suele estar bien; en appliances NAS antiguos o VMs sobrecargadas, puede marcar la diferencia entre “rápido” y “¿por qué todo va a 12 MB/s?”

El cifrado SMB es fantástico cuando lo necesitas (redes no confiables, segmentos multi-inquilino, recursos sensibles).
También es una forma sencilla de hacer que un clúster de almacenamiento parezca lento mientras las CPUs se maximizan en criptografía.
Úsalo donde reduzca riesgo real; no lo actives en bloque y luego te sorprendas cuando cambie el rendimiento.

Deshabilita autenticación heredada cuando puedas

SMB1 a menudo arrastra comportamientos de autenticación antiguos a la conversación. Si todavía permites NTLMv1 o LM en 2026, no eres “compatible”;
estás invitando al abuso de credenciales. Muévete hacia Kerberos y políticas NTLM modernas, y mantén el acceso de invitado desactivado a menos que disfrutes de la respuesta a incidentes.

Broma #2: “Excepción temporal a SMB1” es el equivalente en TI de “solo tomaré una galleta”.

Tareas prácticas: comandos, salidas, decisiones

Estas son tareas reales que puedes ejecutar en producción con mínimo drama. Cada una incluye qué significa la salida y la decisión que tomas a partir de ella.
Mezcla según si administras servidores Windows, Samba o un NAS.

Tarea 1: Comprobar dialecto SMB y características negociadas (cliente Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,NumOpens,SigningRequired,Encrypted | Format-Table -Auto"
ServerName ShareName Dialect NumOpens SigningRequired Encrypted
---------- --------- ------ -------- ---------------- ---------
NAS01      data      3.1.1  24       True             False
FS01       profiles  3.0    6        True             True

Significado: El dialecto muestra lo que se negoció realmente. Si ves 1.5 o “1.0” (SMB1), tienes una brecha de política.
Decisión: Si aparece SMB1, identifica el par cliente/servidor y deshabilita SMB1 donde corresponda. Si el cifrado está activado inesperadamente, espera impacto en CPU.

Tarea 2: Confirmar que el servidor SMB1 está deshabilitado (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol | Format-List"
EnableSMB1Protocol : False
EnableSMB2Protocol : True

Significado: Esta es la configuración efectiva del servidor SMB.
Decisión: Si EnableSMB1Protocol es True, desactívalo en una ventana de cambio y monitorea quejas de dispositivos legacy (luego repara los dispositivos).

Tarea 3: Deshabilitar el servidor SMB1 (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force"

Significado: El soporte de servidor SMB1 queda apagado.
Decisión: Programa un reinicio solo si lo requiere tu build/política del SO; valida que nuevas conexiones negocien SMB2/3; vigila los registros de eventos por negociaciones fallidas.

Tarea 4: Comprobar si la característica cliente SMB1 está instalada (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol | Select-Object FeatureName,State"
FeatureName  State
-----------  -----
SMB1Protocol Enabled

Significado: Los componentes cliente SMB1 están presentes.
Decisión: Deshabilita/elimina SMB1 en los clientes salvo que haya una excepción aislada. Esto reduce la caída accidental y la superficie de ataque.

Tarea 5: Quitar la característica cliente SMB1 (Windows)

cr0x@server:~$ powershell -NoProfile -Command "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart"
Path          :
Online        : True
RestartNeeded : True

Significado: Eliminación de la característica encolada; se requiere reinicio.
Decisión: Coordina con la gestión de endpoints el reinicio. Tras el reinicio, valida acceso a recursos compartidos y asegura que no aparezca dialecto SMB1.

Tarea 6: Identificar sesiones de servidor SMB y dialectos (Windows Server)

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbSession | Select-Object ClientComputerName,ClientUserName,Dialect,NumOpens | Sort-Object Dialect | Format-Table -Auto"
ClientComputerName ClientUserName     Dialect NumOpens
------------------ --------------     ------ --------
WS043              CORP\j.singh       3.1.1  18
WS019              CORP\finance.svc   3.0    4

Significado: Ves qué clientes están usando qué dialectos.
Decisión: Si alguna sesión muestra SMB1, puedes localizar el cliente de inmediato. Si el dialecto es SMB2/3 pero el rendimiento es pobre, pasa a comprobaciones de latencia/credits/cifrado.

Tarea 7: Samba: comprobar el suelo/techo efectivo de protocolo SMB

cr0x@server:~$ testparm -s 2>/dev/null | egrep -i "server min protocol|server max protocol|client min protocol|client max protocol"
server min protocol = SMB2_02
server max protocol = SMB3_11
client min protocol = SMB2_02
client max protocol = SMB3_11

Significado: Samba no negociará por debajo de SMB2_02 y puede negociar hasta SMB3_11.
Decisión: Si ves NT1 (SMB1) en alguna parte, sube el mínimo. Si el máximo es demasiado bajo, actualiza Samba o ajusta la config para permitir SMB3.

Tarea 8: Samba: ver activamente clientes conectados y dialecto negociado

cr0x@server:~$ smbstatus -S
Service      pid     Machine       Connected at                     Encryption   Signing
------------------------------------------------------------------------------------------
data         1842    10.40.12.77    Tue Feb  5 09:21:44 2026 UTC    -            SMB2
profiles     1920    10.40.10.31    Tue Feb  5 09:24:11 2026 UTC    AES-128-GCM  SMB3_11

Significado: Samba reporta por sesión el estado de firma/cifrado (varía por versión).
Decisión: Si el cifrado aparece inesperadamente en un recurso pesado, mide la CPU. Si la firma muestra SMB2 cuando esperabas SMB3_11, puedes tener problemas de capacidad del cliente o de políticas.

Tarea 9: Samba: establecer protocolo mínimo a SMB2 (deshabilitar SMB1) y recargar

cr0x@server:~$ sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
cr0x@server:~$ sudo bash -lc 'printf "\n[global]\n   server min protocol = SMB2_02\n   server max protocol = SMB3_11\n" >> /etc/samba/smb.conf'
cr0x@server:~$ sudo systemctl reload smbd

Significado: Samba rechazará negociaciones SMB1 tras la recarga.
Decisión: Monitorea logs por clientes rechazados; si algo falla, te está indicando qué dispositivo necesita reemplazo o aislamiento.

Tarea 10: Comprobar logs de Samba por fallos de negociación de dialecto

cr0x@server:~$ sudo journalctl -u smbd --since "1 hour ago" | egrep -i "protocol|SMB1|NT1|negotiate|reject" | tail -n 20
Feb 05 09:44:10 nas01 smbd[2112]: negotiate_protocol: No compatible protocol. Client offered: NT1
Feb 05 09:44:10 nas01 smbd[2112]: Failed to negotiate protocol with client 10.40.50.19

Significado: Un cliente está intentando SMB1 (NT1) y está siendo rechazado.
Decisión: Identifica el dispositivo en esa IP y decide: actualizar firmware, reemplazar el dispositivo o aislarlo detrás de un gateway legado con controles estrictos.

Tarea 11: Comprobar si el cifrado SMB está activado en un recurso Windows

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare -Name data | Select-Object Name,EncryptData,CachingMode | Format-List"
Name        : data
EncryptData : False
CachingMode : Manual

Significado: El cifrado a nivel de recurso está apagado.
Decisión: Si el recurso cruza una frontera de red no confiable, considera habilitar cifrado. Si el rendimiento ya es ajustado, realiza un benchmark antes/después.

Tarea 12: Habilitar cifrado SMB en un recurso Windows específico (quirúrgico, no global)

cr0x@server:~$ powershell -NoProfile -Command "Set-SmbShare -Name data -EncryptData $true"

Significado: Los clientes deben usar cifrado SMB3 para acceder a ese recurso.
Decisión: Despliega esto por recurso, no globalmente. Valida el soporte del SO cliente y vigila CPU y rendimiento del servidor tras habilitarlo.

Tarea 13: Verificar requisitos de firma SMB en Windows Server

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EnableSecuritySignature | Format-List"
RequireSecuritySignature : True
EnableSecuritySignature  : True

Significado: La firma está activada y requerida.
Decisión: Si el rendimiento es pobre, comprueba CPU y red primero. Si el servidor está infraaprovisionado, puede que necesites mejor hardware o estrategias de offload—no desactivar la firma a la ligera.

Tarea 14: Cliente Linux: mostrar dialecto SMB negociado para un recurso montado

cr0x@server:~$ mount | grep -i cifs
//nas01/data on /mnt/data type cifs (rw,relatime,vers=3.1.1,sec=krb5,cache=strict,username=CORP\\j.singh,uid=1000,gid=1000)

Significado: El cliente Linux está usando SMB 3.1.1. Bien.
Decisión: Si ves vers=1.0 o vers=2.0 inesperadamente, ajusta las opciones de montaje y asegúrate de que el servidor soporte dialectos más nuevos.

Tarea 15: Cliente Linux: forzar SMB3 y fallar rápido si el servidor no lo soporta

cr0x@server:~$ sudo mount -t cifs //nas01/data /mnt/data -o vers=3.1.1,sec=krb5,seal,username=CORP\\j.singh
mount error(95): Operation not supported

Significado: El servidor o la pila cliente no soportan el conjunto de características solicitado (aquí: SMB3.1.1 + cifrado).
Decisión: Decide si actualizar Samba/kernel, ajustar a un dialecto soportado o mover la carga. No lo “arregles” activando SMB1.

Tarea 16: Comprobación de realidad de red desde el cliente (pistas de latencia y pérdida)

cr0x@server:~$ ping -c 5 nas01
PING nas01 (10.40.10.20) 56(84) bytes of data.
64 bytes from 10.40.10.20: icmp_seq=1 ttl=63 time=1.12 ms
64 bytes from 10.40.10.20: icmp_seq=2 ttl=63 time=12.9 ms
64 bytes from 10.40.10.20: icmp_seq=3 ttl=63 time=1.05 ms
64 bytes from 10.40.10.20: icmp_seq=4 ttl=63 time=1.09 ms
64 bytes from 10.40.10.20: icmp_seq=5 ttl=63 time=1.08 ms

--- nas01 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 1.05/3.45/12.9/4.73 ms

Significado: No hay pérdida de paquetes, pero la variabilidad de latencia (jitter) alcanza 12.9 ms.
Decisión: SMB odia el jitter. Investiga congestión, offloads de NIC problemáticos, Wi‑Fi malo o switches virtuales sobrecargados antes de culpar “al NAS”.

Tarea 17: Prueba rápida de rendimiento (sospecha: red vs almacenamiento)

cr0x@server:~$ dd if=/dev/zero of=/mnt/data/smb-test.bin bs=16M count=64 conv=fdatasync status=progress
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s
17179869184 bytes (17 GB, 16 GiB) copied, 292 s, 58.8 MB/s
64+0 records in
64+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 18.4 s, 58.4 MB/s

Significado: Las escrituras rondan ~58 MB/s. En una red 1 GbE sana podrías esperar ~90–110 MB/s para escrituras secuenciales, según sobrecarga y cifrado/firma.
Decisión: Si esto está muy por debajo de lo esperado para el enlace, comprueba CPU del cliente (cifrado/firma), negociación de la NIC y latencia de disco en el servidor. Si está cerca de lo esperado, examina patrones de I/O pequeños a nivel de aplicación.

Tarea 18: Windows: comprobar velocidad/duplex de la NIC (sí, todavía duele)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,Status,LinkSpeed | Format-Table -Auto"
Name        Status LinkSpeed
----        ------ ---------
Ethernet0   Up     1 Gbps
Ethernet1   Up     100 Mbps

Significado: Una NIC está a 100 Mbps. Eso no es “un poco más lento”, es otra década.
Decisión: Arregla cableado/puerto de switch/auto-negociación. Si SMB multicanal está activado, la NIC lenta puede arrastrar el rendimiento o causar comportamientos extraños según la política.

Guía rápida de diagnóstico

Los problemas SMB rara vez son “solo SMB”. Por lo general son una de cuatro cosas: desajuste de negociación/política, calidad de red, CPU del servidor (cripto/firma)
o latencia de almacenamiento. El truco es encontrar cuál en minutos, no horas.

Primero: confirma el dialecto y el modo de seguridad

• En cliente Windows: Get-SmbConnection y observa Dialect, SigningRequired, Encrypted.
• En servidor Windows: Get-SmbSession para dialectos de los clientes.
• En Samba: smbstatus -S (dialecto/firma/cifrado depende de la versión).

Si algo está negociando SMB1, deja de diagnosticar rendimiento. Estás diagnosticando una falla de política. Arregla eso primero.

Segundo: decide si huele a red, CPU o disco

• Olor a red: ping con jitter, pérdida de paquetes, clientes Wi‑Fi, rutas VPN, enrutamiento asimétrico, rarezas de ECMP.
• Olor a CPU: el rendimiento cae solo cuando el cifrado/firma está activo; la CPU del servidor sube con la copia de archivos.
• Olor a disco: SMB va bien para un cliente pero colapsa con muchos; la latencia de almacenamiento se dispara; cargas ricas en metadatos (muchos archivos pequeños) se arrastran.

Tercero: mide una cosa a la vez

1. RTT/jitter cliente-servidor: un ping rápido sirve como pista, luego usa herramientas del SO para chequeos más profundos.
2. Rendimiento de flujo único: una prueba controlada de escritura/lectura para aislar límites gruesos.
3. Comportamiento en concurrencia: SMB2/3 usa créditos; los problemas a menudo aparecen bajo operaciones paralelas.
4. CPU vs latencia de disco: vigila CPU del servidor y latencia de almacenamiento durante la misma ventana de prueba.

Una regla práctica de triaje

Si la copia de un solo archivo grande es rápida pero abrir carpetas con muchos archivos es lento, estás ante comportamiento sensible a metadatos/latencia.
Si la copia de archivos grandes es lenta y la CPU está al máximo, revisa firma/cifrado.
Si el rendimiento es inconsistente y los picos correlacionan con jitter de red, es la red aunque nadie quiera aceptarlo.

Tres microhistorias corporativas desde el terreno

Microhistoria 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía una “zona de legado” para unos pocos dispositivos de manufactura. La suposición era simple: esos dispositivos estaban en su propia VLAN,
así que permitir SMB1 “solo para esa red” era seguro. El equipo de archivos activó SMB1 en un servidor de archivos central porque era más rápido que
construir un gateway dedicado.

Meses después, un proyecto no relacionado conectó temporalmente una estación de trabajo de prueba a la VLAN de manufactura para ejecutar diagnósticos.
La estación estaba unida al dominio, sin parches y con un acceso este-oeste amplio que nadie recordaba. Captó malware mediante una descarga maliciosa.
El malware no necesitó ingenio; solo necesitó alcance.

SMB1 era alcanzable. El servidor de archivos tenía recursos con herencia de ACL permisiva porque “siempre se hizo así”. El ataque se movió lateralmente
y empezó a cifrar carpetas compartidas. Inicialmente el equipo persiguió permisos y trabajos de backup porque no quería creer que una fuga de VLAN importara.

La corrección post-incidente no fue exótica. Deshabilitaron SMB1 en el servidor central, construyeron un pequeño gateway SMB aislado para los dispositivos de manufactura,
y ajustaron el enrutamiento para que las conexiones “temporales” requirieran aprobaciones explícitas. La corrección real fue cultural: las suposiciones sobre
aislamiento pasaron a ser hipótesis que se prueban, no verdades repetidas.

Microhistoria 2: La optimización que salió mal

Otra organización desplegó cifrado SMB de forma amplia porque una auditoría de seguridad señaló “recursos compartidos sin cifrar”. El equipo de almacenamiento cumplió rápido:
habilitar cifrado a nivel de recurso para todo y dar por resuelto el tema. Pasó la auditoría. También cambió silenciosamente la física del sistema.

Dos semanas después, el helpdesk recibió quejas de “unidad de red lenta”. Luego el equipo VDI también reportó: tormentas de inicio de sesión más largas, cargas de perfiles que fallaban,
y las culpas rebotaban entre red, almacenamiento y “Windows siendo Windows”.

La causa real fue mundana: los servidores de archivos eran máquinas virtuales con CPU limitada. El cifrado las empujó a la contención de CPU en horas pico. SMB no falló; se ralentizó.
Eso es peor, porque parece que todo “más o menos funciona” mientras la productividad cae.

La solución no fue “apagar la seguridad”. Aplicaron cifrado a los recursos que cruzaban fronteras menos confiables y a los que contenían datos sensibles,
redimensionaron algunos servidores y repartieron la carga. La lección mayor: los controles de seguridad tienen costes de rendimiento, y el coste se nota donde el negocio lo percibe—inicios de sesión y apertura de archivos—si no planificas capacidad.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Una compañía global tenía una política: antes de deprecar un protocolo, hacen un inventario real de uso por 30 días, luego implementan un bloqueo con registro,
y después eliminan la opción legacy. No es glamoroso. Es lo que la gente se burla hasta que les salva.

Cuando se propusieron eliminar SMB1, no empezaron con un interruptor global. Primero activaron registro en el perímetro y en los servidores de archivos,
capturando qué clientes intentaban negociar SMB1. Aparecieron unos pocos dispositivos: un escáner de almacén, una impresora multifunción antigua
y una caja Linux olvidada montando recursos con vers=1.0.

Arreglaron las opciones de montaje de Linux, actualizaron firmware donde fue posible, y para el escáner del almacén construyeron una ruta de recursos dedicada y aislada.
Luego deshabilitaron SMB1 de forma amplia y observaron los logs. Nada gritó. Sin interrupciones sorpresa. Sin “excepción ejecutiva urgente”.

Dos meses después, una prueba de penetración intentó trucos basados en SMB1 contra segmentos internos. No había nada escuchando. El informe fue corto.
El equipo había hecho el trabajo aburrido, y el trabajo aburrido es lo que la fiabilidad parece en un buen día.

Errores comunes: síntoma → causa raíz → solución

1) “Deshabilitamos SMB1, pero algo todavía lo negocia”

Síntoma: Sigues viendo SMB1/NT1 en logs o sesiones.

Causa raíz: Deshabilitado en el servidor pero todavía activado en otro servidor; o el cliente tiene la característica SMB1 instalada y se conecta a un NAS antiguo que solo habla SMB1.

Solución: Inventaría dialectos negociados con Get-SmbSession/Get-SmbConnection o smbstatus. Deshabilita SMB1 en ambos extremos. Reemplaza o aísla el dispositivo que solo soporta SMB1.

2) “Las copias de archivos están lentas después de habilitar cifrado”

Síntoma: La transferencia baja; la CPU del servidor se dispara; usuarios se quejan en horas pico.

Causa raíz: El cifrado SMB3 exige mucho a la CPU; el tamaño de VM o la CPU del NAS no dan abasto.

Solución: Habilita cifrado solo en recursos sensibles o segmentos no confiables; añade CPU; considera hardware con aceleración AES; prueba antes de desplegar ampliamente.

3) “Operaciones con archivos pequeños son dolorosamente lentas, los archivos grandes están bien”

Síntoma: Abrir carpetas con muchos archivos es lento; las aplicaciones que escanean directorios se arrastran.

Causa raíz: Las operaciones de metadatos son sensibles a la latencia; jitter de red, controladores de dominio sobrecargados (retrasos de autenticación) o latencia de almacenamiento en conjuntos ricos en metadatos.

Solución: Reduce el jitter; verifica la capacidad de respuesta de DNS/DC; comprueba latencia e IOPS del almacenamiento; considera colocar metadatos en medios más rápidos; evita SMB sobre WAN sin aceleración.

4) “Desconexiones aleatorias, solicitudes de autenticación o ‘ruta de red no encontrada’”

Síntoma: Las sesiones se caen intermitentemente; las reconexiones piden credenciales; las unidades asignadas se vuelven rojas.

Causa raíz: Middleboxes extinguiendo sesiones con estado; MTU/fragmentación; offloads de NIC erráticos; Wi‑Fi malo; enrutamiento asimétrico más multicanal.

Solución: Valida MTU extremo a extremo; prueba con offloads ajustados; garantiza conectividad cableada estable para sistemas críticos; revisa diseño multicanal y simetría de enrutamiento.

5) “Requerimos firma y ahora el rendimiento es terrible en un servidor”

Síntoma: Un servidor de archivos va lento, otros están bien; la CPU del servidor está alta durante carga SMB.

Causa raíz: Ese servidor es más viejo, está infra-provisionado o ejecuta cargas adicionales; la sobrecarga de firma lo colapsa.

Solución: Mueve cargas; añade CPU; separa roles. No desactives la firma globalmente porque una caja es débil.

6) “Clientes Linux montan, pero clientes Windows no (o viceversa)”

Síntoma: Comportamiento mixto por SO; errores como “operation not supported” o fallos de autenticación.

Causa raíz: Desajuste de dialecto (vers=), desajuste de modo de seguridad (sec=), o configuración de Samba en conflicto con expectativas de AD/Kerberos.

Solución: Alinea dialectos (SMB3.1.1 cuando sea posible), estandariza autenticación (Kerberos para dominio) y verifica server min protocol y el mapeo de identidad en Samba.

Listas de verificación / plan paso a paso

Paso 1: Encontrar uso de SMB1 sin romper nada (fase de inventario)

1. En servidores de archivos Windows, lista sesiones y dialectos con Get-SmbSession.
2. En clientes Windows (muestra), lista conexiones con Get-SmbConnection.
3. En Samba, revisa logs por ofertas NT1 y usa smbstatus.
4. Construye una lista: dispositivo/IP, propietario, función de negocio, ruta de reemplazo/actualización.

Paso 2: Deshabilitar SMB1 en una secuencia controlada

1. Deshabilita SMB1 lado servidor en servidores de archivos de propósito general primero.
2. Deshabilita SMB1 lado cliente vía gestión de endpoints a continuación.
3. Para los pocos retenedores verdaderos, proporciona una solución contenida: VLAN aislada + gateway de recurso dedicado + ACLs mínimas.

Paso 3: Endurecer SMB2/3 intencionalmente (no por copiar y pegar)

• Firma: requiere donde tu modelo de riesgo lo demande; asegura que los servidores tengan capacidad para ello.
• Cifrado: habilita en recursos sensibles y segmentos no confiables; verifica margen de CPU.
• Autenticación: prefiere Kerberos; reduce NTLM legacy cuando sea posible; elimina acceso de invitado.
• Auditoría: mantén logs por fallos de negociación y anomalías de acceso.

Paso 4: Lista de validación de rendimiento

• Prueba una transferencia secuencial grande y una carga de muchos archivos pequeños.
• Valida que el dialecto negociado permanezca en SMB3.x para clientes modernos.
• Revisa CPU del servidor durante copias pico con firma/cifrado activados.
• Comprueba velocidad y estabilidad de NICs en clientes; evita Wi‑Fi para flujos SMB pesados cuando sea posible.
• Confirma latencia de almacenamiento bajo carga; SMB transmitirá fielmente tus problemas de almacenamiento a los usuarios.

Paso 5: Manejo de excepciones (la parte que todos intentan saltarse)

• Cada excepción SMB1 necesita: propietario, justificación, aislamiento de red, monitoreo y fecha de eliminación.
• Si no puedes aislarlo, no tienes una excepción—tienes una vulnerabilidad.

Preguntas frecuentes

1) ¿SMB1 está alguna vez bien en una red interna?

No, no como valor por defecto. “Interno” no es una frontera de seguridad; es una descripción de enrutamiento. Si debes mantener SMB1 para un dispositivo, aíslalo y ponle fecha límite.

2) Si deshabilito SMB1, ¿los clientes Windows usarán SMB2/3 automáticamente?

Windows moderno negociará SMB2/3 si el servidor lo soporta. Si algo falla, suele ser porque el servidor (o NAS) solo soporta SMB1,
o porque un cliente es antiguo o está mal configurado.

3) ¿Cuál es la diferencia práctica entre SMB2 y SMB3 para la mayoría de las empresas?

SMB3 añade cifrado y funciones de rendimiento avanzadas (multicanal, SMB Direct). Si no necesitas esas, SMB2 sigue siendo una gran mejora sobre SMB1.
En la práctica querrás SMB3 para flotas Windows modernas y postura de seguridad.

4) ¿El cifrado SMB reemplaza la necesidad de firma?

El cifrado protege confidencialidad (e integridad de cargas cifradas), pero la firma sigue siendo parte de cómo SMB previene manipulación en varios modos y políticas.
Trátalos como controles relacionados, no sustitutos estrictos.

5) ¿Por qué a veces SMB es rápido para un usuario y lento para muchos?

La concurrencia expone límites de CPU del servidor (firma/cifrado), límites de IOPS/latencia del almacenamiento y el comportamiento de créditos de SMB.
Las pruebas de un solo usuario pueden engañar. Siempre prueba con carga paralela realista al validar cambios.

6) ¿Debo habilitar SMB multicanal en todas partes?

Solo si tu diseño de red lo soporta limpiamente (múltiples NICs, enrutamiento estable, MTU consistente, sin middleboxes extraños).
Multicanal puede aumentar el rendimiento, pero también amplifica las malas configuraciones hasta volver las sesiones inestables.

7) Tenemos un appliance NAS. ¿Se aplican las mismas reglas?

Sí. Las opciones pueden estar en una GUI, pero los riesgos y modos de falla son los mismos. Asegura que el firmware del NAS soporte SMB3.x, deshabilita SMB1
y valida los dialectos negociados desde los clientes.

8) ¿Y los clientes Linux montando recursos SMB—qué deberíamos estandarizar?

Estandariza en SMB3.1.1 cuando sea posible, usa Kerberos (sec=krb5) en entornos de dominio, y evita retrocesos permisivos.
Haz montajes explícitos en lugar de depender de valores por defecto que varían por distro y kernel.

9) Si deshabilito SMB1, ¿cómo manejo impresoras/escáneres antiguos que solo hacen SMB1?

Ponlos en un segmento de red aislado, dales una carpeta de caída dedicada con permisos estrictos y planifica su reemplazo.
Si el negocio se niega a reemplazarlos, documenta el riesgo y conténlo agresivamente.

10) ¿Cómo le demuestro a la dirección que deshabilitar SMB1 vale la pena?

Muéstrales evidencia: qué dispositivos todavía negocian SMB1, qué permite esa exposición y cómo las excepciones pueden aislarse.
Luego presenta un plan de eliminación con mínima interrupción y propietarios claros.

Conclusión: próximos pasos que no te robarán el fin de semana

SMB1 no es “soporte de legado”. Es una responsabilidad que aparece como incidentes de seguridad y como problemas de fiabilidad raros que nunca arreglarás por completo.
SMB2/3 no son perfectos, pero están diseñados para el mundo en el que operas: redes ocupadas, servidores virtualizados y adversarios que escanean todo.

Pasos prácticos:

1. Inventaria los dialectos SMB negociados en tu entorno (clientes y servidores). Encuentra los hablantes de SMB1.
2. Deshabilita SMB1 lado servidor en servidores de archivos generales. Luego elimina la característica cliente SMB1 en toda la flota.
3. Para los retenedores, aísla y fecha. No hay excepciones sin contención y fecha de eliminación.
4. Valida el rendimiento de SMB2/3 con dos pruebas: copias secuenciales grandes y operaciones de muchos archivos pequeños.
5. Ajusta la seguridad de forma intencional: firma según política, cifrado por recurso donde reduzca riesgo real y planificación de capacidad para el coste de CPU.

El objetivo no es ganar un concurso de pureza de protocolo. El objetivo es tener recursos compartidos de archivos aburridos: lo suficientemente rápidos, lo suficientemente seguros y que no sean la razón por la que te pierdas la cena.