Dans le cadre du durcissement (hardening) d’une infrastructure On-Premise, la désactivation des protocoles obsolètes ne suffit pas. Il faut également sécuriser les protocoles légitimes actifs. Parmi les failles les plus exploitées par les attaquants en environnement Active Directory, on retrouve les attaques par rebond de type SMB Relay.
La réponse technique à cette vulnérabilité est connue : l'activation obligatoire du SMB Signing (la signature numérique des paquets SMB). Cependant, déployer cette configuration à l'aveugle via une GPO globale sur l'ensemble d'un parc informatique est le meilleur moyen de paralyser une production. Les vieux systèmes industriels, les imprimantes multifonctions (scans to file) ou les anciens contrôleurs de stockage (NAS/Samba legacy) risquent de ne plus pouvoir communiquer.
Voici un guide d'ingénierie complet pour auditer, valider et déployer la signature SMB de manière totalement sécurisée.
1. Deep Dive : Comment fonctionne la signature SMB et pourquoi est-elle vitale ?
Le protocole Server Message Block (SMB) sert à l'échange de fichiers et à la communication inter-processus (RPC) au sein du réseau. Par défaut, si la signature n'est pas exigée, les communications se font en texte clair ou du moins sans vérification d'intégrité de la session.
Une attaque SMB Relay se déroule ainsi :
-
Un attaquant se positionne sur le réseau (via un outil comme Responder) et intercepte une tentative d'authentification NTLM d'un utilisateur (ou d'un compte machine).
-
Au lieu de déchiffrer le hash, l'attaquant retransmet (relay) ce challenge d'authentification vers un autre serveur du réseau (par exemple, un contrôleur de domaine ou un serveur de fichiers critique).
-
Si la victime dispose de droits d'administration sur la cible, l'attaquant obtient instantanément un accès administrateur sans même connaître le mot de passe.
Lorsque le SMB Signing est configuré sur "Required" (Requis), chaque paquet SMB échangé contient une signature cryptographique unique basée sur la clé de session. Si un attaquant tente d'intercepter et de relayer la session, la signature devient invalide, et le serveur cible rejette immédiatement la connexion.
La matrice de négociation (SMBv2 / SMBv3)
La configuration de la signature dépend de deux variables, côté Client et côté Serveur :
-
Enabled (Activé/Optionnel) : La machine accepte de signer si l'autre partie le demande.
-
Required (Obligatoire) : La machine refuse catégoriquement toute communication non signée.
Si un client exige la signature (Required) mais que le serveur cible refuse ou ne sait pas la gérer (Disabled), la connexion réseau échoue. C'est précisément ce comportement qu'il faut anticiper grâce à un audit.
2. Phase critique : L'audit du parc informatique
Avant de modifier vos stratégies de groupe, vous devez cartographier l'état actuel de votre parc. L'objectif est d'identifier les machines configurées de manière non homogène et de lister les serveurs ou équipements tiers incapables de supporter le chiffrement/signature.
Le Script PowerShell de masse : Audit de la configuration SMB Signing
Ce script interroge une liste de machines (serveurs ou postes) via les instances CIM/WMI ou directement via le Registre pour extraire la configuration exacte des composants LanmanServer (le rôle serveur de la machine) et LanmanWorkstation (le rôle client).
<#
.SYNOPSIS
Audit de la configuration SMB Signing sur un parc de machines Windows.
.DESCRIPTION
Ce script vérifie l'état des clés de registre LanmanServer et LanmanWorkstation
pour déterminer si la signature SMB est Activée (Enabled) ou Requise (Required).
#>
# Liste des machines à auditer (Peut être alimentée par Get-ADComputer)
$Computers = @("DC01", "SRV-FILE01", "SRV-APP01", "WKST-01")
# Pour tout le domaine : $Computers = (Get-ADComputer -Filter *).Name
$Report = @()
foreach ($Computer in $Computers) {
Write-Host "Vérification de la machine : $Computer..." -ForegroundColor Cyan
if (Test-Connection -ComputerName $Computer -Count 1 -Quiet) {
try {
# Chemins des clés de registre SMB
$PathServer = "SYSTEM\CurrentControlSet\Services\LanManServer\Parameters"
$PathClient = "SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters"
# Connexion au registre distant via CIM (plus sécurisé et moderne que WMI)
$Reg = [WMIClass]"\\$Computer\root\default:StdRegProv"
# Lecture des valeurs pour le rôle Serveur (LanManServer)
$ServerEnabled = $Reg.GetDWORDValue(2147483650, $PathServer, "EnableSecuritySignature").uValue
$ServerRequired = $Reg.GetDWORDValue(2147483650, $PathServer, "RequireSecuritySignature").uValue
# Lecture des valeurs pour le rôle Client (LanManWorkstation)
$ClientEnabled = $Reg.GetDWORDValue(2147483650, $PathClient, "EnableSecuritySignature").uValue
$ClientRequired = $Reg.GetDWORDValue(2147483650, $PathClient, "RequireSecuritySignature").uValue
$Report += [PSCustomObject]@{
Machine = $Computer
Statut = "En ligne"
Server_Enabled = if($ServerEnabled -eq 1) { "Oui" } else { "Non" }
Server_Required = if($ServerRequired -eq 1) { "Oui (Sécurisé)" } else { "Non (Vulnérable)" }
Client_Enabled = if($ClientEnabled -eq 1) { "Oui" } else { "Non" }
Client_Required = if($ClientRequired -eq 1) { "Oui (Sécurisé)" } else { "Non (Vulnérable)" }
}
}
catch {
$Report += [PSCustomObject]@{
Machine = $Computer
Statut = "Erreur de lecture Registre/CIM"
Server_Enabled = "Inconnu"
Server_Required = "Inconnu"
Client_Enabled = "Inconnu"
Client_Required = "Inconnu"
}
}
} else {
$Report += [PSCustomObject]@{
Machine = $Computer
Statut = "Hors ligne / Inaccessible"
Server_Enabled = "N/A"
Server_Required = "N/A"
Client_Enabled = "N/A"
Client_Required = "N/A"
}
}
}
# Affichage du rapport final sous forme de tableau
$Report | Out-GridView -Title "Rapport d'audit SMB Signing"
# Optionnel : Exporter en CSV pour analyse
# $Report | Export-Csv -Path "C:\Temp\Audit_SMBSigning.csv" -NoTypeInformation -Encoding UTF8
3. Stratégie de déploiement par GPO
Une fois l'audit réalisé et les exceptions traitées (par exemple, en isolant les vieux NAS dans des VLAN spécifiques ou en mettant à jour leur firmware pour supporter au moins SMBv2 avec signature), vous pouvez passer à l'application par stratégie de groupe.
Microsoft recommande d'appliquer la configuration dans l'ordre suivant :
-
Chemin de la GPO pour le rôle Serveur :
Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité-
Serveur réseau Microsoft : signer numériquement les communications (toujours) : Définir sur Activé (équivaut à Required).
-
Serveur réseau Microsoft : signer numériquement les communications (si le client l'accepte) : Définir sur Activé (équivaut à Enabled).
-
-
Chemin de la GPO pour le rôle Client : Dans le même nœud d'options de sécurité :
-
Client réseau Microsoft : signer numériquement les communications (toujours) : Définir sur Activé.
-
Client réseau Microsoft : signer numériquement les communications (si le serveur l'accepte) : Définir sur Activé.
-
Note: Depuis les versions récentes de Windows Server, les Contrôleurs de Domaine ont l'option "Serveur réseau Microsoft : signer numériquement les communications (toujours)" activée par défaut pour protéger SYSVOL et NETLOGON.
4. Références officielles Microsoft
Pour valider vos changements d'infrastructure et garantir la conformité avec les recommandations de l'éditeur :
Conclusion
Le SMB Signing n'est pas une option superflue, c'est un rempart indispensable contre le vol d'identités sur votre réseau local. En prenant le temps de cartographier votre infrastructure à l'aide de notre script d'audit, vous éliminez le risque de coupure de production tout en élevant drastiquement le niveau de sécurité de votre Active Directory.
