Prove di dipendenza SMBv1: tentativi e dialetti

Le prove di dipendenza da SMBv1 devono collegare un tentativo osservato di un client a un server, a un flusso di lavoro e a un responsabile. Una vecchia etichetta del sistema operativo in Active Directory può aiutare a dare priorità all'indagine, ma non può stabilire quale dialetto SMB utilizzi oggi un dispositivo. Prima di rimuovere SMBv1, costruite un registro che distingua configurazione, tentativi di utilizzo, connessioni stabilite e lacune nell'osservazione.

Questa guida descrive un percorso di verifica e correzione per ambienti AD. I comandi seguenti sono esempi documentati che un amministratore Windows autorizzato può eseguire sui sistemi previsti; non sono stati eseguiti su un dominio reale per questo articolo. Nessun output di esempio viene presentato come risultato misurato.

Che cosa sono le prove di dipendenza da SMBv1?

Una dipendenza è un'affermazione operativa: un flusso di lavoro aziendale identificato richiede ancora SMBv1 per essere completato. Questa affermazione richiede un riscontro più solido di un attributo di directory, di un componente installato su disco o della dichiarazione che un dispositivo è vecchio. Trattate ciascuno di questi elementi come un dato per l'indagine e registrate quale osservazione confermerebbe o indebolirebbe l'affermazione.

La revisione deve rispondere a tre domande. Quali server e client sono coinvolti? Quale operazione deve riuscire? Quali prove collegano l'osservazione del protocollo a quell'operazione? Se il responsabile non può rispondere, la dipendenza rimane non verificata. Ciò non rende innocua la rimozione; significa che la decisione richiede un progetto pilota con un perimetro definito e un'ulteriore raccolta.

Usate un registro delle prove con voci separate per configurazione, tentativi lato server, istantanee lato client e risultati dei flussi di lavoro. Mantenere separate queste voci evita un errore comune: usare una connessione moderna acquisita da una postazione per chiudere un rilievo relativo a un altro dispositivo, un'altra identità o un'attività notturna.

Come collegare le prove

Partite dal flusso di lavoro anziché da una modifica estesa a tutto il parco. Chiedete al responsabile del servizio di elencarne le destinazioni e i sistemi chiamanti, comprese le attività periodiche che potrebbero non essere eseguite durante un test interattivo. Registrate quali sistemi Windows possono fornire audit del server o osservazioni client e quali dispositivi richiedono un altro metodo di raccolta. Un'appliance che non può eseguire i comandi proposti rimane nella popolazione non risolta finché il suo responsabile non fornisce prove adeguate.

Scegliete una finestra di raccolta che includa il ciclo operativo pertinente. Un test giornaliero in primo piano non esercita un'esportazione mensile. Qui non è prescritta una durata universale: il responsabile deve giustificare la finestra usando la pianificazione effettiva e le eventuali operazioni insolite o di ripristino rilevanti. Registrate gli orari di inizio e fine, i flussi esclusi, gli host mancanti e le interruzioni della raccolta.

Per ogni osservazione, conservate l'host di origine e il contesto prima di trarre una conclusione. Un timestamp da solo non è sufficiente se i registri del server e del client non possono essere collegati alla stessa destinazione e operazione. Quando non è possibile stabilire il collegamento, indicate la correlazione come non risolta invece di trattare la vicinanza temporale come una prova.

Rilevamento: verificare configurazione, tentativi e connessioni

Passaggio 1: esaminare il componente Windows e l'impostazione del server

Microsoft documenta questi controlli nella sua guida alla gestione dei protocolli SMB. Usate i comandi appropriati per il sistema Windows esaminato e conservatene gli output come elementi di prova separati. Eseguite i comandi delle funzionalità facoltative in una sessione PowerShell con privilegi elevati, come richiesto dalla guida Learn.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Get-SmbServerConfiguration | Select EnableSMB1Protocol

Il primo riporta lo stato della funzionalità facoltativa; il secondo riporta l'impostazione del server SMB. Registrate lo stato restituito e il ruolo dell'host esaminato. Un'impostazione server non descrive tutte le connessioni in uscita da quell'host, e lo stato di una funzionalità non stabilisce se sia stata utilizzata da un'operazione aziendale. Se un comando non è disponibile o non riesce sulla destinazione, conservate l'errore e scegliete un metodo di ispezione applicabile prima di dichiarare coperto l'host.

Evitate di usare un valore predefinito storico per colmare un'osservazione mancante. Il registro decisionale deve contenere il risultato effettivo del sistema esaminato, l'ora di raccolta e il revisore che lo ha interpretato. Conservate i risultati precedenti alla modifica per il confronto dopo la correzione.

Passaggio 2: abilitare l'audit del server e conservare Event 3000

Per il perimetro server approvato, Microsoft documenta questa impostazione di audit:

Set-SmbServerConfiguration -AuditSmb1Access $true

Verificate l'impostazione:

Get-SmbServerConfiguration | Select AuditSmb1Access

La stessa guida Learn identifica l'evento 3000 in Microsoft-Windows-SMBServer/Audit come un tentativo di un client di connettersi usando SMBv1 dopo l'abilitazione dell'audit. Conservate insieme l'evento e le prove dello stato dell'audit. Un Event 3000 non dimostra un accesso riuscito a una condivisione, uno sfruttamento o un inventario completo delle dipendenze.

Assegnate ogni tentativo a un registro di indagine. Usate le informazioni client effettivamente disponibili nell'evento e l'inventario di supporto per identificare un responsabile; non inventate un'identità client quando manca la correlazione. Chiedete al responsabile quale operazione fosse in corso e ottenetene il risultato. Classificate il registro come tentativo associato, tentativo non risolto o flusso di lavoro che richiede ulteriori osservazioni.

Anche un tentativo non riuscito merita una spiegazione, ma non stabilisce che il flusso di lavoro richieda SMBv1 per riuscire. Viceversa, un flusso di lavoro mai eseguito non può essere considerato validato solo perché il registro server non contiene voci pertinenti.

Passaggio 3: acquisire le connessioni del client attivo

Eseguite il controllo client documentato mentre l'operazione identificata è attiva:

Get-SmbConnection

Il riferimento Get-SmbConnection di Microsoft descrive le connessioni stabilite dal client al server e mostra il campo Dialect negli esempi. Le righe si distinguono per condivisione, accesso utente e credenziali utilizzate. Conservate questo contesto invece di ridurre tutte le righe a un'unica risposta per la macchina.

Allegate l'istantanea al registro del flusso di lavoro con l'ora di raccolta e i valori effettivamente restituiti. Un dialetto moderno su una connessione corrispondente supporta il percorso osservato in quel momento. Non valida altre condivisioni, identità, dispositivi o esecuzioni pianificate. Una riga mancante non è una registrazione storica di tutta l'attività SMBv1; per il percorso non risolto potrebbe essere necessario un altro metodo di osservazione.

Passaggio 4: riconciliare le prove prima di decidere

Confrontate evento, istantanea client e risultato del flusso di lavoro. Se riguardano chiamanti o operazioni diversi, mantenete registri separati. Se un tentativo è visibile sul server ma non viene acquisita una connessione stabilita corrispondente, conservate entrambe le osservazioni senza inventare un successo o un dialetto.

Sostituire la dipendenza e rivalidare SMB2/3 (Remediation)

Passaggio 1: rendere verificabile la decisione sulla dipendenza

Per ogni flusso di lavoro interessato, registrate se verrà dismesso, aggiornato o trasferito a un dispositivo o servizio sostitutivo. Indicate responsabile, data di completamento prevista, perimetro pilota approvato e piano di ripristino. Se la dipendenza non è risolta, specificate esattamente quale osservazione manca e chi la otterrà.

Il progetto pilota deve includere i percorsi client e server scoperti durante la raccolta. Non basate una modifica estesa a tutto il parco su una sola connessione riuscita. Includete le operazioni periodiche identificate nella fase di pianificazione o documentate che la loro validazione è ancora in sospeso.

Passaggio 2: applicare la modifica SMBv1 approvata

Microsoft documenta il comando seguente per disabilitare SMBv1 sul componente server:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Per la funzionalità facoltativa Windows applicabile, il comando documentato è:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Selezionate il metodo appropriato per la destinazione e il perimetro previsto. Queste modifiche non sono prove intercambiabili: disabilitare il protocollo server e disabilitare una funzionalità facoltativa interviene su livelli di configurazione diversi. La guida Learn descrive un riavvio per la modifica alla funzionalità facoltativa, mentre Set-SmbServerConfiguration non richiede un riavvio. Pianificate con il responsabile l'impatto di eventuali riavvii e conservate il risultato restituito invece di presumere che la modifica sia stata completata.

Se la compatibilità non funziona, tornate al registro del flusso di lavoro e alla sostituzione prevista. Una decisione di ripristino deve identificare il servizio specifico interessato e il suo responsabile; non deve ridefinire silenziosamente la configurazione di riferimento per host estranei al caso.

Passaggio 3: ripetere le osservazioni sul perimetro modificato

Ripetete i controlli applicabili della funzionalità e del server, quindi eseguite le operazioni previste. Acquisite le connessioni client durante tali operazioni e mantenete la copertura dell'audit server per tutta la finestra giustificata. Confrontate i registri precedenti e successivi alla modifica usando gli stessi identificatori di host, condivisione e flusso di lavoro.

Chiudete un registro di dipendenza solo quando il responsabile può spiegare cosa è cambiato e fornire prove che il flusso di lavoro richiesto funzioni ancora sul percorso SMB2/3 previsto. Lasciate aperti i casi di operazioni periodiche non testate e dispositivi non disponibili. Un risultato di configurazione, un test aziendale superato e un'istantanea di connessione rispondono a domande diverse; il registro di chiusura richiede la combinazione pertinente.

Registrate i tentativi residui dopo la modifica e indagate sui loro chiamanti. La loro presenza non significa automaticamente che un flusso di lavoro aziendale sia fallito, e la loro assenza non stabilisce una copertura completa. Mantenete l'interpretazione legata al perimetro e alla finestra di audit originali.

Come EtcSec rileva questo problema

Nell'implementazione di etc-collector esaminata, COMPUTER_LEGACY_PROTOCOL è un segnale di triage basato sulla directory. Il metodo Detect esamina gli account computer abilitati. Per prima cosa cerca corrispondenze con cinque pattern OS senza distinguere maiuscole e minuscole: Windows XP, Windows 2000, Windows NT, Server 2003 e Windows Vista. Una corrispondenza aggiunge il computer all'elenco degli interessati e passa al computer successivo.

Per i computer che non corrispondono a quel ramo, il rilevatore verifica se SupportedEncryptionTypes è diverso da zero e non contiene nessuno dei due bit AES della maschera 0x18. Il ramo OS ha la precedenza: un computer corrispondente a quel ramo non contribuisce anche al conteggio del motivo di cifratura debole. Il metodo restituisce un unico rilievo aggregato, anche quando il numero di interessati è zero.

Il provider LDAP legge operatingSystem e msDS-SupportedEncryptionTypes nel modello del computer. Si tratta di attributi di directory, non di misurazioni del traffico SMB reale. Il parser di interi restituisce zero per un valore assente e scarta gli errori di conversione; il suo risultato non conserva quindi questi casi come esiti distinti della raccolta. Il rilevatore ignora un valore di cifratura pari a zero; ciò non stabilisce l'utilizzo di protocolli moderni.

Il controllo non osserva un dialetto SMB, una versione NTLM, l'utilizzo effettivo di DES/RC4, Event 3000 o il successo di un flusso di lavoro aziendale. Un computer interessato richiede ulteriori indagini, e un conteggio pari a zero non può chiudere la revisione delle dipendenze da SMBv1. Usate il rilievo per dare priorità al percorso di raccolta delle prove descritto sopra.

Se il motivo è l'attributo di cifratura, seguite la guida al fallback Kerberos RC4 per distinguere le impostazioni di directory dalle prove dei ticket. Se la revisione solleva una questione di firma, usate la guida alla firma SMB per i requisiti di firma e l'esposizione al relay. Nessuna di queste revisioni sostituisce le prove dei tentativi e delle dipendenze da SMBv1 raccolte qui.

Registro decisionale e riferimenti primari

Prima di chiudere la revisione, conservate risposte esplicite a queste domande:

1. Quali server e flussi di lavoro sono stati sottoposti ad audit, e la finestra comprendeva le loro attività periodiche?
2. Quali tentativi Event 3000 sono stati associati a un client e a un responsabile, e quale esito è stato verificato per ogni operazione?
3. Quale dipendenza è stata rimossa o sostituita, e quali prove rivalidano i flussi di lavoro SMB2/3 richiesti?

Allegate i risultati di configurazione originali, la finestra di audit, gli eventi, le istantanee client, le decisioni dei responsabili e la validazione successiva alla modifica. Dove mancano ancora prove, indicate la lacuna e l'azione successiva. Questo è un metodo di revisione proposto, non l'affermazione che un dominio abbia superato questi controlli.

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