SMB-Signierung erzwingen und SMBv1 domänenweit abschalten
SMB-Signierung auf Clients und Servern erzwingen, Standards von Windows 11 24H2 und Server 2025 kennen, SMBv1-Nutzung auditieren und es ohne Zugriffsausfälle entfernen.
SMB-Relay ist das klassische NTLM-Relay: Ein Angreifer fängt einen Authentifizierungsversuch ab, häufig durch LLMNR poisoning oder Authentifizierungserzwingung, und gibt ihn an einen Server weiter, der unsigniertes SMB akzeptiert. Ist die weitergeleitete Identität lokaler Administrator auf dem Ziel, erhält der Angreifer Remotecodeausführung. Ist SMB-Signierung erforderlich, scheitert die weitergeleitete Sitzung, weil dem Angreifer der zum Signieren nötige Sitzungsschlüssel fehlt. SMBv1 wiederum ist das Protokoll hinter EternalBlue und WannaCry und hat in einem modernen Netzwerk nichts verloren.
Der Leitfaden zu NTLM und Legacy-Protokollen nennt die beiden Signierungseinstellungen. Dieser Leitfaden behandelt die vollständige Einführung: die vier Richtlinieneinstellungen und was jede tatsächlich bewirkt, was Windows 11 24H2 und Windows Server 2025 standardmäßig ändern, wie Sie die Geräte finden, die ausfallen werden, und wie Sie SMBv1 auditieren und entfernen.
Die vier Einstellungen und welche davon zählen
Alle vier befinden sich unter:
Computer Configuration > Policies > Windows Settings > Security Settings >
Local Policies > Security Options| Richtlinie | Registrierung (DWORD) | Wirkung |
|---|---|---|
| Microsoft network server: Digitally sign communications (always) | LanmanServer\Parameters\RequireSecuritySignature = 1 | Server lehnt unsignierte Sitzungen ab |
| Microsoft network server: Digitally sign communications (if client agrees) | LanmanServer\Parameters\EnableSecuritySignature = 1 | Nur SMB1: signiert, wenn der Client es verlangt |
| Microsoft network client: Digitally sign communications (always) | LanmanWorkstation\Parameters\RequireSecuritySignature = 1 | Client lehnt unsignierte Sitzungen ab |
| Microsoft network client: Digitally sign communications (if server agrees) | LanmanWorkstation\Parameters\EnableSecuritySignature = 1 | Nur SMB1: signiert, wenn der Server es verlangt |
Die Registrierungspfade liegen unter HKLM\SYSTEM\CurrentControlSet\Services\. Bei SMB 2 und 3 ändern nur die „always“-Einstellungen das Verhalten: Signiert wird, sobald eine der beiden Seiten es verlangt. Das bedeutet auch: Die Signierungspflicht auf dem Server schützt diesen Server unabhängig von der Client-Konfiguration vor Relay, während die Pflicht auf dem Client den Client vor bösartigen oder herabgestuften Servern schützt.
Standardwerte nach Version
- Domänencontroller verlangen die serverseitige Signierung seit Langem über die Default Domain Controllers Policy. Prüfen Sie, dass niemand sie abgeschwächt hat.
- Windows 11 24H2 verlangt SMB-Signierung standardmäßig für ausgehende und eingehende Verbindungen.
- Windows Server 2025 verlangt die Signierung standardmäßig für ausgehende (Client-)Verbindungen. Eingehende Signierung ist standardmäßig nur auf Domänencontrollern erforderlich, Mitglieds-Dateiserver benötigen also weiterhin die Richtlinie.
- Ältere Versionen (Windows 10, Windows 11 vor 24H2, Windows Server 2022 und früher) verlangen sie nur, wo eine Richtlinie es vorschreibt.
Aktualisierte Rechner folgen einer gesetzten Richtlinie. Setzt Ihre GPO „always“ explizit auf Disabled — was manche alte Baselines taten, um die Leistung zu „verbessern“ —, überschreibt das den neuen Standard. Suchen Sie danach, bevor Sie annehmen, 24H2 habe irgendetwas behoben.
Signierung, Verschlüsselung und Leistung
Die Signierung versieht jedes SMB-Paket mit einem Nachrichtenauthentifizierungscode, der aus dem bei der Authentifizierung ausgehandelten Sitzungsschlüssel abgeleitet wird. Ein Relay-Angreifer erfährt diesen Schlüssel nie — deshalb stirbt eine weitergeleitete Sitzung, sobald Signierung erforderlich ist. Der Algorithmus hängt vom ausgehandelten Dialekt ab:
| Dialekt | Signierungsalgorithmus |
|---|---|
| SMB 2.0.2 / 2.1 | HMAC-SHA256 |
| SMB 3.0 / 3.0.2 / 3.1.1 | AES-CMAC |
| SMB 3.1.1 unter Windows 11 und ab Windows Server 2022 | AES-GMAC, wenn beide Seiten es unterstützen |
AES-GMAC und AES-CMAC profitieren von der AES-NI-Hardwarebeschleunigung, daher ist der Overhead auf modernen Servern weit geringer, als es die Warnungen aus der SMB-1- und SMB-2-Ära („Signierung halbiert den Durchsatz“) nahelegen. Was bleibt, ist CPU-Last auf dem Dateiserver, am deutlichsten auf Hosts, die große sequenzielle Übertragungen an viele Clients gleichzeitig liefern, etwa Softwareverteilungspunkte, Profilserver und Backup-Ziele.
SMB-Verschlüsselung (Set-SmbShare -EncryptData $true oder Set-SmbServerConfiguration -EncryptData $true) stellt ebenfalls die Integrität sicher, sodass eine verschlüsselte Sitzung keine separate Signierung benötigt. Sie schützt zudem die Daten während der Übertragung, erfordert aber SMB 3.x auf beiden Seiten, was ältere Clients und viele Appliances ausschließt. Die praxistaugliche Baseline lautet: Signierung überall erforderlich, Verschlüsselung zusätzlich für Freigaben mit sensiblen Daten oder Zugriffen über nicht vertrauenswürdige Verbindungen.
Die Signierung behebt nicht das grundlegende Problem, dass NTLM-Authentifizierungen überhaupt abgefangen werden können. Sie entfernt SMB als Relay-Ziel — also den Teil, der aus einer abgefangenen Authentifizierung Codeausführung macht.
Messen: finden, was nicht signieren kann
Auf Windows-Clients zeigt Get-SmbConnection, ob jede aktive Sitzung signiert ist. Führen Sie es auf einer Stichprobe von Arbeitsstationen und Servern aus, um zu sehen, welche Dateiserver, NAS-Geräte und Appliances heute ohne Signierung erreicht werden.
# Auf einem Client: aktuelle SMB-Sitzungen und ihr Schutz
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted, UserName
# Über mehrere Rechner hinweg
$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 -UniqueFür die Serverseite inventarisieren Sie die aktuelle Einstellung auf jedem Windows-Server:
$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 -NoTypeInformationZiele außerhalb von Windows erfordern eine eigene Prüfung. Samba-Server werden mit server signing = mandatory in smb.conf konfiguriert; viele NAS-Hersteller bieten die Option als „SMB signing“ oder „strict signing“ in ihrer Verwaltungskonsole an. Prüfen Sie auch Drucker und Scanner mit „Scan to Folder“: Sie sind SMB-Clients, und manche alte Firmware kann nicht signieren.
SMBv1 auditieren und entfernen
SMBv1 wird seit Windows 10 1709 und Windows Server 2019 nicht mehr standardmäßig installiert, doch aktualisierte Systeme und ältere Server haben es oft noch. Bevor Sie es von Dateiservern entfernen, auditieren Sie, wer es nutzt:
# Auf jedem Dateiserver: SMB1-Zugriffsversuche protokollieren
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
# Nach einigen Wochen auslesen, wer sich per SMB1 verbunden hat
Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -FilterXPath '*[System[EventID=3000]]' -MaxEvents 500 |
Select-Object TimeCreated, MessageEreignis 3000 zeichnet die Client-Adresse jeder SMB1-Verbindung auf. Typische Quellen sind alte Kopierer, Embedded-Linux-Geräte mit veraltetem Samba, ältere Medizin- oder Industrieanlagen sowie Windows-XP- oder Server-2003-Systeme, die es eigentlich nicht mehr geben sollte.
Dann entfernen Sie es:
# Server und Clients: die SMB1-Serverkomponente deaktivieren
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
# Das Feature vollständig entfernen (Neustart erforderlich)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestartUnter Windows Server können Sie auch Uninstall-WindowsFeature FS-SMB1 verwenden. Für die flottenweite Steuerung fügt die MS Security Guide ADMX aus den Microsoft-Sicherheitsbaselines die Einstellungen „Configure SMB v1 server“ und „Configure SMB v1 client driver“ hinzu; siehe Microsoft-Sicherheitsbaselines bereitstellen.
Erzwingen: Reihenfolge des Rollouts
- Domänencontroller. Bestätigen Sie, dass „always“ auf Server- und Clientseite auf Enabled steht. DCs sind das wertvollste Relay-Ziel und signieren in den meisten Domänen bereits.
- Tier-0- und Verwaltungsserver: AD CS, Backup, SCCM/MECM, Hypervisor-Verwaltung. Ein Relay auf diese Systeme verschafft Administratorrechte auf kritischen Systemen; siehe Tier-0-Assets identifizieren.
- Alle Mitgliedsserver, zuerst serverseitig. Damit fällt SMB-Relay als Technik für Lateral Movement gegen sie weg.
- Arbeitsstationen, serverseitig (Arbeitsstationen stellen
ADMIN$undC$bereit, und Relay auf sie ist verbreitet) und clientseitig. - Clientseitig auf Servern, sobald feststeht, dass jedes von ihnen genutzte SMB-Ziel signieren kann.
Verwenden Sie pro Ring eine GPO, verknüpft mit den jeweiligen OUs, damit Sie einen Ring zurückrollen können, ohne die anderen anzufassen. Änderungen gelten für neue SMB-Sitzungen; bestehende laufen weiter, bis sie getrennt werden — ein Neustart oder eine Abmeldung macht Tests daher reproduzierbar.
Überprüfen
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-TableDie Ausgabe sollte leer sein. Führen Sie die Get-SmbConnection-Stichprobe erneut aus: Keine Sitzung sollte unsigniert und unverschlüsselt sein. Viele interne Scanner sowie die Relay-Prüfungen in Werkzeugen wie PingCastle und NetExec, die Ihr Red Team verwendet, listen Hosts auf, die keine Signierung verlangen; diese Liste sollte auf null oder auf eine dokumentierte Ausnahmeliste schrumpfen.
Was dabei ausfallen kann
- NAS- und Samba-Server, die Signierung nicht unterstützen oder verlangen, funktionieren nur weiter, solange die Windows-Clientseite sie nicht verlangt. Sobald Sie die Client-Signierung erzwingen, schlagen diese Freigaben mit „Der angegebene Netzwerkname ist nicht mehr verfügbar“ oder ähnlichen Fehlern fehl, bis die Signierung auf dem Gerät aktiviert ist.
- Gast- und anonymer SMB-Zugriff funktioniert mit Signierung nicht, weil eine Gastsitzung keinen Schlüssel zum Signieren hat. Windows 11 24H2 blockiert den Gast-Fallback bereits; günstige NAS-Geräte und manche „Scan to Folder“-Konfigurationen waren darauf angewiesen.
- Multifunktionsdrucker, die auf SMB-Freigaben scannen, können mit alter Firmware keine Verbindung mehr herstellen, wenn der Server Signierung verlangt. Aktualisieren Sie die Firmware oder verlegen Sie die Scan-Ziele auf eine dedizierte Freigabe auf einem Server mit Ausnahmeplan.
- Geräte, die nur SMBv1 beherrschen, funktionieren nach dem Entfernen von SMBv1 überhaupt nicht mehr: alte Kopierer, Embedded-Controller, ältere Medizin- und Industriesysteme. Isolieren Sie nicht ersetzbare Geräte in einem separaten Netzwerksegment mit einer dedizierten Dateiablage außerhalb der Domäne.
- Dateiserver mit hohem Durchsatz auf älterer Hardware können mit erforderlicher Signierung geringere Übertragungsraten zeigen. Messen Sie vorher und nachher; erwägen Sie SMB-Verschlüsselung über 3.1.1 als Alternative für bestimmte Freigaben.
Weiterführend: das Thema NTLM & Legacy-Protokolle, der Glossareintrag SMB-Signierung, LLMNR, NBT-NS und WPAD deaktivieren, um die häufigste Quelle weiterleitbarer Authentifizierungen zu beseitigen, sowie NTLM einschränken als langfristige Lösung, bei der NTLM selbst entfernt wird.
Häufige Fragen
Brauche ich sowohl die „always“- als auch die „if client agrees“/„if server agrees“-Einstellungen?
Entscheidend sind die „always“-Einstellungen: Sie machen die Signierung verpflichtend. Die Einstellungen „if client agrees“ und „if server agrees“ aktivieren die Signierung nur, wenn beide Seiten dazu bereit sind, und werden von SMB2 und höher ignoriert, wo die Signierfähigkeit immer vorhanden ist. Setzen Sie „always“ auf Client- und Serverseite auf Enabled und lassen Sie die „if agrees“-Einstellungen für SMB1-Sonderfälle aktiviert.
Ersetzt SMB-Verschlüsselung die Signierung?
Wird eine Sitzung oder Freigabe mit SMB 3.x verschlüsselt, stellt die Verschlüsselung auch die Integrität sicher, sodass zusätzlich keine Signierung angewendet wird. Verschlüsselung ist nur ab SMB 3.0 verfügbar und wird meist pro Freigabe oder pro Server aktiviert. Die Signierung bleibt die domänenweite Baseline, weil sie jede SMB-2- und SMB-3-Sitzung schützt, auch zu nicht verschlüsselten Freigaben.
Wie viel Leistung kostet SMB-Signierung?
Auf moderner Hardware mit SMB 3.x meist wenig, da die Signierung AES-CMAC oder, unter Windows 11 und ab Windows Server 2022, AES-GMAC mit CPU-Beschleunigung nutzt. Spürbar wird der Aufwand auf Dateiservern mit sehr hohem Durchsatz, älteren CPUs und SMB-2.x-Sitzungen, die auf HMAC-SHA256 zurückfallen. Messen Sie auf Ihrem meistgenutzten Dateiserver vorher und nachher, statt Annahmen zu treffen.
SMB-Signierung erzwingen und SMBv1 domänenweit abschalten