Exigir la firma SMB y deshabilitar SMBv1 en el dominio
Exija la firma SMB en clientes y servidores, conozca los valores predeterminados de Windows 11 24H2 y Server 2025, y audite y elimine SMBv1 sin cortar el acceso.
El relay SMB es el NTLM relay clásico: un atacante captura un intento de autenticación, a menudo mediante envenenamiento LLMNR o coerción de autenticación, y lo reproduce contra un servidor que acepta SMB sin firmar. Si la identidad reenviada es administrador local en el destino, el atacante obtiene ejecución remota de código. Exigir la firma SMB hace que la sesión reenviada falle, porque el atacante no dispone de la clave de sesión necesaria para firmar. SMBv1, por su parte, es el protocolo detrás de EternalBlue y WannaCry y no tiene cabida en una red moderna.
El pilar de NTLM y protocolos heredados indica las dos configuraciones de firma. Esta guía cubre el despliegue completo: las cuatro configuraciones de directiva y lo que hace realmente cada una, qué cambian de forma predeterminada Windows 11 24H2 y Windows Server 2025, cómo encontrar los dispositivos que se romperán y cómo auditar y eliminar SMBv1.
Las cuatro configuraciones y cuáles cuentan
Las cuatro se encuentran en:
Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options| Directiva | Registro (DWORD) | Efecto |
|---|---|---|
| Microsoft network server: Digitally sign communications (always) | LanmanServer\Parameters\RequireSecuritySignature = 1 | El servidor rechaza las sesiones sin firmar |
| Microsoft network server: Digitally sign communications (if client agrees) | LanmanServer\Parameters\EnableSecuritySignature = 1 | Solo SMB1: firma cuando el cliente lo pide |
| Microsoft network client: Digitally sign communications (always) | LanmanWorkstation\Parameters\RequireSecuritySignature = 1 | El cliente rechaza las sesiones sin firmar |
| Microsoft network client: Digitally sign communications (if server agrees) | LanmanWorkstation\Parameters\EnableSecuritySignature = 1 | Solo SMB1: firma cuando el servidor lo pide |
Las rutas del registro están bajo HKLM\SYSTEM\CurrentControlSet\Services\. Con SMB 2 y 3, solo las configuraciones «always» cambian el comportamiento: la firma se usa siempre que cualquiera de las dos partes la exija. Eso también significa que exigir la firma en el servidor protege a ese servidor frente al relay independientemente de la configuración del cliente, mientras que exigirla en el cliente protege al cliente frente a servidores fraudulentos o degradados.
Valores predeterminados por versión
- Los controladores de dominio exigen desde hace mucho la firma en el lado servidor mediante la Default Domain Controllers Policy. Compruebe que nadie la haya debilitado.
- Windows 11 24H2 exige la firma SMB de forma predeterminada tanto en las conexiones salientes como en las entrantes.
- Windows Server 2025 exige la firma de forma predeterminada en las conexiones salientes (cliente). La firma entrante solo se exige de forma predeterminada en los controladores de dominio, por lo que los servidores de archivos miembros siguen necesitando la directiva.
- Las versiones anteriores (Windows 10, Windows 11 antes de 24H2, Windows Server 2022 y anteriores) solo la exigen donde la directiva lo indica.
Los equipos actualizados siguen la directiva si hay una configurada. Si su GPO establece explícitamente «always» en Disabled, algo que hacían algunas bases de referencia antiguas para «arreglar» el rendimiento, prevalece sobre el nuevo valor predeterminado. Búsquelo antes de dar por hecho que 24H2 ha arreglado algo.
Firma, cifrado y rendimiento
La firma añade un código de autenticación de mensajes a cada paquete SMB, con una clave derivada de la clave de sesión establecida durante la autenticación. Un atacante que hace relay nunca conoce esa clave, y por eso una sesión reenviada muere en cuanto se exige la firma. El algoritmo depende del dialecto negociado:
| Dialecto | Algoritmo de firma |
|---|---|
| SMB 2.0.2 / 2.1 | HMAC-SHA256 |
| SMB 3.0 / 3.0.2 / 3.1.1 | AES-CMAC |
| SMB 3.1.1 en Windows 11 y Windows Server 2022 o posterior | AES-GMAC cuando ambas partes lo admiten |
AES-GMAC y AES-CMAC se benefician de la aceleración por hardware AES-NI, por lo que la sobrecarga en servidores modernos es muy inferior a lo que decían las advertencias de «la firma reduce el rendimiento a la mitad» escritas en la época de SMB 1 y 2. El coste restante es CPU en el servidor de archivos, más visible en equipos que sirven grandes transferencias secuenciales a muchos clientes a la vez, como puntos de distribución de software, servidores de perfiles y destinos de copia de seguridad.
El cifrado SMB (Set-SmbShare -EncryptData $true o Set-SmbServerConfiguration -EncryptData $true) también proporciona integridad, por lo que una sesión cifrada no necesita firma aparte. Además protege los datos en tránsito, pero requiere SMB 3.x en ambos extremos, lo que excluye a los clientes antiguos y a muchos dispositivos. La base práctica es: firma exigida en todas partes y cifrado añadido para los recursos compartidos que contienen datos sensibles o a los que se accede a través de enlaces no fiables.
La firma no resuelve el problema de fondo, que es que la autenticación NTLM pueda capturarse. Elimina SMB como destino de relay, que es la parte que convierte una autenticación capturada en ejecución de código.
Medir: encontrar lo que no puede firmar
En los clientes Windows, Get-SmbConnection muestra si cada sesión activa está firmada. Ejecútelo en una muestra de estaciones de trabajo y servidores para ver a qué servidores de archivos, NAS y dispositivos se accede hoy sin firma.
# En un cliente: sesiones SMB actuales y su protección
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted, UserName
# En varios equipos
$targets = Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
Select-Object -First 50 -ExpandProperty DNSHostName
Invoke-Command -ComputerName $targets -ScriptBlock {
Get-SmbConnection | Where-Object { -not $_.Signed -and -not $_.Encrypted } |
Select-Object @{n='Client';e={$env:COMPUTERNAME}}, ServerName, ShareName, Dialect
} -ErrorAction SilentlyContinue | Sort-Object ServerName -UniquePara el lado servidor, inventaríe la configuración actual en todos los servidores Windows:
$servers = (Get-ADComputer -Filter 'OperatingSystem -like "*Server*"').DNSHostName
Invoke-Command -ComputerName $servers -ScriptBlock {
$s = Get-SmbServerConfiguration
$c = Get-SmbClientConfiguration
[PSCustomObject]@{
Host = $env:COMPUTERNAME
ServerRequire = $s.RequireSecuritySignature
ClientRequire = $c.RequireSecuritySignature
SMB1 = $s.EnableSMB1Protocol
}
} -ErrorAction SilentlyContinue | Export-Csv .\smb-posture.csv -NoTypeInformationLos destinos no Windows necesitan una comprobación aparte. Los servidores Samba se configuran con server signing = mandatory en smb.conf; muchos fabricantes de NAS lo exponen como «SMB signing» o «strict signing» en su consola de administración. Compruebe también las impresoras y escáneres que hacen «escanear a carpeta»: son clientes SMB y algunos firmwares antiguos no pueden firmar.
Auditar y eliminar SMBv1
SMBv1 no se instala de forma predeterminada desde Windows 10 1709 y Windows Server 2019, pero los sistemas actualizados y los servidores antiguos a menudo lo siguen teniendo. Antes de eliminarlo de los servidores de archivos, audite quién lo usa:
# En cada servidor de archivos: registrar los intentos de acceso SMB1
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
# Al cabo de unas semanas, ver quién se conectó con SMB1
Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -FilterXPath '*[System[EventID=3000]]' -MaxEvents 500 |
Select-Object TimeCreated, MessageEl evento 3000 registra la dirección del cliente de cada conexión SMB1. Los orígenes típicos son fotocopiadoras antiguas, dispositivos Linux embebidos con Samba obsoleto, equipos médicos o industriales heredados y sistemas Windows XP o Server 2003 que ya no deberían existir.
Después, elimínelo:
# Servidores y clientes: deshabilitar el componente de servidor SMB1
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Eliminar la característica por completo (requiere reinicio)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestartEn Windows Server también puede usar Uninstall-WindowsFeature FS-SMB1. Para un control a escala de todo el parque, el ADMX MS Security Guide de las bases de referencia de seguridad de Microsoft añade las configuraciones "Configure SMB v1 server" y "Configure SMB v1 client driver"; consulte implementar las bases de referencia de seguridad de Microsoft.
Aplicar: orden de despliegue
- Controladores de dominio. Confirme que «always» está en Enabled tanto en servidor como en cliente. Los controladores de dominio son el objetivo de relay más valioso y en la mayoría de los dominios ya firman.
- Servidores de Tier 0 y de administración: AD CS, copia de seguridad, SCCM/MECM, administración de hipervisores. Hacer relay hacia ellos da privilegios de administrador sobre sistemas críticos; consulte identificar los activos de Tier 0.
- Todos los servidores miembros, primero el lado servidor. Esto elimina el relay SMB como técnica de movimiento lateral contra ellos.
- Estaciones de trabajo, lado servidor (las estaciones comparten
ADMIN$yC$, y el relay hacia ellas es habitual) y lado cliente. - Lado cliente en los servidores, cuando sepa que todos los destinos SMB que usan pueden firmar.
Use una GPO por anillo, vinculada a las OU correspondientes, para poder revertir un anillo sin tocar los demás. Los cambios surten efecto en las nuevas sesiones SMB; las existentes continúan hasta que se desconectan, así que un reinicio o un cierre de sesión hace que las pruebas sean deterministas.
Verificar
Invoke-Command -ComputerName $servers -ScriptBlock {
[PSCustomObject]@{
Host = $env:COMPUTERNAME
ServerRequire = (Get-SmbServerConfiguration).RequireSecuritySignature
ClientRequire = (Get-SmbClientConfiguration).RequireSecuritySignature
SMB1Feature = (Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -ErrorAction SilentlyContinue).State
}
} | Where-Object { -not $_.ServerRequire -or -not $_.ClientRequire } | Format-TableLa salida debe estar vacía. Vuelva a ejecutar la muestra de Get-SmbConnection: ninguna sesión debe estar sin firmar y sin cifrar. Muchos escáneres internos, y las comprobaciones de relay de herramientas como PingCastle y NetExec que usa su red team, enumeran los equipos que no exigen la firma; la lista debe reducirse a cero o a un conjunto de excepciones documentado.
Qué se rompe
- Los NAS y servidores Samba que no admiten o no exigen la firma solo siguen funcionando si el lado cliente de Windows no la exige. Cuando exige la firma en el cliente, esos recursos compartidos fallan con «el nombre de red especificado ya no está disponible» o errores similares hasta que se habilita la firma en el dispositivo.
- El acceso SMB de invitado y anónimo no funciona con la firma, porque una sesión de invitado no tiene clave con la que firmar. Windows 11 24H2 ya bloquea el recurso a invitado; los NAS económicos y algunas configuraciones de «escanear a carpeta» dependían de él.
- Las impresoras multifunción que escanean a recursos compartidos SMB con firmware antiguo pueden no conectarse cuando el servidor exige la firma. Actualice el firmware o mueva los destinos de escaneo a un recurso compartido dedicado en un servidor con un plan de excepción.
- Los dispositivos que solo admiten SMBv1 dejan de funcionar por completo cuando se elimina SMBv1: fotocopiadoras antiguas, controladores embebidos, sistemas médicos e industriales heredados. Aísle los que no puedan sustituirse en un segmento de red separado con un depósito de archivos dedicado y fuera del dominio.
- Los servidores de archivos de alto rendimiento sobre hardware antiguo pueden mostrar tasas de transferencia menores con la firma exigida. Mida antes y después; considere el cifrado SMB en 3.1.1 como alternativa para recursos compartidos concretos.
Lecturas relacionadas: el tema NTLM y protocolos heredados, la entrada del glosario firma SMB, deshabilitar LLMNR, NBT-NS y WPAD para eliminar el origen más común de autenticaciones aprovechables para relay, y restringir NTLM para la solución a más largo plazo de eliminar el propio NTLM.
Preguntas frecuentes
¿Necesito tanto la configuración «always» como «if client agrees» / «if server agrees»?
Las que importan son las configuraciones «always»: hacen que la firma sea obligatoria. Las configuraciones «if client agrees» e «if server agrees» solo habilitan la firma cuando ambas partes están dispuestas, y SMB2 y posteriores las ignoran, porque en ellos la capacidad de firma siempre está presente. Establezca «always» en Enabled tanto en el lado cliente como en el servidor, y deje habilitadas las configuraciones «if agrees» para los casos límite de SMB1.
¿El cifrado SMB sustituye a la firma?
Cuando una sesión o un recurso compartido se cifra con SMB 3.x, el cifrado también proporciona integridad, por lo que no se aplica la firma encima. El cifrado solo está disponible con SMB 3.0 y posteriores, y normalmente se habilita por recurso compartido o por servidor. La firma sigue siendo la base para todo el dominio porque protege todas las sesiones SMB 2 y 3, incluidas las dirigidas a recursos compartidos que no están cifrados.
¿Cuánto rendimiento cuesta la firma SMB?
En hardware moderno con SMB 3.x suele ser poco, porque la firma usa AES-CMAC o, en Windows 11 y Windows Server 2022 y posteriores, AES-GMAC con aceleración por CPU. El coste se nota en servidores de archivos de muy alto rendimiento, en CPU antiguas y en sesiones SMB 2.x que recurren a HMAC-SHA256. Mida en su servidor de archivos más cargado antes y después, en lugar de suponer nada.
Exigir la firma SMB y deshabilitar SMBv1 en el dominio