Support-Ende von SMBv1

End of Life

Mit dem aktuellen Update für Windows 10 und Windows Server 2016 steht eine Änderung ins Haus, die gerade für Benutzer älterer Linux-Distributionen große Auswirkungen hat. Nachdem Microsoft es über viele Jahre schon angekündigt hat, entfernt der Konzern mit dem aktuellen Update-Release den Support für das SMB-Protokoll 1.
Datenklau scheint Alltag in deutschen Unternehmen geworden zu sein. Im Oktober-Heft widmet sich IT-Administrator dem Thema 'Daten- und Informationssicherheit'. ... (mehr)

Das über 30 Jahre alte Server-Message-Block-Protokoll (SMB) [1] dient in erster Linie dazu, auf Datei- und Drucker-Freigaben zuzugreifen (Bild 1). Außerdem wird es von einer Reihe weiterer Netzwerkdienste verwendet. Im Lauf der Zeit wurde das Protokoll weiterentwickelt und liegt aktuell in Version 3.1.1 vor, die beispielsweise in Windows 10 und Windows 2016 zum Einsatz kommt. Im Open-Source-Umfeld begann man schon Ende der 80er-Jahre an einem Service zu arbeiten, der einen SMB-Server-Dienst auch im Linux-Umfeld zur Verfügung stellen sollte. Im Jahr 1992 erschien dann die erste Version des Samba-Servers.

In Microsoft-Umgebungen kommt das alte SMBv1-Protokoll kaum noch zum Einsatz, stattdessen stehen hier neuere Versionen zur Verfügung (SMBv2 und SMBv3). Vor allem sicherheitsrelevante Features, wie beispielsweise die Möglichkeit, SMB-Pakete zu signieren, sind für viele Anwender interessant. Leider ist aber SMBv1 in vielen Installationen immer noch aktiv und Verbindungen können immer noch auf Basis dieses veralteten Protokolls aufgebaut werden. Dies ist deshalb nicht wünschenswert, da die besten Security-Features neuerer SMB-Versionen nichts bringen, wenn das alte SMB-Protokoll immer noch aktiv ist.

SMBv1 hat Sicherheitslücken

Microsoft weist schon seit langer Zeit darauf hin, dass das SMBv1-Protokoll eine Vielzahl von Schwachstellen besitzt und daher abgeschaltet werden sollte. Wie das geht, zeigt beispielsweise der Microsoft-Knowledgebase-Artikel [2]. Seit Windows 2012 gilt das Protokoll bereits als "deprecated" und auch die empfohlene "Security baseline" für aktuelle Windows-Versionen enthält die Empfehlung, das Protokoll zu deaktivieren. Windows-Benutzer, die diesem Ratschlag nicht gefolgt sind, hatten spätestens im Frühjahr mit WannaCry [3] ein böses Erwachen. Der Verschlüsselungstrojaner hat sich nämlich eine altbekannte Schwachstelle im SMBv1-Protokoll zu Nutze gemacht, um darüber Windows-Systeme zu infizieren.

Mit dem aktuellen Update für Windows 10 und Windows 2016 wird es damit nun aber vorbei sein. Mit dem Redstone-3-Update wird SMBv1 standardmäßig nicht mehr installiert. Da Microsoft die SMB-Funktionen jetzt nach Client und Server getrennt verwaltet, steht in den Home- und Pro-Versionen von Windows ein SMB-Client jedoch nach wie vor zur Verfügung und wird nur dann deinstalliert, wenn er nicht aktiv verwendet wird. Die Unterscheidung wurde einfach deshalb vorgenommen, um es Anwendern zu ermöglichen, immer noch auf SMB-Server zugreifen zu können, die lediglich SMBv1 unterstützen. Microsoft pflegt sogar eine Liste der Hersteller, die in ihren Produkten noch SMBv1 einsetzen [4]. Die Liste ist sicherlich nicht vollständig, aber dennoch erstaunlich lang. Auf der anderen Seite wird es aber nun nicht mehr möglich sein, als Anwender eine Verbindung mittels SMBv1 aufzubauen, wenn das System zuvor auf Redstone 3 aktualisiert wurde. Somit gehören Angriffe, die SMBv1 als Einfallstor verwenden, nun hoffentlich der Vergangenheit an.

Welche Auswirkungen haben diese Änderungen jetzt auf Linux-Anwender? Dies hängt primär von der Aktualität der eingesetzten Distribution und den einzelnen Anwendungsfällen ab. Schaut man sich die obige Liste einmal näher an, finden sich darauf auch die beiden großen Linux-Enterprise-Distributoren SuSE und Red Hat. Allerdings sind hier nur ältere Versionen der jeweiligen Linux-Distribution betroffen: SUSE Linux Enterprise Server 11 und Red Hat Enterprise Linux 6. Diese bringen lediglich Unterstützung für SMBv1 mit, während aktuellere Versionen auch SMBv2 und SMBv3 bieten. Ein Upgrade auf die jeweils aktuelle Version ist daher sicherlich anzuraten. Teilweise ist dies aber nicht möglich, daher sollen an dieser Stelle die einzelnen Anwendungsfälle aufgelistet werden, um auch mögliche Alternativen aufzuzeigen – wenn diese denn existieren.

SMBv2-Support erst mit Samba 4.1

Stellt das Linux-System einen Dateiserver mit Hilfe von Samba zur Verfügung, so unterstützt dieser das SMB-Protokoll SMBv2+ erst ab Samba 4.1. Ältere Linux-Distributionen enthalten aber zumeist Samba in der Version 3.6, womit der Zugriff eines Windows-Clients fehlschlägt, wenn auf ihm SMBv1 ausgeschaltet oder entfernt wurde. Als mögliche Alternative zu einem Update des Samba-Servers ist hier lediglich das Aktivieren des SMBv1-Protokolls auf dem Client zu nennen.

Ein weiterer klassischer Anwendungsfall besteht darin, von einem Linux-Client auf eine Datei- oder Drucker-Freigabe eines Windows-Systems zuzugreifen. Dieser Zugriff erfolgt entweder mittels des Samba-Tools smbclient oder des Kernel-Moduls cifs. Mittels cifs lässt sich die Freigabe in das lokale Dateisystem des Linux-Systems einhängen. Dieser Zugriff wird nicht mehr funktionieren, wenn auf dem Server SMBv1 nicht mehr unterstützt wird, da auf älteren Linux-Systemen das Kernel-Modul cifs ebenfalls nur SMBv1 unterstützt. Hier ist in jedem Fall ein Update des Linux-Systems notwendig, da das nachträgliche Aktivieren von SMBv1 auf einem Windows-System nicht empfehlenswert ist.

Bild 1: Zugriff auf Windows-Shares mit einem Linux-Dateiprogramm. Damit ist bald Schluss, wenn die Linux-Distribution nur SMBv1 unterstützt.

Teilweise verfügen Linux-Systeme über ein eigenes Maschinen-Konto in einer Active-Directory-Domäne. Um ein neues System in eine Domäne aufzunehmen, kommt zumeist das Tool net aus der Samba-Suite zum Einsatz. Es unterstützt auf älteren Systemen aber, wie beschrieben, lediglich das SMBv1-Protokoll. Der Beitritt in eine Windows-Domäne, in der SMBv1 auf den Domänen-Controllern deaktiviert wurde, ist somit also nicht mehr möglich. Als Alternative bietet sich hier an, das Tool anzuweisen, statt SMB das Kerberos-Protokoll zu verwenden. Hierfür kennt das net-Tool die Option "-k". Allerdings muss der Benutzer bereits über ein entsprechendes Kerberos-Ticket verfügen (kinit). Ansonsten besteht ebenfalls die Möglichkeit, auf das Tool adcli zurückzugreifen. Es verzichtet von Haus aus auf den Einsatz von SMB und verwendet zur Kommunikation mit einem Domänen-Controller lediglich die Protokolle LDAP und Kerberos.

Anwender, die auf Samba Winbind zurückgreifen, um Benutzer aus einem Ac-tive Directory auf einem Linux-System zu authentifizieren, haben ebenfalls schlechte Karten. Hier besteht eine mögliche Alternative im Umstieg auf den System Security Services Daemon (SSSD), allerdings unterstützt dieser kein NTLM, das in manchen Umgebungen eventuell noch benötigt wird. Da der SSSD auf die Samba-Bibliothek libsmbclient zurückgreift, um GPOs von einem Win­dows-System zu beziehen, gibt es auch Probleme mit der Zugangskontrolle auf Linux-Systemen, wenn Administratoren hierfür auf Windows-GPOs zurückgreifen. Ein Update auf eine Samba-Version mit Support von SMBv2 und SMBv3 ist hier die beste Option.

Ein weiteres Problem sind POSIX-Erweiterungen, die eventuell in einer Windows-Domäne zum Einsatz kommen. Diese sind zwar Bestandteil der SMBv1-Spezifikation, neueren SMB-Versionen allerdings komplett unbekannt. Bei den betreffenden Projekten finden zwar schon einige Arbeiten statt, um diese Erweiterungen auch mit neueren SMB-Versionen verwenden zu können, allerdings wird es wohl noch eine ganze Zeit dauern, bis diese abgeschlossen sind und die Unterstützung hierfür in die verschiedenen Enterprise-Produkte eingeflossen ist.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023