File-Server absichern durch SMB-Signierung

    Signierung von SMB-PaketenUm zu ver­hindern, dass Angreifer die über das Netz über­tragenen Infor­ma­tionen mani­pulieren, unter­stützt Server Message Block (SMB) die Sig­nierung der Daten­pakete. Das soll ihre Authen­tizität gewähr­leisten. Die Sig­nierung ist für Domain Controller standard­mäß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 vertrauens­würdiges Netzwerk austauschen.

    Schutz gegen Manipulation von GPOs

    Wenn es aber ausreicht, die Integrität der Daten sicher­zustellen, dann kann man sich die erforderliche Rechen­leistung für eine volle Verschlüsselung sparen und SMB-Signing einsetzen. Eine explizite Kombination beider Techniken ist übrigens nicht sinnvoll, ein ver­schlüsseltes Paket gilt auch als signiert.

    Die Default Domain Controller Policy aktiviert die SMB-Signierung für DCs.

    Ein typischer Anwendungs­fall für die SMB-Signierung ist die Übertragung der GPOs von DCs an die Clients. Die darin enthaltenen Informa­tionen sind nicht sonder­lich 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 Gruppen­richtlinien 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öglich­keiten 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 Gruppen­richt­linien finden sich unter Computer­konfiguration => Richtlinien => Windows-Einstellungen => Sicherheitseinstellungen => Lokale Richtlinien => Sicherheitsoptionen.

    GPO-Einstellungen zur Konfiguration der SMB-Signierung.

    Wie man hier schnell erkennt, existieren für Client und Server je zwei Ein­stellungen. 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 Gegen­stelle 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 Protokoll­signierung 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.

    Standard­mäß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 Gruppen­richt­linien 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.

    Einstellungen für die SMB-Signierung über PowerShell konfigurieren.

    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 Verzeich­nisse freigibt, und ein Windows Server nutzt einen SMB-Client, um auf Shares zuzugreifen. Das Verhalten dieser Komponenten wird jeweils über GPOs oder PowerShell konfiguriert.

    Keine Kommentare