SMB Signing - Kommunikation digital signieren

Gibt es eine Empfehlung wie man mit dem "SMB Signing" umzugehen hat? Ja. Es ist, ganz einfach: Aus Sicherheitsgründen darf ich die komplette Deaktivierung des SMB Signings nicht empfehlen.

Vorweg und wichtig:
Wenn das SMB Signing falsch konfiguriert ist, dann kann es dazu kommen, daß keine Kommunikation mehr möglich ist. Das kann aber nur dann der Fall sein, wenn es per Hand verstellt wurde. Deswegen gibt es diesen Artikel, denn SMB Signing sollte ich immer per Gruppenrichtlinie domänenweit, also schon auf Domänen-Ebene für alle definieren, damit es nicht zu diesem Fehlern kommen kann.

You cannot open file shares or Group Policy snap-ins when you disable SMB signing for the Workstation or Server service on a domain controller
 
Warum gibt es SMB Signing?

Die Frage ist, warum gibt es überhaupt signierte, als gestempelte/beglaubigte Datenpakete beim Dateitransfer, die bei Microsoft über das SMB Protokoll laufen? Es geht natürlich, wie schon gedacht, um das Thema Sicherheit. Es geht um die klassische Man-in-the-Middle-Attack, in der sich jemand in die Kommunikation einschleicht, die Pakete fängt und zu einem späteren Zeitpunkt wieder einspielt und damit Informationen über das Netzwerk (Computernamen, Gruppen, Benutzer etc. alles was so NetBIOS mässig zu finden ist) bekommt. Beim Thema SMB wurde der Angriff "Reflection Attack" genannt.
Mit der Signatur wird der Versender und die versende Zeit eindeutig in das Paket integriert. Die Sicherheitslücke ist damit geschlossen. Der Angreifer kann die Information nicht simulieren und nachbauen und aufgrund des Zeitstempels wird ein zu einem späteren Zeitpunkt eingespieltes Paket für ungültig erklärt. Das ist das Argument für SMB Signing.

Mein Lieblingsartikel von 2005:
How to Shoot Yourself in the Foot with Security, Part 1

1. [...] a really easy way to shoot yourself in the foot is to disable SMB message signing. SMB message signing does mitigate serious security issues by validating all packets in an SMB exchange. True, you may use Internet Protocol security (IPsec on top of SMB to achieve a similar effect, but unlike SMB message signing, IPsec does not stop attacks. It simply ensures that you only get attacked by people you know. SMB message signing actually stops the attacks. Thus, we highly recommend that you turn on SMB message signing for critical traffic like DC traffic.[...]
    
2. [...] There is a performance overhead associated with message signing. Turning on message signing actually modifies how data is transmitted. This means that the overhead is probably going to be negligible for small transactions like transferring small files. However, for very large file transfers the overhead could get extremely high—up to 40 percent in some situations. Therefore, you need to think about where you turn it on.[...}

Fazit nach diesem Artikel:
Eigentlich nur zwischen DCs aktivieren, für Fileservices nicht zu gebrauchen ...

Todo:

• Erstellt euch eine neu Richtlinie "C_SMB-Signing"
• diese wird auf Domänen-Ebene verlinkt und nach "oben" auf die Verknüpfungsreihenfolge Platz 1 sortiert, damit sie gewinnt
• diese wird auf DomänenControllers-Ebene verlinkt und nach "oben" auf die Verknüpfungsreihenfolge Platz 1 sortiert, damit sie gewinnt

Konfiguration nach Bestpractise, alle Microsoft Rechner reden signiert miteinander, weil sie es können, wenn es jemand nicht kann, ist es augeschaltet.

Argumente gegen SMB Signing und für das Abschalten der Funktion

1. Die kritischsten Probleme, nämlich die Möglichkeit Anmeldeinformationen zu spiegeln wurden von Microsoft 2008/2009 geschlossen. NetBIOS Informationen lassen sich auch einfacher beschaffen, als über unsignierte SMB Pakete. Seit 2009 ist der "Zwang" zur Verwendung relativiert.
   Vulnerability in SMB Could Allow Remote Code Execution (957097)
   falls noch NTLM im Spiel ist:
   Vulnerabilities in Windows HTTP Services Could Allow Remote Code Execution (960803)
   Cumulative Security Update for Internet Explorer (963027)
2. Es kostet massiv Performance! Bei XP/2003 kommt SMB in der Version 1.0 zum Einsatz, es gibt gerade über WAN Strecken massive Performance-Einbrüche, aufgrund der eingeschränkten maximalen Paketgröße von SMB 1.0. Von dem "kleinen" Paket muss jetzt auch noch ein Teil für die Signatur abgeknapst werden. 1 Million 1 Kilobyte große GIF Dateien in einem Webverzeichniss bringen euch jetzt um ... Mit SMB v2 ab Windows Vista wird es stressfreier, spätestens mit Windows 8 und einem Server 2012 mit SMB v3 haben wir mit der Größe der Signatur keine Probleme mehr.
   SMB Maximum Transmit Buffer Size and Performance Tuning
3. Wer hat schon Microsoft File Server? Je größer die Umgebung ist, desto eher finden wir fette Storage System, die seltsamerweise alle mit einem Linux Samba laufen. Samba kann signieren, aber ich glaube nicht, daß sie das per Default machen. Wann fliessen also signierte Pakete durch das Netz? Nur wenn ein Microsoft Client mit einem Microsoft Server spricht und umgekehrt. Also praktisch nur zur Übernahme der Gruppenrichtlinien.
   Wenn also ein hoher 90+x% Anteil sowieso unsigniert ist, wo ist mein Sicherheitsgewinn von SMB Signing?
4. Die Standard Konfiguration von Microsoft wird IMMER! unsignierten Traffic erlauben, da zuviele Geräte diese Technik garnicht beherrschen. Eure Scan-to-UNC Geräte, euer Mac, die alten DOS Clients. Im Umkehrschluss heisst das: Nur wenn der Partner signieren kann, wird signiert. Wenn der Partner es nicht kann, dann eben nicht. Ich behaupte jetzt mal, daß ein Angriff auf euer Netzwerk als Man-in-the-Middle nicht von einem Windows Client aus stattfindet. Dieser Client selber wird unsignierten Traffic senden und empfangen und "irgendwer" im Netzwerk macht das auch, z.B.: euer Storage und die Jungs in der Design Abteilung mit ihren Äpfeln.

Konfiguration zum Abschalten, Verlinkung der Richtlinien erstellen wie schon oben: