SMB/CIFS im WAN

Immer mehr Dienste gehen in die Cloud und einige Firmen verlagern sogar ihre Server zu Azure oder anderen Cloud-Anbietern. Da stellt sich natürlich die Frage, wie das mit Dateiservern per SMB oder vielleicht auch anderen Protokollen aussieht. Anstatt Dateien auf SharePoint oder OneDrive, OwnCloud/NextCloud, Dropbox o.ä. abzulegen und im Browser zu öffnen bzw. zu replizieren, könnte man doch einfach einen Dateiserver im Internet bereitstellen, auf dem alle Anwender arbeiten

SMB und Sicherheit

Die erste Frage sollte natürlich das Thema Sicherheit sein. Wer einen Windows Dateiserver mal einfach so mit einer öffentlichen IP-Adresse im Internet erreichbar macht, öffnet vielleicht ein richtig großes Tor.

  • Portmapper
    Die früheren Versionen von SMBv1 und SMBv2 nutzen insbesondere den RPC-Portmapper auf Port 135, über den ein Client erst erfragt hat, auf welchem Port die Dateidienste denn laufen. Der Port 135 ist nicht einmal eine Erfindung von Microsoft. Hier hat SUN Pate gestanden, weil schon absehbar war, dass man nicht jedem Dienst einen eigenen Port aus der Bereich 1-65535 reservieren kann. Server binden also einen dynamischen Port und der RPC-Endpoint Mapper weiß, woher den Client senden muss. Damit ist aber über Port 135 auch jeder andere Dienst "erfragbar" und dynamische Ports finden Firewall Administratoren auch nicht gut
  • Port 139/445
    Bis Windows NT4 hat der Windows Dateiserver den Port 139 genutzt und seit Windows 2000 ist der Port 445 für SMB/CIFS reserviert.
  • Verschlüsselung
    Neben der Erreichbarkeit und der potentiellen Gefahr einer DoS-Attacke durch das Durchprobieren von Kennworten oder die Ausnutzung von Lücken in der Implementierung gibt es auch im Tagegeschäft für legitime Anwender eine Herausforderung. Selbst nach einer Authentifizierung und mit gültigen Berechtigungen sollten sie wissen, dass die Daten erst ab Windows 8/Werver2012 bei Nutzung des Protokolls SMBv3 auch verschlüsselt werden können.
  • Downgrade
    Aus Kompatibilitätsgründen handeln der Client und Server das verwendete Protokoll aus. Sie müssen also beide z.B. SMBv3 anbieten und ein Angreifer dazwischen darf die Pakete nicht derart stören, dass beide ein schwächeres Verfahren nutzen.

Die meisten Firmen betreiben daher keinen SMB-Server einfach so am Internet, sondern Beschränken den Zugriff durch IPSEC, ein VPN oder bestimmte statische Client-Netzwerke. Wenn Sie nun einen SMB-Server in Azure betreiben, dann richtige Sie in der Regel auch ein VPN aus ihrem Büro-Netzwerk zum Azure-Subnetz ein oder die Clients im Homeoffice authentifizieren sich per IPSec oder VPN-Einwahl. Selbst eine Fritz!Box hat er Default einen "NetBIOS"-Filter, mit dem z.B. Zugriff über das Protokoll unterbunden werden.

Aus meiner Sicht ist es unverantwortlich, über das Internet eine Dateidienste ohne sichre Anmeldung, Signierung und Verschlüsselung zu betreiben. Damit darf aus meiner Sicht der Server nur noch SMB3. mit Signing und Verschlüsselung anbieten. Das bedeutet aber auch, dass alle Clients ohne diese Funktion ausgesperrt sind.

Daher hier noch einmal zur Sicherheit die Matrix, welche alten Clients welches Protokoll aushandeln.

Client/Server OS Server2012 oder neuer / Win8, Win10 Server 2008R2 / Win7 Server2008 / Vista Älter
Server2012 oder neuer / Win8, Win10

SMB 3.0

SMB 2.1

SMB 2.0

SMB 1.0

Server2008R2 / Win7

SMB 2.1

SMB 2.1

SMB 2.0

SMB 1.0

Server2008 / Vista

SMB 2.0

SMB 2.0

SMB 2.0

SMB 1.0

Älter

SMB 1.0

SMB 1.0

SMB 1.0

SMB 1.0

Dies Tabelle ist verkürzt. Sie finden an anderen Stellen auch noch Unterscheidungen nach SMB 3.0, SMB 3.0.1, SMB 3.0.2 und SMB 3.1.1 u.a.

Microsoft empfiehlt (Stand Jun 2020) immer noch, dass SMB2 nicht deaktiviert werden sollte:
Quelle: Erkennen, aktivieren und Deaktivieren von SMBv1, SMBv2 und SMBv3 in Windows - https://docs.microsoft.com/de-de/windows-server/storage/file-server/troubleshoot/detect-enable-and-disable-smbv1-v2-v3

SMB-Latenzzeiten und Packetloss

Wird der Dateiserver aus dem LAN in eine Cloud übertragen, dann reduziert sich meist die Bandbreite ein wenig aber viel schlimmer ist die Zunahme der Latenzzeit. In einem LAN sind Client und Server meist weniger als eine Millisekunde voneinander entfernt. Im WAN sind selbst 10ms ein sehr guter Wert. Meist sind es noch mehr und das hat einen deutlichen Einfluss auf den maximalen Durchsatz.

Wenn Sie 20ms "Roundtip-Zeit" haben und SMB-Anfragen sequentiell erfolgen und erst quittiert werden, dann sind pro Sekunde eben maximal 50 SMB-Pakete (1000ms/ 20ms) möglich. Ich habe das Thema auf der Seite TCP Window Scaling, Latenz und Durchsatz, RWIN schon umfangreich beschrieben. Diese Limits kann ein Protokolle relativ einfach speziell im WAN umgehen:

  • WindowSize
    Der Sender kann bis zu 16 GB senden, ohne auf die Quittung zu warten. Voraussetzung ist natürlich, dass nicht nur die beiden Endpunkte dies aushandeln, sondern auch eine Firewall oder Router dazwischen Einfluss nehmen kann. Zudem ist es nicht sinnvoll zu viele Pakete ohne Quittung zu senden, da man so leicht die Warteschlangen auf den Routern überlastet, die dann Pakete verwerfen. Das führt u.a. zu erneuten Übertragungen die Bandbreite kosten
  • Parallele Sessions
    Das Limit ist pro Sitzung und wenn das Protokoll es erlaubt, können mehrere parallele Sitzungen genutzt werden. Bei Dateiservern geht das recht elegant, wenn Sie z.B. mehrere Dateien parallel kopieren oder große Dateien in verschiedene Stücke aufteilen und diese parallel übertragen.

Eine hohe Windows-Size oder parallele Verbindungen bringen natürlich nichts, wenn ihre Applikation sequentiell arbeitet, z.B. Datei für Datei kopiert oder öffnet oder bei der Suche einer Datei in mehreren Verzeichnissen nicht parallel arbeitet. SMB ist durchaus als "gesprächig" bekannt. Das macht es auch für WAN-Optimierer (Riverbed, Cisco etc.) gerade interessant, SMB zu optimieren. Wenn gleich dies mit SMB 2/3 nicht mehr so viel bringt oder nur mit Abschaltung von SMB-Signing noch möglich ist und damit die Sicherheit senkt. Sie können auf den Clients das erwünschte SMB-Signing nicht einfach pro Netzwerkstandort ein- und ausschalten.

Bei einer WAN-Verbindung kann es viel häufiger vorkommen, dass einzelne Pakete verloren gehen. Das macht TCP an sich nichts aus, da das fehlende Paket erkannt, neu angefordert und nachgeliefert wird. Aber der TCP-Stack muss darauf eingehen und die in der Zwischenzeit schon empfangenen Pakete erst mal verzögern, bis das fehlende Pakete nachgeliefert wurde. Zudem ist ein Packetloss immer auch ein Zeichen für eine Überlastung mindestens einer Zeitstrecke und führt zu einer temporären Drosslung der Datenrate.

SMB in Azure

Auch wenn SMB über WAN verschiedenen Einschränkungen unterliegt, bietet Mikrosoft in Azure beide Dienste an:

Da muss man sich dann die Frage stelle, warum diese Dienste in Azure Betrieben werden sollten, wenn die Latenzzeit der Client in ihrem Firmennetzwerk eigentlich dagegen sprechen. Die Antwort ist schnell gegeben: Es gibt auch Clients in Azure selbst, die eine SMB-Freigabe nutzen können.

Genau so wie Clients aus ihrem LAN nur relativ langsam auf die Dateifreigaben in Azure zugreifen können, können Clients in Azure umgekehrt natürlich auch nur langsam auf OnPremises gehostete Server zugreifen. Für diese Systeme sind dann Dateiserver in Azure interessant, z.B.

  • Domain Dienste, SYSVOL
    Wenn Sie ihre lokales AD auch zu Azure ausdehnen, weil Server in Azure als "Domain-Mitglied" arbeiten müssen, dann stellen viele Firmen auch Domain Controller in Azure, die natürlich eine SYSVOL- und NETLOGON-Freigabe bereitstellen. So können die Member-Systeme sehr schnell ihre Anmeldeskripte und Gruppenrichtlinien bekommen
  • WDS und Benutzerprofile statt Terminal Server
    Wenn die meisten Dienste schon in der Cloud laufen, dann macht ein OnPremises Terminal-Server nicht mehr viel Sinn. Sie können also Terminal-Server in Azure aufbauen oder die neuen "Windows Virtual Desktop"-Variante wählen. Aber auch diese virtuellen Windows 10 Clients brauchen natürlich Domaindienste und Ablageorte für Anwender
    https://azure.microsoft.com/de-de/services/virtual-desktop/
  • SMB-Share für Server
    Ein SMB-Share ist zwar kein Ersatz für ein klassisches Backup aber viele Dienste, z.B. SQL, erlauben ein "Backup auf Netzwerklaufwerke". Gerade bei Umbauten oder Migrationen kann eine schnelle "Sicherheitskopie" auf ein SMB-Laufwerk sinnvoll sein

Das sind nur ein paar Beispiele und sicher gibt es noch weitere Einsatzbereiche für SMB-Freigaben in Azure.

Einschätzung

Die Bereitstellung klassischer SMB-Freigaben ist lokal oder in Azure problemlos möglich. Allerdings sollten Sie den Einsatzzeck genau bewerten. Microsoft hat nicht umsonst für Exchange Postfächer den "Cached Mode" mit einer lokalen OST-Datei eingeführt. Auch Dateien auf SharePoint oder OneDrive können per OneDrive-Client auf einen lokalen PC repliziert und dort bearbeite werden. Eine direkte Bearbeitung in der Cloud, z.B. in Teams, kann über WordApp im Browser erfolgen. Wenn ihre Applikation eh in der Cloud läuft, dann ist der Zugriff auf Dateien in der Cloud auch sehr schnell.

Immer dann, wenn aber das WAN und damit Latenzzeiten, Paketverluste etc. die Verbindung verschlechtern, wird natürlich zwangsläufig auch die SMB-Kommunikation darunter leiden. Bis zu einem gewissen Maß kann das toleriert werden aber in diesen Szenarien werden Sie sehr bald wieder über Kopien und Replikationen nachdenken oder die Verarbeitung und die Daten nahe zusammen bringen, z.B. in Form von "Windows Virtual Desktop", Client/Server Lösungen o.ä.

Ich durfte 2019 genau so eine Szenario analysieren, bei denen ein Kunde seinen Dateiserver und die Freigaben zu Azure verlagert hat und sich dann die Anwender über "schlechte Performance", "hängende Applikationen", "langsamer Windows Explorer" etc. beschwert haben. Wir haben dann mit End2End-Ping und End2End File aber auch mit Wireshark (vormals Ethereal) u.a. quasi bewiesen, dass es nicht am Netzwerk liegt, sondern das verwendete SMB-Protokoll zusammen mit der Arbeitsweise einfach ineffektiv arbeitet. Eine DOCX-Datei ist nun mal ein Container, in dem viele Dateien im ZIP-Format gespeichert werden und selbst kleinere Veränderungen und Umorganisationen durchaus umfangreichere SMB-Aktivitäten bewirken.

Schon ohne die Cloud hat Microsoft das Problem schon länger auf dem Radar und mit verschiedenen Alternativen den Einsatz verlängert, z.B. BanchCache

Stellen Sie daher einen klassischen Dateiserver immer möglichst nahe an die Client

Weitere Links