Evidencia de dependencia do SMBv1: tentativas e dialetos

A evidencia de dependencia do SMBv1 deve ligar uma tentativa de ligação observada de um cliente a um servidor, a um fluxo de trabalho e a um responsável. Uma designação antiga do sistema operativo no Active Directory pode ajudar a priorizar a investigação, mas não permite determinar que dialeto SMB um dispositivo utiliza hoje. Antes de remover o SMBv1, crie um registo que distinga configuração, tentativas de utilização, ligações estabelecidas e lacunas na observação.

Este guia descreve um fluxo de verificação e remediação para ambientes AD. Os comandos abaixo são exemplos documentados para um administrador Windows autorizado executar nos sistemas previstos; não foram executados num domínio real para este artigo. Nenhuma saída de exemplo é apresentada como um resultado medido.

O que constitui evidência de dependência do SMBv1?

Uma dependência é uma afirmação operacional: um fluxo de trabalho de negócio identificado ainda precisa de SMBv1 para ser concluído. Essa afirmação exige provas mais sólidas do que um atributo do diretório, um componente instalado no disco ou a declaração de que um dispositivo é antigo. Trate cada um destes elementos como uma entrada para a investigação e registe que observação confirmaria ou enfraqueceria a afirmação.

A análise deve responder a três perguntas. Que servidor e cliente estão envolvidos? Que operação precisa de ser bem-sucedida? Que evidência liga a observação do protocolo a essa operação? Se o responsável não conseguir responder, a dependência permanece por verificar. Isso não torna a remoção inofensiva; significa que a decisão exige um piloto com âmbito definido e recolha adicional.

Utilize um registo de evidências com entradas separadas para configuração, tentativas no servidor, capturas pontuais no cliente e resultados dos fluxos de trabalho. Manter estas entradas separadas evita um erro comum: utilizar uma ligação moderna capturada num computador de trabalho para encerrar um achado relativo a outro dispositivo, outra identidade ou uma tarefa noturna.

Como as evidências se complementam

Comece pelo fluxo de trabalho, em vez de uma alteração generalizada em todo o ambiente. Peça ao responsável pelo serviço para listar os destinos e os sistemas que o contactam, incluindo tarefas periódicas que podem não ser executadas durante um teste interativo. Registe que sistemas Windows podem fornecer auditoria do servidor ou observações do cliente e que dispositivos precisam de outro método de recolha. Um equipamento que não consiga executar os comandos propostos pertence ao conjunto por esclarecer até que o seu responsável forneça evidências adequadas.

Escolha uma janela de recolha que inclua o ciclo operacional relevante. Um teste diário em primeiro plano não exercita uma exportação mensal. Não se prescreve aqui uma duração universal: o responsável deve justificar a janela com base no calendário real e nas operações excecionais ou de recuperação que sejam relevantes. Registe as horas de início e fim, os fluxos de trabalho excluídos, os hosts em falta e as interrupções na recolha.

Para cada observação, preserve o host de origem e o contexto antes de tirar conclusões. Uma data e hora, por si só, não bastam se os registos do servidor e do cliente não puderem ser associados ao mesmo destino e à mesma operação. Quando não for possível estabelecer essa ligação, marque a correlação como por esclarecer, em vez de tratar a proximidade temporal como prova.

Deteção: verificar configuração, tentativas e ligações

Passo 1: inspecionar o componente Windows e a definição do servidor

A Microsoft documenta estas verificações no seu guia de gestão dos protocolos SMB. Utilize os comandos adequados ao sistema Windows em análise e guarde as respetivas saídas como elementos de evidência separados. Execute os comandos de funcionalidades opcionais numa sessão PowerShell com privilégios elevados, conforme exigido pelo guia do Learn.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Get-SmbServerConfiguration | Select EnableSMB1Protocol

O primeiro devolve o estado da funcionalidade opcional; o segundo devolve a definição do servidor SMB. Registe o estado devolvido e a função do host inspecionado. Uma definição do servidor não descreve todas as ligações de saída desse host, e o estado de uma funcionalidade não determina se uma operação de negócio a utilizou. Se um comando não estiver disponível ou falhar no destino, preserve a falha e escolha um método de inspeção aplicável antes de declarar que o host está coberto.

Evite utilizar um valor predefinido histórico para preencher uma observação em falta. O registo da decisão deve conter o resultado real do sistema inspecionado, o momento da recolha e o revisor que o interpretou. Guarde os resultados anteriores à alteração para comparação após a remediação.

Passo 2: ativar a auditoria do servidor e preservar Event 3000

Para o âmbito de servidores aprovado, a Microsoft documenta esta definição de auditoria:

Set-SmbServerConfiguration -AuditSmb1Access $true

Verifique a definição:

Get-SmbServerConfiguration | Select AuditSmb1Access

O mesmo guia do Learn identifica Event ID 3000 em Microsoft-Windows-SMBServer/Audit como uma tentativa de um cliente de estabelecer ligação através de SMBv1 após a ativação da auditoria. Preserve o evento juntamente com a evidência do estado da auditoria. Um Event 3000 não prova acesso bem-sucedido a uma partilha, exploração ou um inventário completo de dependências.

Associe cada tentativa a um registo de investigação. Utilize as informações do cliente efetivamente disponíveis no evento e o inventário de apoio para identificar um responsável; não invente uma identidade de cliente quando faltar a correlação. Pergunte ao responsável que operação estava em execução e obtenha o respetivo resultado. Classifique o registo como uma tentativa identificada, uma tentativa por esclarecer ou um fluxo de trabalho que exige mais observação.

Uma tentativa malsucedida também merece explicação, mas não determina que o fluxo de trabalho precise de SMBv1 para ser bem-sucedido. Por outro lado, um fluxo de trabalho que nunca foi executado não pode ser considerado livre dessa dependência apenas porque o registo do servidor não tem entradas relevantes.

Passo 3: capturar as ligações do cliente ativo

Execute a verificação documentada do cliente enquanto a operação identificada está ativa:

Get-SmbConnection

A referência de Get-SmbConnection da Microsoft descreve ligações estabelecidas entre cliente e servidor e mostra o campo Dialect nos seus exemplos. As linhas distinguem-se por partilha, início de sessão do utilizador e credenciais utilizadas. Preserve esse contexto, em vez de reduzir todas as linhas a uma única resposta para a máquina.

Anexe a captura pontual ao registo do fluxo de trabalho, com o momento da recolha e os valores efetivamente devolvidos. Um dialeto moderno numa ligação correspondente sustenta esse caminho observado naquele momento. Não iliba outras partilhas, identidades, dispositivos ou execuções agendadas. Uma linha ausente não é um registo histórico de toda a atividade SMBv1; pode ser necessário outro método de observação para o caminho por esclarecer.

Passo 4: reconciliar as evidências antes de decidir

Compare o evento, a captura do cliente e o resultado do fluxo de trabalho. Se disserem respeito a diferentes sistemas de origem ou operações, mantenha registos separados. Se uma tentativa for visível no servidor, mas não for capturada uma ligação estabelecida correspondente, preserve ambas as observações sem fabricar um sucesso ou um dialeto.

Remediação: substituir a dependência e revalidar SMB2/3 (Remediation)

Passo 1: tornar a decisão sobre a dependência passível de revisão

Para cada fluxo de trabalho afetado, registe se será descontinuado, atualizado ou transferido para um dispositivo ou serviço de substituição. Identifique o responsável, a data prevista de conclusão, o âmbito aprovado do piloto e o plano de recuperação. Se a dependência estiver por esclarecer, indique exatamente que observação falta e quem a obterá.

O piloto deve incluir os caminhos de cliente e servidor descobertos durante a recolha. Não baseie uma alteração de todo o ambiente numa única ligação bem-sucedida. Inclua as operações periódicas identificadas na fase de planeamento ou documente que a sua validação continua pendente.

Passo 2: aplicar a alteração SMBv1 aprovada

A Microsoft documenta o seguinte comando para desativar SMBv1 no componente de servidor:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Para a funcionalidade opcional Windows aplicável, o comando documentado é:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Selecione o método adequado ao destino e ao âmbito pretendido. Estas alterações não são evidências intercambiáveis: desativar o protocolo do servidor e desativar uma funcionalidade opcional abordam camadas de configuração diferentes. O guia do Learn descreve um reinício para a alteração da funcionalidade opcional, enquanto Set-SmbServerConfiguration não exige reinício. Planeie qualquer impacto do reinício com o responsável e guarde o resultado devolvido, em vez de presumir que a alteração foi concluída.

Se a compatibilidade falhar, volte ao registo do fluxo de trabalho e à substituição prevista. Uma decisão de recuperação deve identificar o serviço específico afetado e o responsável; não deve redefinir silenciosamente a configuração de referência para hosts não relacionados.

Passo 3: repetir as observações no âmbito alterado

Repita as verificações aplicáveis da funcionalidade e do servidor e, depois, execute as operações previstas. Capture as ligações dos clientes durante essas operações e mantenha a cobertura de auditoria do servidor ao longo da janela justificada. Compare os registos anteriores e posteriores à alteração utilizando os mesmos identificadores de host, partilha e fluxo de trabalho.

Encerre um registo de dependência apenas quando o responsável conseguir explicar o que mudou e fornecer evidências de que o fluxo de trabalho necessário continua a funcionar no caminho SMB2/3 previsto. Mantenha em aberto as operações periódicas não testadas e os dispositivos indisponíveis. Um resultado de configuração, um teste de negócio bem-sucedido e uma captura de ligações respondem a perguntas diferentes; o registo de encerramento exige a combinação relevante.

Registe as tentativas residuais após a alteração e investigue os sistemas que as originam. A sua presença não significa automaticamente que um fluxo de trabalho de negócio falhou, e a sua ausência não determina uma cobertura completa. Mantenha a interpretação associada ao âmbito e à janela originais da auditoria.

Como a EtcSec deteta isto

Na implementação revista do etc-collector, COMPUTER_LEGACY_PROTOCOL é um sinal de triagem baseado no diretório. O seu método Detect examina contas de computador ativadas. Primeiro, procura correspondências com cinco padrões de sistema operativo, sem distinguir maiúsculas de minúsculas: Windows XP, Windows 2000, Windows NT, Server 2003 e Windows Vista. Uma correspondência adiciona o computador à lista de afetados e prossegue para o computador seguinte.

Para os computadores que não correspondem a esse ramo, o detetor verifica se SupportedEncryptionTypes é diferente de zero e não tem nenhum dos dois bits AES da máscara 0x18. O ramo do sistema operativo tem precedência: um computador identificado nesse ramo não contribui também para a contagem do motivo de encriptação fraca. O método devolve um único achado agregado, incluindo quando a contagem de afetados é zero.

O fornecedor LDAP lê operatingSystem e msDS-SupportedEncryptionTypes para o modelo do computador. Estes são atributos do diretório, não medições de tráfego SMB ativo. O parser de inteiros devolve zero para um valor ausente e descarta erros de conversão, pelo que o seu resultado não preserva esses casos como resultados distintos da recolha. O detetor ignora um valor de encriptação zero; isso não determina a utilização de um protocolo moderno.

A verificação não observa um dialeto SMB, uma versão NTLM, a utilização efetiva de DES/RC4, Event 3000 ou o sucesso de um fluxo de trabalho de negócio. Um computador afetado exige investigação adicional, e uma contagem zero não pode encerrar a análise da dependência de SMBv1. Utilize o achado para priorizar o fluxo de evidências acima.

Se o motivo for o atributo de encriptação, siga o guia separado de fallback Kerberos RC4 para distinguir definições do diretório de evidências dos tickets. Se a análise levantar uma questão de assinatura, utilize o guia de assinatura SMB sobre requisitos de assinatura e exposição a relay. Nenhuma destas análises substitui as evidências de tentativas e dependências de SMBv1 recolhidas aqui.

Registo da decisão e referências primárias

Antes de encerrar a análise, guarde respostas explícitas a estas perguntas de revisão:

1. Que servidores e fluxos de trabalho foram auditados, e a janela incluiu as respetivas tarefas periódicas?
2. Que tentativas Event 3000 foram associadas a um cliente e a um responsável, e que resultado foi verificado para cada operação?
3. Que dependência foi removida ou substituída, e que evidências revalidam os fluxos de trabalho SMB2/3 necessários?

Anexe os resultados originais da configuração, a janela de auditoria, os eventos, as capturas dos clientes, as decisões dos responsáveis e a validação após a alteração. Onde faltarem evidências, indique a lacuna e a próxima ação. Este é um método de revisão proposto, não uma afirmação de que algum domínio passou estas verificações.

• Microsoft Learn: Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft Learn: Get-SmbConnection