Tags: Netzwerk, Verschlüsselung
Um zu verhindern, dass Angreifer die über das Netz übertragenen Informationen manipulieren, unterstützt Server Message Block (SMB) die Signierung der Datenpakete. Das soll ihre Authentizität gewährleisten. Die Signierung ist für Domain Controller standardmäßig aktiviert, für File-Server muss man sie per GPO einschalten.
Das in Windows 8 und Server 2012 eingeführte SMB3 brachte mit der eingebauten Verschlüsselung ein zusätzliches Sicherheits-Feature, welches auch ein Ausspähen der übertragenen Daten verhindert. Der Einsatz von SMB Encryption empfiehlt sich besonders, wenn Clients und Server sensible Informationen über ein nicht vertrauenswürdiges Netzwerk austauschen.
Schutz gegen Manipulation von GPOs
Wenn es aber ausreicht, die Integrität der Daten sicherzustellen, dann kann man sich die erforderliche Rechenleistung für eine volle Verschlüsselung sparen und SMB-Signing einsetzen. Eine explizite Kombination beider Techniken ist übrigens nicht sinnvoll, ein verschlüsseltes Paket gilt auch als signiert.
Ein typischer Anwendungsfall für die SMB-Signierung ist die Übertragung der GPOs von DCs an die Clients. Die darin enthaltenen Informationen sind nicht sonderlich geheim, aber sie sollten beim Transfer in keinem Fall verändert werden, etwa im Zuge eines Man in the middle Attacks. Aus diesem Grund aktiviert die Default Domain Controllers Policy die SMB-Signierung.
Neuer Algorithmus in SMB3
Im Vergleich zur Verschlüsselung ist die Konfiguration der Signierung etwas aufwändiger, nicht zuletzt aus historischen Gründen. Dieses Sicherheits-Feature ist bereits seit SMB1 an Bord, aber die Einstellungen in den Gruppenrichtlinien haben sich über die Zeit geändert.
Neu ist übrigens auch der für SMB3 verwendete Algorithmus, Microsoft wechselte von HMAC SHA-256 zu AES-CMAC. Dieses Verfahren soll die Möglichkeiten moderner 64-Bit-Prozessoren besser nutzen und bis zu dreimal weniger CPU-Zyklen verbrauchen.
Konfiguration über Gruppenrichtlinien
Während man die SMB Encryption nur auf dem Server aktivieren muss, sieht die Signierung eine separate Konfiguration von Client und Server vor. Die dafür zuständigen Einstellungen in den Gruppenrichtlinien finden sich unter Computerkonfiguration => Richtlinien => Windows-Einstellungen => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen.
Wie man hier schnell erkennt, existieren für Client und Server je zwei Einstellungen. Ab SMB2, also seit Vista und Server 2008, benötigt man aber auf beiden Seiten nur mehr Kommunikation digital signieren (immer). Die anderen, die das Feature von der Zustimmung der Gegenstelle abhängig machen, sind für SMB1 gedacht, das man aber nach Möglichkeit deinstallieren sollte.
Aushandlung der Kommunikation
Durch die Reduktion der Optionen vereinfacht sich die Aushandlung der Protokollsignierung zwischen Client und Server. Verlangt bei SMB2 oder SMB3 eine der beiden Seiten die Signatur für Pakete, dann wird signiert. Nur wenn keiner der beiden Endpunkte dafür konfiguriert ist, unterbleibt die Signierung.
Standardmäßig ist bei Client und Server das SMB-Signing abgeschaltet, wie man am Wert false von RequireSecuritySignature nach Eingabe dieser Befehle ersehen kann:
Get-SmbClientConfiguration | select RequireSecuritySignature
bzw.
Get-SmbServerConfiguration | select RequireSecuritySignature
Konfiguration über PowerShell
Alternativ zu den Gruppenrichtlinien kann man auch PowerShell nutzen, um die Signierung von SMB-Paketen einzuschalten:
Set-SmbServerConfiguration -RequireSecuritySignature $true
bzw.
Set-SmbClientConfiguration -RequireSecuritySignature $true
Über den Wert $false deaktiviert man sie wieder.
Zu beachten gilt hier generell, dass es bei Client und Server nicht um die Workstation- oder Server-Version von Windows geht. Vielmehr fungiert jeder Windows-Rechner als SMB-Server, wenn er Verzeichnisse freigibt, und ein Windows Server nutzt einen SMB-Client, um auf Shares zuzugreifen. Das Verhalten dieser Komponenten wird jeweils über GPOs oder PowerShell konfiguriert.
