[English]Noch ein kurzer Hinweis für Administratoren im Firmenumfeld. Microsoft ermöglicht eine SMB-Signierung beim betreffenden Netzwerkprotokoll. Damit soll die Sicherheit der Kommunikation gewährleistet werden. Allerdings ist das Ganze wohl etwas komplex, wenn ich dies richtig interpretiere. Nun gibt es einen Techcommunity-Beitrag, wo man von Microsoft das Thema aufgreift und die vertrauenswürdige Konfigurierung einer SMB-Signierung behandelt.
Anzeige
Ned Pyle hat bereits Anfang August 2021 den Beitrag Configure SMB Signing with Confidence in der Techcommunity veröffentlicht. Ich hatte es über nachfolgenden Tweet von Lawrence Abrams mitbekommen, der das Ganze als mögliche Reaktion auf die kürzlich bekannt gewordene PetitPotam-Schwachstelle vermutet.
Die Administratoren, die es betrifft, haben es möglicherweise mitbekommen. Andernfalls einfach mal den Beitrag von Pyle lesen. Bereits die Einleitung ist eine Offenbarung:
Hallo Leute, hier ist wieder Ned. Vor vielen Jahren haben wir [bei Microsoft] die Konfiguration der SMB-Signierung in Windows ziemlich kompliziert gemacht. Dann, Jahre später, haben wir, in dem Versuch, weniger kompliziert zu sein, es noch komplizierter gemacht. Heute bin ich hier, um die SMB-Signierungsregeln ein für alle Mal zu erklären. Wahrscheinlich …
Ähnliche Artikel:
PetitPotam-Angriff erlaubt Windows Domain-Übernahme
Microsofts Workaround gegen Windows PetitPotam NTLM-Relay-Angriffe
PetitPotam-Angriffe auf Windows durch RPC-Filter blocken
Windows 365: Anmeldedaten im Klartext abgreifbar
2015
Seid vorsichtig mit S2D Cluster, Signierung blind anschalten zerschiesst ihr euch alle VMs.
du meinst glaube ich encryption und nicht signing oder?
@Stoner: Vielen Dank für den Hinweis!
@Michael: Nein, sowohl als auch, siehe https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/reduced-performance-after-smb-encryption-signing
Aber hey, immerhin mit Windows Server 2022 wird alles wieder gut! 🤪
@michael nein ich meine signing.
wir haben im guten glauben das kurzerhand umgesetzt weil es bemängelt wurde bei einem PenTest.
Die Auswirkung war so heftig das unseren S2D so zerschossen hat das alle VMs (97 Server) direkt abgestürzt sind und schlimmste dabei wo angemeldet User waren die kompletten Profile zerhämmert hat. Also wenn jemand das vorhat plant das gut und bedenkt alles mit. Wir haben es wieder auf deaktiviert gelassen.
Server 2019 mit S2D Cluster Hyper-V alles von DELL zertifiziert und mit eingerichtet.
Ich kenne den Artikel und die Warnung was Performance angeht, dass es da aber etwas zerschießen soll… ich kenne euer Setup nicht, aber bei mir läuft's mit Signing super, kann nicht klagen bei ca. 15 Gb/s für Datatraffic mit SMB 3 und RDMA. Verwende aber auch eine exklusive Direktverbindung zwischen den nodes, also da ist nicht Mal ein Switch dazwischen für den S2D Cluster. Aufgrund dessen, dass es schon ein wichtiges Sicherheitsfeature darstellen kann, würde ich nachforschen, warum es denn da etwas "zerschießt" normal ist das ja nicht.
Ich wäre sehr an mehr Informationen bzw. Quellen hierzu interessiert, da ich den Hintergrund zu Storage Spaces Direct (S2D) leider nicht kenne.
ich versteh das immer noch nicht warum der os hersteller da so ein dam dam macht. dann sollens das per patch halt gleich sicher für alle server und clients machen, und wer es nicht braucht, da wird es abschalten.
warum kann ein hersteller nicht gleich ein OS mit sicheren defaults ausliefern?!?!
Weil das ganze bunte Bling Bling dann per Default abgeschaltet wäre und das alles Niemand nutzen würde, weil 95% der Nutzerinnen und Nutzer keine Ahnung haben das es das überhaupt gibt. Dann könnte MS die Entwicklung von dem ganzen Bling Bling auch gleich sein lassen und das ganze wäre OS wäre genau das ein OS. Aber was dann fragt Zeus?
Das mit "per Patch halt gleich sicher für alle server und clients machen" ist schön und gut, ist aber in vielen Umgebungen nicht so leicht umsetzbar, weil es im Netz immer irgendwelchen Krempel gibt, der das nicht kann, irgendwelche Linux-Büchsen oder Drucker mit Scan to SMB und was weiß ich. Mit so einem Patch würde sich MS ordentlich in die Nesseln setzen.
Ach Linux Büchsen und MuFu sind noch das kleinere Übel, wenn Du Fertigungsmaschinen, vernetzt im Einsatz hast, die munter mit MS-DOS laufen mit dem MS-Client auf SMB1 mit NTLMv1, zum Glück gibt es VLANs und multipel konfigurierbare SAMBA-Server.