[English]Microsoft empfiehlt Administratoren von Exchange Servern aus Sicherheitsgründen, das SMBv1-Protokoll auf den betreffenden Maschinen zu deaktivieren.
Anzeige
Das SMBv1-Problem
Das Kürzel SMB steht für Server Message Block (frühere Bezeichnungen lauten als LAN-Manager- oder NetBIOS-Protokoll), ein Netzwerkprotokoll für Datei-, Druck- und andere Serverdienste in Rechnernetzen. Die Version 1 (SMBv1) des vor über 30 Jahren entworfenen Netzwerkprotokolls und speziell die Microsoft-Implementierung, gilt als sehr fehleranfällig und sicherheitskritisch. Zwischenzeitlich gibt es SMBv2 und SMBv3, so dass die Verwendung von SMBv1 in Windows-Netzwerken nicht mehr unbedingt erforderlich ist.
Microsoft hat daher bereits im September 2017 den Beitrag Stop using SMB1 veröffentlicht, in dem von der Verwendung von SMBv1 abgeraten wird. Es sei unsicher und den modernen Anforderungen nicht mehr gewachsen. Zudem sei SMBv1 nicht mehr erforderlich …, was aber das Problem verkennt, dass in vielen Firmen immer noch Geräte wie Multifunktionsgeräte (Drucker mit Scan-Einheiten) stehen, die über SMBv1 Dateien auf Freigaben speichern. Die lassen sich nicht umstellen.
Was Microsoft im Nacken sitzt
Im Mai 2017 infizierte der Erpressungstrojaner WannaCry weltweit tausende Computer (siehe Ransomware WannaCry befällt tausende Computer weltweit). Grund für die Verbreitung war auch eine Sicherheitslücke in der SMBv1-Implementierung von Windows (siehe SMB Zero-Day-Sicherheitslücke in Windows 8.1/10/Server). Diese Sicherheitslücke war aber vor dem WannaCry-Befall durch Sicherheitsupdates von Microsoft geschlossen worden. Eigentlich hätte WannaCry nicht mehr die Sicherheitslücke ausnutzen können – aber die betroffenen Rechner waren ungepatcht.
Anzeige
Die Pflege des SMBv1-Codes ist mit einem gewissen Aufwand verbunden und es lässt sich nicht ausschließen, dass in der Implementierung weitere Schwachstellen enthalten sind. Daher möchte Microsoft vorbeugen und forciert, dass die Leute auf SMBv2 oder SMBv3 umsteigen sollen.
Zudem will Microsoft die im Blog-Beitrag SMB-Lücke SMBloris in Windows bleibt ungepatcht beschriebene Schwachstelle, über die man Rechner abschießen könnte, nichts mehr patchen (nicht so kritisch).
Schrittweise Abschaltung ab Herbst 2017
Ich hatte im Blog-Beitrag Windows 10: Aus für SMBv1 ab Herbst 2017 darauf hingewiesen, dass Microsoft damit beginnt, SMBv1 in Windows 10 schrittweise abzuschalten. SMBv1 wird bei Neuinstallationen von Windows 10 nicht mehr automatisch mit installiert. Das wurde schrittweise umgesetzt – und Administratoren können auch selbst tätig werden. Ich habe zu diesem Thema einige Informationen im Blog-Post SMBv1-FAQ und Windows-Netzwerke zusammen getragen.
Empfehlung, SMBv1 in Exchange abzuschalten
Lawrence Abrams ist ein Techcommunity-Beitrag Exchange Server and SMBv1 aufgefallen, in dem Microsoft Administratoren von Exchange-Servern bei on-premises-Installationen empfiehlt, SMBv1 aus Sicherheitsgründen zu deaktivieren. Abrams weist in diesem Tweet darauf hin.
Microsoft Urges Exchange Admins to Disable SMBv1 to Block Malware – by @LawrenceAbramshttps://t.co/vdBbdgqhuf
— BleepingComputer (@BleepinComputer) February 12, 2020
Im Techcommunity-Beitrag Exchange Server and SMBv1 (veröffentlicht am 12. Februar 2020) lautet die Empfehlung:
To make sure that your Exchange organization is better protected against the latest threats (for example Emotet, TrickBot or WannaCry to name a few) we recommend disabling SMBv1 if it's enabled on your Exchange (2013/2016/2019) server.
Um einen besseren Schutz vor Ransomware zu haben, wird die Deaktivierung des SMBv1-Protokolls empfohlen. Im Beitrag weisen die Microsoft-Leute darauf hin, dass keine Notwendigkeit besteht, das fast 30 Jahre alte SMBv1-Protokoll auszuführen, wenn Exchange 2013/2016/2019 auf einem System installiert ist.
Microsoft hatte bereits 2014 das SMBv1-Protokoll als veraltet (deprecated) erklärt. Die Verwendung des SMBv1-Protokolls bei der Installation wurde ab Windows Server 2016 1709 (RS3) standardmäßig eingestellt. Weitere Informationen finden Sie in dieser KB. Im Techcommunity-Beitrag Exchange Server and SMBv1 gibt es weitere Hinweise.
- So hat Microsoft nicht validiert, dass der im Oktober 2020 aus dem Support fallende Exchange Server 2010 mit deaktiviertem SMBv1-Protokoll sauber läuft.
- Zudem empfiehlt Microsoft vorher zu prüfen, das ein korrekt konfigurierter und unterstützter DAG (database availability group) Witness Server (Spiegel-Server) verwendet wird, der mindestens SMBv2 unterstützt.
Im Techcommunity-Beitrag gibt Microsoft zudem Hinweise, wie man unter verschiedenen Server-Versionen prüft, ob das SMBv1-Protokoll aktiviert ist und wie man dieses deaktivieren kann.
Ähnliche Artikel:
SMBv1-FAQ und Windows-Netzwerke
Windows 10: SMBv1-Klippen in Version 1803
Samba 4.11 deaktiviert SMBv1 und unterstützt SMBv2
Anzeige
Eigentlich gibts wirklich keine Notwendigkeit mehr für SMBv1. Stimmt.
Ich hatte aber mal vor 2 Jahren einen Fall, wo nach Abschaltung von SMBv1 in der gesamten Domäne anschließend die gesamte komplett durchgepatchte VSphere-6.5-Umgebung verrückt gespielt hat, nicht nur das vCenter, sondern sämtliche ESXi-Hosts waren da AD integriert, wie man es ja eigentlich auch machen sollte. Der VMware-Support hat über 1/2 Jahre gebraucht, um das Problem zu bestätigen, es wurde aber nie an die große Glocke gehängt. Uns half vorrüberghehend nur, zumnindestens bei den DCs wieder SMBv1 einzuschalten…
Und privat eigentlich auch nicht.
Aber wer gerne mit alten Rechnern rumspielt, muss teilweise froh sein, wenn es für diese Netzwerklösungen gibt, die wenigstens mit SMBv1 umgehen können, prominente Beispiele sind da Win 9x, NT, 2000, aber auch z.B. NetBSD/Debian-Linux für die 68000-Schiene (Ataris/Amigas/Macs mit 68030 oder besser). Bei mir läuft daher auf meinem Heimserver eine Linux-VM mit, der per SMBv2 vom Host die notwendigen Retro-Verzeichnisse mountet und per SMBv1 und NFS 2 und FTP wieder freigibt (natürlich soweit es geht auf den Retro-IP-Bereich im Heimnetz beschränkt ohne mich mit iptables rumschlagen zu müssen), so klappt es mit neben den betagten Windows-Versionen auch mit MiNT (nein, nicht Linux-Mint, sondern "MiNT is Now TOS, ein Unix/Linux-ähnliches OS für gehobenere Rechner der Atari ST Serie, das immerhin NFS-Shares mounten kann), STING (ein TCP/IP-Stack für die kleineren Ataris) und mTCP (für MS-DOS). Amiga dürfte auch klappen, hab ich aber noch nicht hinbekommen, da kenne ich mich nicht so aus.
Bei unseren Maschinen im Werkzeugbau habe ich die Wahl: SMB1 oder NFS3 (teilweise NFS2). Letzteres natürlich so, dass User-ID 0 (=root) verwendet wird…
Hat viel Freude gemacht in letzter Zeit. Ich habe das Problem so ähnlich wie Du gelöst, wenn auch auf Windows-Basis: der NFS-Server von haneWin kann im Gegensatz zu den meisten anderen (Windows-)NFS direkt auf UNC-Verzeichnisse umleiten.
Das mit dem Linux-Rechner ist aber evtl. eine Idee für die Maschine, die noch Windows XP einsetzt… (Nein, ein Update der Steuerung ist nicht möglich. Zu alt.).
Wenigstens sind die alle in einem eigenen VLAN.
Das HaneWin-Zeugs sieht lecker aus, nicht nur der nfs-Server… Aber meine "Linux-Appliance" tuts auch, braucht halt leider "etwas" mehr Ressourcen… :)
Ursprünglich hatte ich auch mit verschiedenen freien NFS-Servern unter Windows experimentiert, aber da funktionierte – zumindestens mit MiNT – keiner vernünftig, die waren schlicht mit den Datenmengen auf dem Share überfordert…
AUTSCH!
Hanewin frickelt sein Zeux mit URALTEN und UNSICHEREN Werkzeugen: sowohl die ausführbaren (IGITT) Installationsprogramme als auch deren Nutzlast erlauben "escalation of privilege" nicht nur per DLL-Hijacking.
Und der Frickler will seine BLUTIGEN Anfängerfehler NICHT korrigieren.
Daher: FINGER WEG!
"Escalation of Privilege" auch Remote oder "nur" von dem Rechner aus, auf dem sie installiert sind? Falls letzteres wäre es kein Problem, macht man halt ne extra-VM…
Gibt es Belege für Deine Aussage? Ich muss ja ggf. nachweisen, warum ich die Zeit reingesteckt habe, das abzulösen…
Also das mit SMBv 1 ist etwas kompliziert. Wer das auf funktionierende Heimnetzwerke in Win10 deaktiviert hat ein Problem. Denn möglicherweise werden die Geräte im Heimnetzwerk bzw. privaten Netzwerk nicht mehr korrekt angezeigt. Man kommt also nicht in die anderen PCs rein.
Ich habe das mal komplett (bei einem PC Upgrade von Win7 auf Win10 bei dem es funktionierte) heute deaktiviert. Dann zeigt er nicht so viel an. Das kann man zwar umgehen mit dem alten Netzmanager V 1.2 von Telekom (der neuere macht das nicht), auf der Herstellerseite dieses Dings kann man den noch abrufen. Das kann aber nicht die Lösung sein.
Also muss man für sich SMBv 1 Client einschalten. Dann wird es angezeigt wieder.
MS und andere weisen auch darauf hin, dass bei Anzeigen von Geräten im privaten Netzwerk das aktivieren kann, um die Geräte sichtbar zu machen.
Für Unternehmensumgebungen stellt sich das ganze natürlich anders dar.
Ich habe – privat – noch ein altes Medion NAS im Betrieb, welches nur SMBv1 versteht.
Was aber nicht so tragisch ist, da dieses nur aktiviert wird, wenn Backups gezogen werden. Sind diese Durch, geht es wieder offline.
Nicht wirklich ideal. Gebe ich zu. Aber es funktioniert einwandfrei und ein Update gibt es leider nicht.
Wir haben hier ein Kopier-/Multifunktionsgerät eines richtig grossen Herstellers.
Das Gerät kostet eine höhere vierstellige Summe.
Trotzdem funktionieren die Zusatzfunktionen nicht ohne SMBv1.
:-(
Schalten wir SMBv1 ab, dann taugt das Gerät NUR noch zum Kopieren.
Es ist also nicht immer nur Microsoft.
HP Officejets brauchen auch noch SMBv1. Jedenfalls der 8500A, den ich mal hatte.
Davon wird es wohl noch etliche in Büros geben.