Che cosa significa firma SMB disabilitata?
Firma SMB disabilitata di solito significa che i client Windows, i server Windows, o entrambi, non richiedono traffico SMB firmato. Nei sistemi Windows moderni, il controllo esatto è l'impostazione RequireSecuritySignature sul client SMB e sul server SMB.
La documentazione Microsoft sulla firma SMB è esplicita su cosa fa questa funzione. La firma SMB aggiunge una firma a ogni messaggio SMB usando la chiave di sessione e la suite di cifratura. Se un attaccante manomette il messaggio in transito, la firma non corrisponde più. Microsoft afferma anche che la firma SMB aiuta a proteggere da attacchi di relay e di spoofing.
Per questo motivo il problema di sicurezza non è solo la "condivisione file non firmata". Quando la firma SMB non è richiesta sui percorsi dove dovrebbe esserlo, l'ambiente è più esposto a intercettazioni adversary-in-the-middle e a opportunità di NTLM relay.
Il perimetro di questo articolo è SMB 2.x e 3.x su Windows in ambienti Active Directory, con enfasi sull'esposizione al relay, sulla verifica e sull'hardening pratico. Il punto non è sostenere che la sola firma SMB risolva ogni percorso di relay. Il punto è che disabilitarla, o non richiederla, elimina una delle protezioni a livello di protocollo che Microsoft ha costruito specificamente per fermare manomissione e relay sul traffico SMB.
Come funziona la firma SMB
Microsoft descrive la firma SMB come una funzione di sicurezza che usa la chiave di sessione e la suite di cifratura per aggiungere una firma a un messaggio che attraversa la connessione SMB. La firma contiene un hash dell'intero messaggio nell'header SMB. Se qualcuno modifica il messaggio in transito, la verifica della firma fallisce.
Per SMB 2.x e 3.x, la firma è controllata dal fatto che sia richiesta, non dalla vecchia logica EnableSecuritySignature dell'epoca SMB1. Microsoft afferma che, a partire da SMB 2.02, EnableSecuritySignature viene ignorato e la firma è controllata unicamente dal fatto che sia richiesta.
Questa distinzione conta perché i team spesso pensano che la firma SMB sia abilitata solo perché esiste un'impostazione legacy da qualche parte nella policy, anche quando il requisito effettivo resta disattivato.
Quando la firma SMB viene usata davvero
Microsoft riassume il comportamento in modo chiaro:
- la firma viene usata quando il client SMB la richiede
- la firma viene usata quando il server SMB la richiede
- la firma non viene usata solo quando né il client SMB né il server SMB la richiedono
Questo significa che lo stato vulnerabile è più ampio di un singolo file server mal configurato. Se nessuna delle due parti richiede la firma, la sessione può procedere senza firma.
Perché la firma SMB conta negli ambienti AD
SMB non è solo un protocollo di condivisione file. Gli ambienti Active Directory lo usano per flussi comuni come l'accesso a SYSVOL e NETLOGON, le share amministrative e l'accesso operativo ai file tra endpoint e server.
Microsoft segnala esplicitamente che i domain controller richiedono la firma SMB per impostazione predefinita per le connessioni verso di loro, in particolare intorno a SYSVOL e NETLOGON. Questa impostazione predefinita esiste per un motivo preciso: il traffico SMB non firmato nell'infrastruttura di identità è molto più facile da manomettere o relayare.
Firma SMB disabilitata rispetto a firma SMB non richiesta
Nella pratica, i team usano spesso queste due etichette in modo intercambiabile, ma la sfumatura tecnica conta.
- Disabilitata di solito significa che l'amministratore ha impostato esplicitamente
RequireSecuritySignaturesuFalsesul client, sul server o su entrambi. - Non richiesta significa che l'endpoint può comunque firmare se l'altra parte lo impone, ma accetterà anche una sessione non firmata quando nessuna delle due parti richiede la firma.
Dal punto di vista del rischio, entrambi gli stati possono creare lo stesso problema operativo: sessioni SMB a cui è permesso procedere senza firma.
Per questo motivo molti audit riducono i due casi a un'unica finding. La vera domanda non è se una casella dice "abilitata". La vera domanda è se il client o il server rifiuteranno SMB non firmato.
Perché la firma SMB disabilitata conta ancora
Questo controllo conta ancora perché Microsoft continua a descrivere la firma SMB come una difesa contro manomissione dei messaggi, spoofing e relay, e perché molti percorsi di relay dipendono ancora dal riuscire a far accettare traffico a un server senza questa protezione.
SMB non firmato offre agli attaccanti un percorso di protocollo più debole
Se un client e un server possono negoziare una sessione non firmata, un attaccante presente sulla rete ha più margine per interferire con il traffico o per relayare materiale di autenticazione verso un altro host.
NTLM esiste ancora negli ambienti reali
Anche nelle organizzazioni che spingono verso Kerberos e protocolli più robusti, Microsoft continua a documentare il blocco di NTLM su SMB come misura di hardening separata per Windows 11 24H2 e Windows Server 2025. È un segnale forte del fatto che il problema del downgrade di protocollo e dell'autenticazione legacy resta operativamente rilevante.
I dispositivi di terze parti e l'accesso in stile guest indeboliscono spesso il percorso
Su questo punto la guida Microsoft sulla firma SMB è diretta: se un server SMB di terze parti non supporta la firma, alcuni team disabilitano la firma su Windows solo per ripristinare la compatibilità. Microsoft mette esplicitamente in guardia dall'usare questo come workaround, perché significa concedere fiducia a un accesso in stile guest, o non firmato, verso una share remota.
Condizioni per un'esposizione reale della firma SMB
Una finding SMB_SIGNING_DISABLED diventa concretamente importante quando le condizioni seguenti si sovrappongono.
1. Nessuna delle due parti richiede la firma su un percorso rilevante
L'esposizione centrale è che sia il client SMB sia il server SMB possono procedere senza richiedere firme.
2. NTLM resta disponibile su quel percorso
La guida Microsoft su SMB raccomanda ripetutamente Kerberos rispetto a NTLMv2 e sconsiglia l'uso di indirizzi IP o record CNAME, perché questi pattern tendono a spingere l'autenticazione lontano da Kerberos e verso NTLM. Questo conta perché SMB non firmato più percorsi di accesso orientati a NTLM è una combinazione classica che abilita il relay.
3. L'attaccante può posizionarsi sul percorso o influenzarlo
Gli attacchi di relay e intercettazione non sono magia a distanza. L'attaccante deve poter forzare o instradare il traffico attraverso un sistema che controlla, oppure comunque abusare di un percorso in cui può relayare le credenziali.
4. Le share amministrative o ad alto valore sono raggiungibili
Un relay contro una share innocua è un problema. Un relay contro un server di gestione, una share amministrativa o un servizio file sensibile è un problema diverso. Se questi sistemi sono raggiungibili anche a causa di un'igiene operativa debole, il raggio d'impatto cresce. È uno dei motivi per rivedere Account Obsoleti e Sovraprivilegiati: Il Rischio Nascosto in Active Directory insieme alle impostazioni di rete esposte al relay.
5. L'ambiente contiene ancora client, dispositivi o flussi guest legacy
La pressione operativa per continuare a supportare vecchi dispositivi NAS, appliance, scanner o pattern di accesso simili a un guest è una delle ragioni principali per cui la firma finisce per non essere richiesta fin dall'inizio.
La catena di attacco
Un percorso di attacco pratico che coinvolge la firma SMB disabilitata spesso si presenta così.
Step 1 - Trovare un percorso SMB non firmato
L'attaccante identifica una coppia server/client in cui nessuna delle due parti richiede la firma SMB.
Step 2 - Forzare o intercettare l'autenticazione
L'attaccante induce un sistema o un utente target ad autenticarsi via SMB su un percorso che può osservare o influenzare.
Step 3 - Relayare il tentativo di autenticazione
Se le condizioni più ampie lo permettono, l'attaccante relaya il tentativo di autenticazione verso un altro servizio SMB o verso un altro endpoint di protocollo che accetta l'identità relayata.
Step 4 - Usare immediatamente l'accesso ottenuto
Il relay è utile perché l'attaccante non ha bisogno di craccare prima la password. Se il relay riesce, può agire con l'accesso della vittima in tempo reale.
Per questo motivo questa finding va letta insieme a NTLM Relay: rilevamento e prevenzione. La firma SMB disabilitata non è tutta la storia del relay, ma è uno dei modi più chiari per rendere il relay SMB più facile di quanto dovrebbe essere.
Rilevamento
Il rilevamento per questo problema ha due parti: rilevamento della configurazione e rilevamento operativo.
Rilevamento della configurazione
Il metodo di verifica più diretto è controllare se il client SMB o il server SMB richiedono effettivamente la firma.
Microsoft documenta i controlli PowerShell esatti:
Get-SmbClientConfiguration | FL RequireSecuritySignature
Get-SmbServerConfiguration | FL RequireSecuritySignature
Se il valore è False, la firma non è richiesta su quel lato.
Nel Group Policy, Microsoft colloca le impostazioni rilevanti sotto:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security OptionsMicrosoft network client: Digitally sign communications (always)Microsoft network server: Digitally sign communications (always)
Questo è il modo più rapido per trasformare un'affermazione di audit vaga in un sì o no concreto.
Verificare la compatibilità prima di imporre la firma
Un miglioramento pratico nelle versioni più recenti di Windows è l'audit della firma e della crittografia SMB. Microsoft documenta i seguenti controlli di audit:
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $trueSet-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true
Gli eventi correlati vengono registrati in:
Microsoft-Windows-SMBClient/Audit, con gli ID evento31998e31999Microsoft-Windows-SMBServer/Audit, con gli ID evento3021e3022
Questi eventi sono particolarmente utili quando vuoi rendere la firma obbligatoria ma devi prima scoprire quali sistemi di terze parti si romperanno.
Rilevamento operativo
Se sospetti un abuso reale e non solo una configurazione debole, correla:
- gli host su cui la firma non è richiesta
- i pattern di traffico SMB con uso intenso di NTLM
- l'attività in stile relay individuata in Monitoraggio Sicurezza AD: Event ID e SIEM
- gli accessi inattesi a share amministrative o a servizi file sensibili
- i sistemi che usano accesso SMB basato su IP o pattern di denominazione che evitano Kerberos
Non esiste un singolo evento Windows che dica "il relay NTLM è riuscito perché la firma SMB era disabilitata". Il modello migliore è identificare prima il percorso non firmato, poi correlare l'attività di autenticazione e di accesso intorno ad esso.
Mitigazione
Il rimedio principale è semplice: richiedere la firma SMB dove deve essere richiesta, poi ridurre i comportamenti di protocollo adiacenti che mantengono il relay praticabile.
1. Richiedere la firma SMB su entrambi i lati, dove possibile
Microsoft documenta i comandi PowerShell esatti:
Set-SmbClientConfiguration -RequireSecuritySignature $true
Set-SmbServerConfiguration -RequireSecuritySignature $true
A livello di policy, le impostazioni rilevanti sono:
Microsoft network client: Digitally sign communications (always)Microsoft network server: Digitally sign communications (always)
Se controlli sia i client Windows sia i file server Windows, questa è la baseline più pulita.
2. Non trattare l'incompatibilità di terze parti come un motivo per normalizzare SMB debole
Microsoft mette esplicitamente in guardia dal disabilitare la firma SMB come workaround per server di terze parti, e dal tentare di usare la firma con account guest. Se un'appliance di terze parti non supporta correttamente la firma, documentala come debito tecnico o isolala. Non abbassare silenziosamente la baseline Windows per tutto il resto.
3. Preferire Kerberos ed evitare i pattern che spingono verso NTLM
Microsoft raccomanda di:
- usare Kerberos invece di NTLMv2
- non connettersi alle share tramite indirizzo IP
- non usare record CNAME per l'accesso SMB dove forzano un comportamento NTLM
Non sono dettagli cosmetici. Riducono direttamente la probabilità che un percorso non firmato o debolmente protetto diventi un percorso di relay NTLM praticabile. L'igiene delle password e l'igiene di protocollo contano ancora sulla stessa superficie di attacco, ed è per questo che Sicurezza delle Password in Active Directory: errori critici fa parte della stessa revisione.
4. Usare le funzioni di hardening SMB più recenti dove la piattaforma le supporta
Microsoft ora distribuisce default più robusti e protezioni adiacenti nelle release attuali:
- Windows 11 24H2 Enterprise, Pro ed Education richiedono la firma SMB sia in ingresso sia in uscita
- Windows Server 2025 richiede la firma SMB in uscita per impostazione predefinita
- Windows 11 24H2 e Windows Server 2025 aggiungono controlli di audit per la firma SMB
- Windows 11 24H2 e Windows Server 2025 aggiungono il blocco NTLM su SMB lato client
Questo significa che il rimedio non consiste solo nell'attivare una vecchia policy. Sulle piattaforme più recenti puoi usare l'audit e la riduzione di NTLM per rendere l'ambiente più sicuro senza dover indovinare quale dipendenza si romperà.
5. Rivedere separatamente l'accesso guest e le dipendenze NAS legacy
Microsoft afferma che richiedere la firma SMB disabilita anche l'accesso guest alle share. Se la tua attività dipende ancora da un accesso SMB in stile guest, si tratta di un'eccezione di design che va isolata e rivista, non ripiegata silenziosamente nel parco macchine normale.
6. Rivedere la proliferazione di admin locali sugli stessi sistemi
SMB non firmato su workstation e member server è più pericoloso quando gli stessi host condividono anche problemi di credenziali admin locali. Se stai facendo hardening del parco macchine, rivedi Windows LAPS non distribuito: perché le password locali di amministratore condivise restano un rischio sullo stesso insieme di sistemi.
7. Abbinare la firma a revisioni focalizzate sul relay
Se la firma SMB è disabilitata, rivedi anche le finding adiacenti che rendono più facile il relay:
- NTLM Relay: rilevamento e prevenzione
- Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation
- Monitoraggio Sicurezza AD: Event ID e SIEM
Se stai decidendo come operazionalizzare questi controlli sull'intero parco macchine, è rilevante anche Confronto strumento audit AD: come confrontare PingCastle, Purple Knight e workflow di audit ripetibili.
Il controllo è più efficace quando lo tratti come parte di un programma di riduzione del relay, non come un valore isolato nel registro.
Validazione dopo l'hardening
Dopo aver modificato la policy, valida direttamente il risultato.
- esegui
Get-SmbClientConfigurationeGet-SmbServerConfigurationper confermare cheRequireSecuritySignaturesiaTrue - conferma che le impostazioni Group Policy effettive corrispondano alla baseline prevista
- abilita prima gli eventi di audit della firma se ti aspetti problemi di compatibilità con terze parti
- identifica i dispositivi o il software che non supportano la firma prima di imporre il requisito su larga scala
- verifica se esistono ancora vecchi flussi guest o non firmati e se andrebbero ritirati invece che mantenuti
- controlla se sono ancora presenti accessi alle share basati su IP, uso di CNAME o percorsi SMB con uso intenso di NTLM
- includi il controllo nella revisione più ampia descritta in Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation
La vera condizione di successo non è uno screenshot della policy. È che client e server non accettino più SMB non firmato dove l'esposizione al relay conta davvero.
Come EtcSec rileva l'esposizione correlata
EtcSec può modellare questo problema direttamente perché SMB_SIGNING_DISABLED è una finding concreta di hardening di rete, non solo una raccomandazione generica di best practice.
Nella pratica, i collegamenti del catalogo più utili sono:
- le finding dirette
SMB_SIGNING_DISABLEDsui sistemi che permettono ancora SMB non firmato - le finding
NTLM_RELAY_OPPORTUNITYdove restano in essere i prerequisiti del relay - i controlli di monitoraggio e hardening AD circostanti, che spiegano se il problema è isolato o fa parte di un ambiente più ampio favorevole al relay
Per questo motivo, questo tema va letto insieme a NTLM Relay: rilevamento e prevenzione e Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation, non solo con una guida generica sui file server.
Controlli correlati
Se stai rivedendo la firma SMB disabilitata, rivedi anche NTLM Relay: rilevamento e prevenzione, Monitoraggio Sicurezza AD: Event ID e SIEM, Auditare la sicurezza di Active Directory: cosa verificare per prima e come dimostrare la remediation, Sicurezza delle Password in Active Directory: errori critici, Windows LAPS non distribuito: perché le password locali di amministratore condivise restano un rischio, Account Obsoleti e Sovraprivilegiati: Il Rischio Nascosto in Active Directory e Confronto strumento audit AD: come confrontare PingCastle, Purple Knight e workflow di audit ripetibili. Questi articoli coprono i percorsi di coercizione, relay e monitoraggio circostanti che determinano se SMB non firmato è solo un'impostazione debole o un percorso di attacco praticabile.
Riferimenti principali
Esplora le pagine di identity security collegate a questo tema