La evidencia de dependencia de SMBv1 debe vincular un intento observado de un cliente con un servidor, un flujo de trabajo y un responsable. Una etiqueta antigua del sistema operativo en Active Directory puede ayudar a priorizar la investigación, pero no permite establecer qué dialecto SMB utiliza hoy un dispositivo. Antes de eliminar SMBv1, elabore un registro que distinga la configuración, los intentos de uso, las conexiones establecidas y las lagunas de observación.
Esta guía describe un proceso de verificación y remediación para entornos AD. Los comandos siguientes son ejemplos documentados que un administrador de Windows autorizado puede ejecutar en los sistemas previstos; no se ejecutaron contra un dominio real para este artículo. Ninguna salida de ejemplo se presenta como un resultado medido.
¿Qué es la evidencia de dependencia de SMBv1?
Una dependencia es una afirmación operativa: un flujo de trabajo empresarial identificado aún necesita SMBv1 para completarse. Esa afirmación exige un respaldo más sólido que un atributo de directorio, un componente instalado en disco o la declaración de que un dispositivo es antiguo. Trate cada uno de esos elementos como una entrada para la investigación y registre qué observación confirmaría o debilitaría la afirmación.
La revisión debe responder a tres preguntas. ¿Qué servidor y cliente están implicados? ¿Qué operación debe completarse correctamente? ¿Qué evidencia vincula la observación del protocolo con esa operación? Si el responsable no puede responderlas, la dependencia sigue sin verificarse. Eso no significa que eliminarla sea inocuo; significa que la decisión necesita un piloto con alcance definido y una recopilación adicional.
Utilice un registro de evidencias con entradas separadas para la configuración, los intentos en el servidor, las instantáneas del cliente y los resultados de los flujos de trabajo. Mantener esas entradas separadas evita un error habitual: utilizar una conexión moderna capturada desde un equipo de escritorio para cerrar un hallazgo sobre otro dispositivo, otra identidad o una tarea nocturna.
| Capa de evidencia | Registro | Límite de la conclusión |
|---|---|---|
| Señal del directorio | Identidad del equipo, atributo OS y motivo del colector | Prioriza la revisión; no establece un dialecto SMB |
| Componente y configuración de Windows | Host, función cliente/servidor, comando, marca temporal y estado devuelto | Describe el ajuste inspeccionado, no el uso empresarial |
| Auditoría del servidor | Servidor, Event 3000, marca temporal y contexto del cliente disponible | Registra un intento SMBv1, no un acceso correcto |
| Conexión del cliente | Cliente, servidor, recurso compartido, contexto de inicio de sesión/credenciales y Dialect | Describe las conexiones visibles en el momento de la recopilación |
| Validación del flujo de trabajo | Responsable, operación, hora de ejecución, resultado y observaciones vinculadas | Respalda una decisión para el flujo de trabajo probado |
Cómo encajan las evidencias
Empiece por el flujo de trabajo en lugar de un cambio para todo el parque. Pida al responsable del servicio que enumere sus destinos y los sistemas que lo invocan, incluidas las tareas periódicas que podrían no ejecutarse durante una prueba interactiva. Registre qué sistemas Windows pueden proporcionar auditoría del servidor u observaciones del cliente y qué dispositivos necesitan otro método de recopilación. Un dispositivo que no puede ejecutar los comandos propuestos permanece en la población sin resolver hasta que su responsable aporte evidencia adecuada.
Elija una ventana de recopilación que incluya el ciclo operativo pertinente. Una prueba diaria en primer plano no ejercita una exportación mensual. Aquí no se prescribe una duración universal: el responsable debe justificar la ventana con el calendario real y las operaciones inusuales o de recuperación que importen. Registre las horas de inicio y fin, los flujos de trabajo excluidos, los hosts ausentes y las interrupciones de la recopilación.
Para cada observación, conserve el host de origen y el contexto antes de extraer una conclusión. Una marca temporal por sí sola no basta si los registros del servidor y del cliente no pueden vincularse al mismo destino y operación. Cuando no se pueda establecer ese vínculo, marque la correlación como no resuelta en vez de tratar la proximidad temporal como prueba.
Detección: verificar la configuración, los intentos y las conexiones
Paso 1: inspeccionar el componente de Windows y el ajuste del servidor
Microsoft documenta estas comprobaciones en su guía de gestión de protocolos SMB. Utilice los comandos adecuados para el sistema Windows revisado y conserve sus salidas como elementos de evidencia separados. Ejecute los comandos de características opcionales en una sesión de PowerShell elevada, como exige la guía de Learn.
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Get-SmbServerConfiguration | Select EnableSMB1Protocol
El primero informa del estado de la característica opcional; el segundo, del ajuste del servidor SMB. Registre el estado devuelto y la función del host inspeccionado. Un ajuste del servidor no describe todas las conexiones salientes desde ese host, y el estado de una característica no establece si una operación empresarial la utilizó. Si un comando no está disponible o falla en el destino, conserve el fallo y elija un método de inspección aplicable antes de declarar que el host está cubierto.
Evite utilizar un valor predeterminado histórico para suplir una observación ausente. El registro de decisión debe contener el resultado real del sistema inspeccionado, la hora de recopilación y la persona que lo interpretó. Conserve los resultados anteriores al cambio para compararlos después de la remediación.
Paso 2: activar la auditoría del servidor y conservar Event 3000
Para el alcance del servidor aprobado, Microsoft documenta este ajuste de auditoría:
Set-SmbServerConfiguration -AuditSmb1Access $true
Verifique el ajuste:
Get-SmbServerConfiguration | Select AuditSmb1Access
La misma guía de Learn identifica el evento 3000 en Microsoft-Windows-SMBServer/Audit como un intento de un cliente de conectarse mediante SMBv1 después de activar la auditoría. Conserve juntos el evento y la evidencia del estado de la auditoría. Un Event 3000 no demuestra un acceso correcto a un recurso compartido, una explotación ni un inventario completo de dependencias.
Asigne cada intento a un registro de investigación. Utilice la información del cliente realmente disponible en el evento y el inventario de apoyo para identificar un responsable; no invente una identidad del cliente cuando falte la correlación. Pregunte al responsable qué operación estaba en curso y obtenga su resultado. Clasifique el registro como un intento vinculado, un intento no resuelto o un flujo de trabajo que requiere más observación.
Un intento fallido también merece una explicación, pero no establece que el flujo de trabajo requiera SMBv1 para completarse correctamente. A la inversa, un flujo de trabajo que nunca se ejecutó no puede darse por validado simplemente porque el registro del servidor no contenga entradas pertinentes.
Paso 3: capturar las conexiones del cliente activo
Ejecute la comprobación del cliente documentada mientras la operación identificada esté activa:
Get-SmbConnection
La referencia de Get-SmbConnection de Microsoft describe las conexiones establecidas del cliente al servidor y expone el campo Dialect en sus ejemplos. Las filas se distinguen por el recurso compartido, el inicio de sesión del usuario y las credenciales utilizadas. Conserve ese contexto en lugar de reducir todas las filas a una única respuesta para la máquina.
Adjunte la instantánea al registro del flujo de trabajo con la hora de recopilación y los valores realmente devueltos. Un dialecto moderno en una conexión coincidente respalda esa ruta observada en ese momento. No valida otros recursos compartidos, identidades, dispositivos ni ejecuciones programadas. Una fila ausente no es un registro histórico de toda la actividad SMBv1; podría necesitarse otro método de observación para la ruta sin resolver.
Paso 4: conciliar las evidencias antes de decidir
Compare el evento, la instantánea del cliente y el resultado del flujo de trabajo. Si se refieren a distintos sistemas que lo invocan u operaciones, mantenga registros separados. Si un intento es visible en el servidor pero no se captura ninguna conexión establecida coincidente, conserve ambas observaciones sin fabricar un éxito ni un dialecto.
| Resultado de la revisión | Evidencia que conservar | Próxima decisión |
|---|---|---|
| Intento vinculado a un responsable | Evento, destino, contexto del cliente y respuesta del responsable | Determinar si el flujo de trabajo aún requiere la ruta antigua |
| Operación esperada observada en SMB2/3 | Instantánea del cliente coincidente y resultado del flujo de trabajo | Revalidar después del cambio SMBv1 aprobado |
| Intento que sigue sin explicación | Evento original y pasos de correlación fallidos | Continuar el triaje; mantener sin resolver el campo de responsable o cliente |
| Ningún evento en una ventana parcial | Comprobación del estado de auditoría, ventana real y tareas omitidas | Ampliar o rediseñar la recopilación en lugar de afirmar que no hay dependencia |
Sustituir la dependencia y revalidar SMB2/3 (Remediation)
Paso 1: hacer revisable la decisión sobre la dependencia
Para cada flujo de trabajo afectado, registre si se retirará, actualizará o trasladará a un dispositivo o servicio de sustitución. Identifique al responsable, la fecha prevista de finalización, el alcance piloto aprobado y el plan de recuperación. Si la dependencia no está resuelta, indique exactamente qué observación falta y quién la obtendrá.
El piloto debe incluir las rutas de cliente y servidor descubiertas durante la recopilación. No base un cambio para todo el parque en una sola conexión correcta. Incluya las operaciones periódicas identificadas durante la planificación o documente que su validación sigue pendiente.
Paso 2: aplicar el cambio SMBv1 aprobado
Microsoft documenta el siguiente comando para desactivar SMBv1 en el componente del servidor:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Para la característica opcional de Windows aplicable, el comando documentado es:
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
Seleccione el método adecuado para el destino y el alcance previsto. Estos cambios no son evidencias intercambiables: desactivar el protocolo del servidor y desactivar una característica opcional abordan distintas capas de configuración. La guía de Learn describe un reinicio para el cambio de la característica opcional, mientras que Set-SmbServerConfiguration no requiere un reinicio. Programe con el responsable el impacto de cualquier reinicio y conserve el resultado devuelto en lugar de suponer que el cambio se completó.
Si falla la compatibilidad, vuelva al registro del flujo de trabajo y a la sustitución prevista. Una decisión de recuperación debe identificar el servicio concreto afectado y su responsable; no debe redefinir silenciosamente la configuración de referencia de hosts ajenos al caso.
Paso 3: repetir las observaciones en el alcance modificado
Repita las comprobaciones aplicables de características y servidor y después ejecute las operaciones previstas. Capture las conexiones del cliente durante esas operaciones y mantenga la cobertura de auditoría del servidor durante la ventana justificada. Compare los registros anteriores y posteriores al cambio utilizando los mismos identificadores de host, recurso compartido y flujo de trabajo.
Cierre un registro de dependencia solo cuando el responsable pueda explicar qué cambió y aportar evidencia de que el flujo de trabajo requerido sigue funcionando en la ruta SMB2/3 prevista. Mantenga abiertos los casos de operaciones periódicas no probadas y dispositivos no disponibles. Un resultado de configuración, una prueba empresarial correcta y una instantánea de conexión responden a preguntas diferentes; el registro de cierre necesita la combinación pertinente.
Registre los intentos residuales después del cambio e investigue los sistemas que los originan. Su presencia no significa automáticamente que un flujo de trabajo empresarial haya fallado, y su ausencia no establece una cobertura completa. Mantenga la interpretación vinculada al alcance y a la ventana originales de auditoría.
Cómo detecta EtcSec este problema
En la implementación de etc-collector revisada, COMPUTER_LEGACY_PROTOCOL es una señal de triaje basada en el directorio. Su método Detect examina las cuentas de equipo habilitadas. Primero busca coincidencias con cinco patrones OS sin distinguir mayúsculas de minúsculas: Windows XP, Windows 2000, Windows NT, Server 2003 y Windows Vista. Una coincidencia añade el equipo a la lista de afectados y continúa con el siguiente equipo.
Para los equipos que no coinciden con esa rama, el detector comprueba si SupportedEncryptionTypes es distinto de cero y no contiene ninguno de los dos bits AES de la máscara 0x18. La rama OS tiene precedencia: un equipo que coincide allí no contribuye también al recuento del motivo de cifrado débil. El método devuelve un único hallazgo agregado, incluso cuando el número de afectados es cero.
El proveedor LDAP lee operatingSystem y msDS-SupportedEncryptionTypes en el modelo de equipo. Son atributos de directorio, no mediciones del tráfico SMB real. El analizador de enteros devuelve cero si falta un valor y descarta los errores de conversión, por lo que su resultado no conserva esos casos como resultados de recopilación distintos. El detector omite un valor de cifrado cero; eso no establece el uso de protocolos modernos.
La comprobación no observa un dialecto SMB, una versión NTLM, el uso real de DES/RC4, Event 3000 ni el éxito de un flujo de trabajo empresarial. Un equipo afectado requiere más investigación, y un recuento cero no puede cerrar la revisión de dependencias de SMBv1. Utilice el hallazgo para priorizar el proceso de recopilación de evidencias anterior.
Si el motivo es el atributo de cifrado, siga la guía de fallback Kerberos RC4 para distinguir los ajustes de directorio de la evidencia de tickets. Si la revisión plantea una cuestión de firma, utilice la guía de firma SMB sobre requisitos de firma y exposición al relay. Ninguna de estas revisiones sustituye la evidencia de intentos y dependencias de SMBv1 recopilada aquí.
Registro de decisión y referencias primarias
Antes de cerrar la revisión, conserve respuestas explícitas a estas preguntas:
- ¿Qué servidores y flujos de trabajo se auditaron, e incluyó la ventana sus tareas periódicas?
- ¿Qué intentos Event 3000 se vincularon a un cliente y a un responsable, y qué resultado se verificó para cada operación?
- ¿Qué dependencia se eliminó o sustituyó, y qué evidencia revalida los flujos de trabajo SMB2/3 requeridos?
Adjunte los resultados originales de configuración, la ventana de auditoría, los eventos, las instantáneas del cliente, las decisiones de los responsables y la validación posterior al cambio. Cuando siga faltando evidencia, indique la laguna y la siguiente acción. Este es un método de revisión propuesto, no una afirmación de que algún dominio haya superado estas comprobaciones.
Explore las páginas de identidad que apoyan este tema