Ausgangslage: SMBv1 ist selten „wirklich gebraucht“, aber oft noch aktiv

In vielen AD-Umgebungen ist SMBv1 offiziell längst „abgeschaltet“ – und trotzdem findest du es in Randbereichen wieder: alte NAS-/Backup-Appliances, vergessene Serverrollen, Alt-Images, Embedded-Geräte, Scanner, oder schlicht Systeme, die nie sauber modernisiert wurden.

Das Problem ist nicht nur „Legacy“. SMBv1 ist operational toxisch:

  • Schwache Protokollbasis: alte Dialects, wenig Schutzmechanik, schlechte Defaults.
  • Unklare Abhängigkeiten: SMBv1 sitzt oft dort, wo niemand mehr hinschaut.
  • Tier-0-Relevanz: DCs, Admin-Jumphosts, Management-Server – hier willst du keine Legacy-Protokolle dulden.

SMBv1-Hardening ist deshalb kein „One-liner“, sondern ein kontrollierter Rückbau: finden, isolieren, ersetzen, entfernen.

Zielbild: SMBv2/SMBv3 only, Legacy bleibt nur als geplante Ausnahme

Ein sauberes Zielbild ist messbar und auditierbar:

  1. SMBv1 ist auf Clients und Servern deaktiviert (Client- und Server-Komponente).
  2. SMBv1 Feature ist entfernt, wo möglich (Optional Feature/Windows Feature).
  3. Keine produktiven File- oder Admin-Pfade hängen an SMBv1.
  4. Ausnahmen sind segmentiert (eigene VLANs/Firewall-Regeln), mit Owner und Sunset-Date.

Wichtig: „Deaktiviert“ ist besser als „nicht genutzt“, aber „entfernt“ ist besser als „deaktiviert“ – weil es Drift reduziert.

Ist-Stand: erst messen, dann schalten

Wenn du SMBv1 „einfach aus“ machst, bekommst du genau zwei Sorten Feedback: gar keins (weil du Glück hattest) oder Produktionstickets. Der bessere Weg:

1) Technischer Zustand pro System (Client, Server, Feature)

Auf einem Windows-System kannst du die relevanten Zustände pragmatisch so prüfen:

Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Get-SmbClientConfiguration | Select-Object EnableSMB1Protocol, EnableSMB2Protocol
Get-WindowsOptionalFeature -Online | Where-Object FeatureName -like 'SMB1Protocol*' | Select-Object FeatureName, State

Interpretation:

  • EnableSMB1Protocol = True ist ein klares Hardening-Finding.
  • Feature SMB1Protocol* im Zustand Enabled heißt: SMBv1 ist nicht nur „theoretisch“, sondern als Komponente vorhanden.

2) Abhängigkeiten sichtbar machen (die eigentliche Arbeit)

SMBv1-Abhängigkeiten zeigen sich selten in GPOs, sondern im Betrieb:

  • Welche NAS/Appliances sprechen noch SMBv1?
  • Welche Backup-/Archiv-/Scan-Workflows hängen daran?
  • Gibt es noch alte Member Server oder Legacy-VMs, die nie modernisiert wurden?

Praktisch: nutze vorhandene Telemetrie (EDR, Netzwerkmonitoring, Firewall-Logs) um zu identifizieren, wer mit wem SMB spricht und welche „Legacy“-Endpunkte überhaupt noch existieren.

Umsetzung: Rollout in Phasen (Pilot → Breite → Entfernung)

Phase 0: Scope und Rückfall planbar machen

  • Definiere eine Pilot-OU (Workstations + ein paar Server) und einen Rollback-Pfad.
  • Lege fest, welche Systeme Tier 0 sind (DCs, Admin-Endpunkte, Management) – dort gilt: keine Ausnahmen ohne Management-Entscheidung.

Phase 1: SMBv1 auf Domain Controllern und Admin-Endpunkten hart deaktivieren

Für Tier-0-Systeme ist SMBv1 in der Regel sofort abschaltbar. Der pragmatische technische Hebel:

Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Set-SmbClientConfiguration -EnableSMB1Protocol $false

Danach (wo möglich) SMBv1 als Feature entfernen:

Get-WindowsOptionalFeature -Online | Where-Object FeatureName -like 'SMB1Protocol*'
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Hinweis: Feature-Namen können je nach Windows-Version variieren. Prüfe immer zuerst mit Get-WindowsOptionalFeature und deaktiviere dann die tatsächlich vorhandenen SMB1Protocol*-Features.

Phase 2: Breiter Rollout per GPO/Endpoint-Management (idempotent)

In klassischen AD-Projekten ist ein Computer-Startup-Skript (oder Endpoint-Management-Remediation) oft am robustesten:

  • setzt Set-SmbServerConfiguration / Set-SmbClientConfiguration
  • entfernt SMBv1-Features, wenn sie vorhanden sind
  • läuft idempotent und ist über Scope/OU steuerbar

Wichtig: trenne „deaktivieren“ (geringes Risiko) von „Feature entfernen“ (mehr Change, aber sauberer Endzustand). Entfernen rollst du typischerweise nach erfolgreichem Pilot in einer zweiten Welle aus.

Phase 3: Legacy-Endpunkte isolieren statt dauerhaft ausnehmen

Wenn ein Gerät SMBv1 „braucht“, ist das ein Architekturthema, kein Hardening-Detail:

  • Isoliere es in ein Legacy-Segment.
  • Erlaube nur minimale SMB-Kommunikation zu genau definierten Zielen.
  • Plane Ersatz/Upgrade und setze ein Sunset-Datum.

Das ist nicht „nice to have“: Dauerhafte SMBv1-Ausnahmen ohne Segmentierung machen spätere Hardening-Schritte (SMB Signing, Admin-Tiering, File-Server-Härtung) unnötig schwer.

Vorteile (explizit)

  • Weniger Angriffsfläche: SMBv1 verschwindet aus dem Footprint.
  • Weniger Drift: Feature-Removal verhindert „zufällige“ Reaktivierung durch Images oder Rollen.
  • Bessere Standardisierung: SMBv2/3-only reduziert Legacy-Fehlerbilder und macht SMB-Hardening konsistenter.
  • Klarere Ausnahmen: Was SMBv1 nutzt, wird sichtbar und erzwingt eine bewusste Entscheidung.

Nachteile und Grenzen (explizit)

  • Legacy-Geräte können ausfallen: insbesondere alte NAS/Appliances/Scanner ohne Updatepfad.
  • Abhängigkeiten sind oft schlecht dokumentiert: Inventar und Telemetrie kosten Zeit.
  • „SMBv1 aus“ ersetzt keine weiteren Baselines: Signing, Least Privilege auf Shares, Segmentierung und Tiering bleiben separate Baustellen.

Typische Stolperfallen

  • Nur „Server-Seite“ betrachtet: SMBv1 kann auch als Client-Komponente aktiv bleiben.
  • Nur deaktiviert, nicht entfernt: bei neuen Images taucht SMBv1 später wieder auf.
  • File-Services und Backup-Pfade nicht getestet: hier hängen oft Appliances oder agentlose Workflows.
  • Dauerhafte Ausnahmen ohne Segmentierung: führt zu einem Legacy-„Schattennetz“ im Kernnetz.
  • Kein Tiering-Filter: Admin-Endpunkte werden wie normale Clients behandelt, obwohl sie ein anderes Risikoprofil haben.

Projekt-Checkliste

  • [ ] Tier-0-Systeme definiert (DCs, Admin-Endpunkte, Management) und ohne SMBv1-Ausnahmen geplant.
  • [ ] Ist-Stand je Systemklasse erhoben: EnableSMB1Protocol (Client/Server) + SMB1Protocol* Feature-State.
  • [ ] Telemetrie genutzt, um SMBv1-Abhängigkeiten (Geräte/Appliances) zu identifizieren.
  • [ ] Pilot-OU umgesetzt: erst deaktivieren, dann Feature entfernen.
  • [ ] Breiter Rollout: GPO/Endpoint-Management idempotent, inklusive Image- und Template-Bereinigung.
  • [ ] Legacy-Ausnahmen: segmentiert, minimal freigeschaltet, Owner + Sunset-Date dokumentiert.