X
Kommentare zu:

Microsoft will altes SMB-Protokoll nach Wannacry endlich abschalten

oder

Zugangsdaten vergessen?

Jetzt kostenlos Registrieren!
[o1] RalphS am 19.06. 12:08
+2 -
Es IST doch schon lange abgeschaltet. Wenn man das natürlich selbst wieder ANschaltet, TROTZ der bekannten Probleme...
[re:1] der_ingo am 19.06. 14:22
+ -
@RalphS: bei einer Standardinstallation von Windows 10 1703 oder Server 2016 ist SMB1 immer noch aktiv.
[re:1] RalphS am 19.06. 18:48
+ -
@der_ingo: Jetzt hab ich extra nochmal nachgeschaut. Immerhin setz ich das bei mir auch öfter mal neu auf und SMB1 wollt ich jetzt nicht noch "aus Versehen" wieder drin haben *shock*

Also, nein. SMB1 ist nach wie vor unter Legacy/Deprecated geführt und ist dort wie bisher üblich explizit *zuzuschalten* , wenn man das haben will. "Normal" kann Windows nur noch SMB2 und SMB3.
[re:1] der_ingo am 19.06. 19:30
+ -1
@RalphS: welches System denn genau?
[re:2] MurdocX am 19.06. 19:57
+1 -1
@RalphS: Diese unqualifizierte Aussage kann so nicht stehen gelassen werden.
Natürlich ist SMB1 von Windows XP bis Windows 10 1703 und Server 2016 als default noch aktiv!

Auch nachzulesen hier:
"In Windows 8.1 and Windows Server 2012 R2, we introduced the option to completely disable CIFS/SMB1 support, including the actual removal of the related binaries. While THIS IS NOT THE DEFAULT configuration, we recommend disabling this older version of the protocol in scenarios where it's not useful, like Hyper-V over SMB."

https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/
[re:1] RalphS am 19.06. 20:15
+ -
@MurdocX: Okay, dann hab ich wohl andere Windowsen als Du. Mich stört SMB1 nämlich auch und ich möcht das nicht anhaben; allerdings hatte ich auch nicht weiter reingeschaut -

- und hab es deswegen nachgeprüft auf meinem Win8(9600), Win10 (15063) und Server 2012r2, per Neuinstallation.

Auf dem Server war's tatsächlich dann an. Auf den Clients aber nicht, ebensowenig wie die DirectPlay-Unterstützung.
[re:2] MurdocX am 19.06. 23:44
+1 -
@RalphS: Nein das hat nichts mit anderen Windows-Versionen zu tun, sondern damit wie du verifizierst, dass SMB1 angeblich ausgeschaltet ist.

Ab Windows 8 ist dies nämlich erstmals über die PS möglich, davor nur über die Registry.

Nur weil die Unterstützung für SMB1 nicht in den "Windows-Features"(GUI) sichtbar ist, heißt das nicht das sie nicht aktiv ist ;-)

Windows 7 Dienste sind abhängig von SMB1 und nur über spezielle Konfigurationen wie z.B. der "LanManWorkstation" alias "Arbeitsstationsdienst". Hier lässt sich über die Abhängigkeiten definitiv sagen, SMB1 (MRxSmb10) ist aktiv und verknüpft.

https://support.microsoft.com/de-de/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server
[o2] JasonLA am 19.06. 12:20
+3 -
anstatt des Videos zu Windows 10, was hier gar nicht passt, wäre eine Erklärung, was SMB mit WannaCry zu tun hat sinnvoll.
[re:1] Lord Laiken am 19.06. 12:30
+4 -
@JasonLA:
Bitte sehr:

"Beispielsweise basierte die Cyberattacke mit der Ransomware WannaCry im Mai 2017 auf einer solchen Sicherheitslücke in der 1. Version des Protokolls."

https://de.wikipedia.org/wiki/Server_Message_Block
[re:2] WolfgangKrauser am 19.06. 15:32
+ -
@JasonLA: Kommt in letzter Zeit (imho) immer oefter hier vor das einfach mal ein Video in den Artikel geklatscht wird, auch wenn es nicht viel mit dem Artikel zu tun hat. Sinkende Aufnahmefaehigkeit von Millenials...?
[re:1] Irgendware am 20.06. 11:18
+ -
@WolfgangKrauser: Ich denke das hat eher damit zu tun, dass sich mit der Werbung auf Videos mehr Einnahmen erzielen lässt, als mit Bannern...
[o3] DarkKnight80 am 19.06. 12:27
+2 -1
Leider wird SMB1 noch immer von diversen (sehr teuren) Druckern / Kopierern (zum Scan auf einen Fileserver) einzig und alleine eingesetzt. Dies war leider auch ein Grund warum wir es im Firmennetzwerk wieder einschalten mussten. Mal schnell 20 dieser Geräte für zig tausend Euro zu ersetzen oder das uralte unsichere Protokoll wieder zu aktivieren. Da war die Entscheidung gaaaaanz schnell von der oberen Etage getroffen :-(...
[re:1] Chilla42o am 19.06. 12:40
+10 -
@DarkKnight80: Drucker hassen die Menschheit.
[re:2] My1 am 19.06. 13:13
+1 -
@DarkKnight80: was aber hilft ist dass man u.U. SMB1 NUR auf dem betroffenen Server anwirft und den server am besten mit ner guten Firewall dazu bringen dass der nur vom drucker SMB1 pakete annimmt.
[re:1] DarkKnight80 am 19.06. 13:15
+1 -
@My1: Danke für den Tipp ;-). Das haben wir letztendlich auch genau so gemacht. Aber dennoch ärgerlich, dass man es aktivieren muss, weil die Hersteller noch immer und einzig und alleine auf SMB1 setzen :-(
[re:1] My1 am 19.06. 13:20
+1 -
@DarkKnight80: klar das ist natürlich doof. das ist genauso wie mit SSL2 oder 3 welches ja auch schon lange auf den Müll gehört.
[re:2] der_ingo am 19.06. 14:24
+ -
@My1: auf Firewallebene zwischen SMB1 und 3 zu unterscheiden wird aber auch nicht ganz einfach. Wie machst du das?
[re:1] My1 am 19.06. 14:34
+ -
@der_ingo: ich muss mich zum glück nicht drum kümmern aber gibts dafür nicht deep packet inspection?

und für den internen datenfluss von/zu fileserver dürfte das auch rechtlich kein problem sein.
[re:1] Nunk-Junge am 19.06. 16:52
+ -1
@My1: Deep Packet Inspection (DPI) ist immer (!) rechtlich ein Problem. Je nachdem wie man sie einsetzt verstößt man gegen zahlreiche Gesetze. Da immer personenbezogene Daten erfasst werden, greift auf jeden Fall die unterschiedlichen Datenschutzgesetze (§1 BDSG und auch Länderdatenschutzgesetze) und der Betriebsrat der Firma ist mit einzubeziehen. Je nachdem was man dann filtern will greifen aber auch dann noch mehrere Straftatbestände, u.a. Ausspähen oder Abfangen von Daten (§202a und b StGB), Verstoß gegen Fernmeldegeheimnis (§206 STGB), Datenveränderung (§303a STGB). Wer DPI einsetzen will, der sollte sich vorher sehr sorgfältig rechtlich absichern.
[re:2] der_ingo am 19.06. 17:01
+ -
@My1: deswegen noch mal extra vor den Fileserver eine Hardwarefirewall zu stellen halte ich für keine sinnvolle Variante. Insofern ist das alles vielleicht nicht sinnvoll, was du da vorgeschlagen hast, SMB1 nur von einem bestimmten Gerät zuzulassen.

Man schaltet stattdessen SMB1 auf den Systemen ab, auf denen es nicht mehr gebraucht wird und lässt es nur dort an, wo es halt nicht anders geht. Dort ist es dann halt an.
Das wird auch nach Microsofts Änderung möglich sein. Man schafft SMB1 ja weiterhin nicht ab. Man aktiviert es nur nicht mehr standardmäßig bzw. installiert das entsprechende Feature nicht mehr standardmäßig mit.
[re:3] My1 am 20.06. 09:41
+ -
@der_ingo: natürlich gehört das abschalten auf allen anderen geräten dazu aber der virus/trojaner/wasauchimmer kann ja auch nen eigenen mini-SMB1 client mitbringen und zumindest den fileserver und die anderen geräte die SMB1 benötigen hacken und das geht doch auch mitner guten softwarefirewall oder nicht?
[re:4] My1 am 20.06. 09:43
+ -
@Nunk-Junge: naja ich hätte halt gedacht dass der nur die header prüft, wenns SMB1 ist, wird die verbindung abgeägt, wenns ne 2er oder 3er ist lässt der die verbundung in ruhe. geloggt wird nur wann ne SMB1 von welchem Computer geblockt wurde, nicht mehr (damit man halt den computer isolieren und reinigen kann).

keine persönlichen daten, nix.
[re:5] Nunk-Junge am 20.06. 10:31
+ -1
@My1: Ein IP-Packet hat im Header keine Information, ob es zu einer SMB1-Verbindung oder etwas anderem gehört. Das kannst Du nur über eine Analyse des Inhaltes von Paketen feststellen. Und damit trifft das oben genannte zu. DPI ist technisch recht einfach, rechtlich aber ein ganz heißes Pflaster.
[re:6] My1 am 20.06. 10:38
+ -
@Nunk-Junge: ich meine nicht den IP header, sondern den protokollheader.

ja man muss das paket analysieren, aber wenn man von dem paket nur den SMB-header analysiert (genauso wie bspw auch den HTTP header bei HTTP paketen oder so) und dann nur droppt oder durchlässt sollte es doch kein problem sein, denke ich zumindest.
[re:7] Nunk-Junge am 20.06. 17:16
+ -1
@My1: So einfach ist das leider nicht. Ein IP-Paket hat keinen SMB-Header und auch keinen HTTP-Header. Etwas verkürzt enthält ein IP-Paket nur Start- und Zieladresse, Fragmentierungsinfo und Nutzdaten. Ich muss daher die Nutzdaten analysieren, um festzustellen was sich darin versteckt. In einem einzelnen Paket ist dabei nur ganz wenig Information. Insbesondere wenn ich verbindungsorientierte Protokolle wie TCP nutze, dann bin ich gezwungen eine ganze Reihe von IP-Paketen zu analysieren. - Oder von der anderen Seite her betrachtet: SMB (oder mit anderen Bezeichnungen CIFS oder Netbios) baut als Application-Layer-Protokoll auf verschiedenen Transport-Layer-Protokollen auf. Das kann ein verbindungsloses UDP sein oder aber auch ein verbindungsorientiertes Protokoll wie TCP oder IPX/SPX sein. Diese basieren wieder auf den oben genanneten Internet-Layer-Protokollen wie IP. - Also reicht die Analyse eines IP-Paketes niemals, sondern es benötigt eine Analyse der Daten bis zum Application Layer und damit ist man voll drin in den personenbezogenen Daten.
[re:8] My1 am 21.06. 09:27
+ -
@Nunk-Junge: man müsste bis zum application layer aufmachen ja, aber da drin ist ja dann der SMB header drin, und eben diesen analysiert man, den rest ignoriert man und wenn das in mehrere teile getrennt ist muss es ja immer noch mit irgendwas SMB spezifischem losgehen, wo dann auch die version vermerkt ist. man nimmt halt pakete auf bis man weiß ob es SMB1 ist und verweigert die verbindung, wenn nix geloggt wird gibts da auch keine problematik, oder wieso sollte es?

ansonsten kann man es ganz übel machen indem man 2 SMB-Server hat 1 für SMB1 und einen mit SMB2/3 und beide greifen über ein anderes protokoll auf die eigentliche storage dahinter zu. der für SMB1 kann nur per SMB mit den problematischen geräten kommunizieren und eben über das andere protokoll mit der storage und der andere hat SMB1 aus.
[re:9] Nunk-Junge am 21.06. 12:44
+ -
@My1: Das Gesetz ist leider eindeutig. Wenn Du personenbezogene Daten erfasst - egal ob gewollt oder ungewollt und auch egal ob Du sie nutzt oder ignorierst - dann sind die entsprechenden Gesetze einschlägig (d.h. sie greifen). Deine Vorstellung funktioniert daher nicht.
[re:10] My1 am 21.06. 12:55
+ -
@Nunk-Junge: das wort erfassen müsste ich nachschlagen, aber das geht wohl schon dadurch los dass man das paket auspackt.

aber was ist denn in dem paket mit SMB header so persönliches drin? so wie ich SMB kenne wird ja erstmal angefragt ob überhaupt jemand auf SMB da ist und dann kommt die authorisierungsanfrage

und wenn die firewall noch vor der authorisierung den request ins nirvana befördert entstehen nicht mal persönliche daten auf der ebene.

und was ist mit der 2. lösung ich ich vorschlug die keine paket inspection bräuchte, wäre das machbar (auch aus technischer sicht oder wäre das zu unpraktisch)
[re:3] Clawhammer am 19.06. 13:22
+1 -
@DarkKnight80: Alternative: Drucker an einem Druckerserverpc anschließen (USB) und dann darüber freigeben. Sofern das natürlich geht.
[re:1] der_ingo am 19.06. 17:03
+ -
@Clawhammer: das Problem ist normalerweise, dass der Drucker eingescannte Dokumente per SMB auf den Clients der User oder einem zentralen Share auf dem Server ablegen will. Es geht ums Scannen. Drucken selber muss man zum Glück normalerweise nicht per SMB, das sollte also gar kein Problem sein.
[o4] DerTigga am 19.06. 17:03
+ -
Klingt für mich, so als nicht grade viel Einblick hinein habender, danach, als ob ich womöglich demnächst mit dem genutzten Win7 Prof oder auch dem Android 6 meines Huawei M3 Tablets (warte seit Wochen auf das versprochene Firmwareupdate) etwas ziemliche Probleme kriegen könnte, (über meine Fritzbox 6490) auf meine NAS Station "drauf" zu kommen ?
Sollte sich das als hintertürige Zwangsmaßnahme entpuppen, (endlich) auf Win10 updaten zu müssen, werd' ich echt stinkig..
[re:1] RalphS am 19.06. 20:12
+ -
@DerTigga: SMB2 gibt's seit fast 10 Jahren.
[re:1] DerTigga am 19.06. 21:09
+ -
@RalphS: Verstehe, sollte also längst drin sein.. Danke ;-)
[o5] monumentum! am 19.06. 19:27
+ -6
>>Der Softwarekonzern Microsoft wird das Erscheinen des nächsten Major Release von Windows auch zum Anlass nehmen, sich in allen möglichen Versionen seines Betriebssystems vom klassischen SMB-Protokoll zu verabschieden [...]<<

Da ich Microsoft grundsätzlich keine Funktionen aus meinen Systemen ausbauen lasse, wird aus diesem Vorhaben von Microsoft in meinem Fall nichts. :-P

>>Intern sollen bei Microsoft schon neue Windows-Builds angefertigt werden, in denen das Protokoll stillgelegt ist. Das gilt beispielsweise für aktuelle Fassungen von Windows 10 Enterprise und Windows Server 2016.<<

Das ist gut, solange es bei den beiden Systemen bleibt, denn Windows 10 oder Windows Server 2016 werde ich niemals verwenden und daher betrifft es mich dort nicht, wenn dort zukünftig die Kompatibilität zu älteren Windows-Versionen fehlt. Ich habe aber keine Lust von meinen neueren zu meinen älteren Windows-Versionen keine SMB-Verbindungen im Netzwerk mehr aufbauen zu können und daher werden die SMBv1 behalten.
[re:1] der_ingo am 19.06. 19:34
+4 -1
@monumentum!: man kann dir dann nur sowas wie WannaCry im lokalen Netz wünschen und hinterher "haha" sagen. :-P
[re:2] Cheeses am 19.06. 20:53
+2 -
@monumentum!: Wenn SMB 1 eine dringende Voraussetzung in deinem Netzwerk ist, heißt das wohl, dass du ältere Versionen als Windows Vista / Server 2008 im Einsatz haben musst. Ich glaube in dem Falle sind Gefahren wie Wannacry dann sowieso dein kleinstes Problem :P
☀ Tag- / 🌙 Nacht-Modus
Desktop-Version anzeigen
Impressum
Datenschutz
Cookies
© 2024 WinFuture