Exiger la signature SMB et désactiver SMBv1 partout

Le relais SMB est le relais NTLM classique : un attaquant capture une tentative d'authentification, souvent via un empoisonnement LLMNR ou une coercition d'authentification, et la rejoue vers un serveur qui accepte le SMB non signé. Si l'identité relayée est administrateur local de la cible, l'attaquant obtient une exécution de code à distance. Exiger la signature SMB fait échouer la session relayée, car l'attaquant ne possède pas la clé de session nécessaire pour signer. SMBv1, de son côté, est le protocole derrière EternalBlue et WannaCry et n'a rien à faire sur un réseau moderne.

Le pilier NTLM et protocoles hérités donne les deux paramètres de signature. Ce guide couvre le déploiement complet : les quatre paramètres de stratégie et ce que chacun fait réellement, ce que Windows 11 24H2 et Windows Server 2025 changent par défaut, comment trouver les équipements qui vont casser, et comment auditer puis supprimer SMBv1.

Les quatre paramètres, et ceux qui comptent

Les quatre se trouvent sous :

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options

Les chemins de registre se trouvent sous HKLM\SYSTEM\CurrentControlSet\Services\. Avec SMB 2 et 3, seuls les paramètres « always » modifient le comportement : la signature est utilisée dès que l'un des deux côtés l'exige. Cela signifie aussi qu'exiger la signature côté serveur protège ce serveur contre le relais quelle que soit la configuration des clients, tandis que l'exiger côté client protège le client contre des serveurs malveillants ou rétrogradés.

Valeurs par défaut selon la version

• Les contrôleurs de domaine exigent depuis longtemps la signature côté serveur via la Default Domain Controllers Policy. Vérifiez que personne ne l'a affaiblie.
• Windows 11 24H2 exige par défaut la signature SMB pour les connexions sortantes et entrantes.
• Windows Server 2025 exige par défaut la signature pour les connexions sortantes (client). La signature entrante n'est exigée par défaut que sur les contrôleurs de domaine : les serveurs de fichiers membres ont donc toujours besoin de la stratégie.
• Les versions plus anciennes (Windows 10, Windows 11 avant 24H2, Windows Server 2022 et antérieurs) ne l'exigent que là où une stratégie le prévoit.

Les machines mises à niveau suivent la stratégie si elle est définie. Si votre GPO règle explicitement « always » sur Disabled — ce que faisaient certaines anciennes bases de référence pour « corriger » les performances —, elle prend le pas sur la nouvelle valeur par défaut. Recherchez ce cas avant de supposer que 24H2 a réglé quoi que ce soit.

Signature, chiffrement et performances

La signature ajoute un code d'authentification de message à chaque paquet SMB, dérivé de la clé de session établie lors de l'authentification. Un attaquant qui relaie ne connaît jamais cette clé : c'est pourquoi une session relayée meurt dès que la signature est exigée. L'algorithme dépend du dialecte négocié :

AES-GMAC et AES-CMAC profitent de l'accélération matérielle AES-NI : le surcoût sur les serveurs modernes est donc bien inférieur aux avertissements du type « la signature divise le débit par deux » rédigés à l'époque de SMB 1 et 2. Le coût restant est la charge processeur sur le serveur de fichiers, surtout visible sur les hôtes qui servent de gros transferts séquentiels à de nombreux clients simultanément : points de distribution logicielle, serveurs de profils et cibles de sauvegarde.

Le chiffrement SMB (Set-SmbShare -EncryptData $true ou Set-SmbServerConfiguration -EncryptData $true) assure aussi l'intégrité : une session chiffrée n'a donc pas besoin d'une signature distincte. Il protège également les données en transit, mais il exige SMB 3.x des deux côtés, ce qui exclut les anciens clients et de nombreuses appliances. La base pragmatique est la suivante : signature exigée partout, chiffrement ajouté pour les partages qui contiennent des données sensibles ou sont accessibles via des liaisons non fiables.

La signature ne corrige pas le problème de fond, à savoir que l'authentification NTLM peut être capturée. Elle supprime SMB en tant que cible de relais, c'est-à-dire l'étape qui transforme une authentification capturée en exécution de code.

Mesurer : trouver ce qui ne sait pas signer

Sur les clients Windows, Get-SmbConnection indique si chaque session active est signée. Exécutez-le sur un échantillon de postes de travail et de serveurs pour voir quels serveurs de fichiers, NAS et appliances sont atteints sans signature aujourd'hui.

# Sur un client : sessions SMB en cours et leur protection
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted, UserName

# Sur plusieurs machines
$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 -Unique

Côté serveur, inventoriez le réglage actuel sur chaque serveur 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 -NoTypeInformation

Les cibles non Windows nécessitent une vérification séparée. Les serveurs Samba se configurent avec server signing = mandatory dans smb.conf ; de nombreux fabricants de NAS l'exposent sous le nom « SMB signing » ou « strict signing » dans leur console d'administration. Vérifiez aussi les imprimantes et scanners qui font du « scan vers dossier » : ce sont des clients SMB, et certains anciens firmwares ne savent pas signer.

Auditer et supprimer SMBv1

SMBv1 n'est plus installé par défaut depuis Windows 10 1709 et Windows Server 2019, mais les systèmes mis à niveau et les serveurs plus anciens l'ont souvent encore. Avant de le retirer des serveurs de fichiers, auditez qui l'utilise :

# Sur chaque serveur de fichiers : journaliser les tentatives d'accès SMB1
Set-SmbServerConfiguration -AuditSmb1Access $true -Force

# Après quelques semaines, lire qui s'est connecté en SMB1
Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -FilterXPath '*[System[EventID=3000]]' -MaxEvents 500 |
    Select-Object TimeCreated, Message

L'événement 3000 enregistre l'adresse cliente de chaque connexion SMB1. Les sources typiques sont les vieux copieurs, les équipements Linux embarqués avec un Samba obsolète, les équipements médicaux ou industriels hérités, et des systèmes Windows XP ou Server 2003 qui ne devraient plus exister.

Puis supprimez-le :

# Serveurs et clients : désactiver le composant serveur SMB1
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# Supprimer entièrement la fonctionnalité (redémarrage requis)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Sur Windows Server, vous pouvez aussi utiliser Uninstall-WindowsFeature FS-SMB1. Pour un contrôle à l'échelle du parc, l'ADMX MS Security Guide fourni avec les bases de référence de sécurité Microsoft ajoute les paramètres « Configure SMB v1 server » et « Configure SMB v1 client driver » ; voir déployer les bases de référence de sécurité Microsoft.

Imposer : ordre de déploiement

1. Contrôleurs de domaine. Vérifiez que les paramètres « always » serveur et client sont sur Enabled. Les DC sont la cible de relais la plus précieuse et signent déjà dans la plupart des domaines.
2. Serveurs Tier 0 et d'administration : AD CS, sauvegarde, SCCM/MECM, gestion des hyperviseurs. Relayer vers ces systèmes donne des droits d'administration sur des systèmes critiques ; voir identifier les actifs Tier 0.
3. Tous les serveurs membres, côté serveur d'abord. Cela supprime le relais SMB comme technique de mouvement latéral contre eux.
4. Postes de travail, côté serveur (les postes partagent ADMIN$ et C$, et le relais vers eux est courant) et côté client.
5. Côté client sur les serveurs, une fois que vous savez que chaque destination SMB qu'ils utilisent sait signer.

Utilisez une GPO par anneau de déploiement, liée aux UO concernées, afin de pouvoir revenir en arrière sur un anneau sans toucher aux autres. Les modifications s'appliquent aux nouvelles sessions SMB ; les sessions existantes continuent jusqu'à leur déconnexion : un redémarrage ou une fermeture de session rend donc les tests déterministes.

Vérifier

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-Table

La sortie doit être vide. Relancez l'échantillonnage Get-SmbConnection : aucune session ne doit être à la fois non signée et non chiffrée. De nombreux scanners internes, ainsi que les contrôles de relais d'outils comme PingCastle et NetExec utilisés par votre red team, listent les hôtes qui n'exigent pas la signature ; cette liste doit tomber à zéro ou à un ensemble d'exceptions documentées.

Ce qui casse

• Les NAS et serveurs Samba qui ne prennent pas en charge ou n'exigent pas la signature ne continuent de fonctionner que si le côté client Windows ne l'exige pas. Dès que vous exigez la signature côté client, ces partages échouent avec « le nom réseau spécifié n'est plus disponible » ou une erreur similaire, jusqu'à ce que la signature soit activée sur l'équipement.
• L'accès SMB invité et anonyme ne fonctionne pas avec la signature, car une session invité n'a pas de clé pour signer. Windows 11 24H2 bloque déjà le repli en mode invité ; des NAS d'entrée de gamme et certaines configurations de « scan vers dossier » en dépendaient.
• Les imprimantes multifonctions qui numérisent vers des partages SMB avec un ancien firmware peuvent ne plus se connecter lorsque le serveur exige la signature. Mettez à jour le firmware ou déplacez les destinations de numérisation vers un partage dédié sur un serveur couvert par un plan d'exception.
• Les équipements limités à SMBv1 cessent complètement de fonctionner une fois SMBv1 supprimé : vieux copieurs, contrôleurs embarqués, systèmes médicaux et industriels hérités. Isolez ceux qui ne peuvent pas être remplacés sur un segment réseau séparé, avec un dépôt de fichiers dédié hors domaine.
• Les serveurs de fichiers à haut débit sur du matériel ancien peuvent afficher des débits plus faibles avec la signature exigée. Mesurez avant et après ; envisagez le chiffrement SMB en 3.1.1 comme alternative pour des partages précis.

Pour aller plus loin : le thème NTLM & protocoles hérités, l'entrée de glossaire Signature SMB, désactiver LLMNR, NBT-NS et WPAD pour supprimer la source la plus courante d'authentifications relayables, et restreindre NTLM pour la solution à long terme : supprimer NTLM lui-même.