SMB mit der Windows Firewall gegen Angriffe absichern

Um auf künftige Sicherheits­lücken in SMB besser vorbereitet zu sein, kann man einige Vorkehrungen treffen, mit denen sich die Verwund­barkeit der Systeme reduzieren lässt. Dazu gehört vor allem, dass Rechner, die keine Verzeichnisse oder Drucker freigeben, auf SMB-Anfragen nicht reagieren.

Gefahr droht allerdings nicht nur durch böswillige Zugriffe auf einen PC, sondern auch, wenn sich dieser zu einem manipulierten SMB-Server verbindet. Die einfachste Lösung bestünde somit darin, die Dienste LanmanWorkstation und LanmanServer zu deaktivieren. Ihren Status kann man in PowerShell mit

Get-Service -Name Lanman*

abfragen.

SMB nicht verzichtbar

Das Problem bei diesem Vorgehen besteht jedoch darin, dass Rechner in einer Domäne den Workstation-Dienst benötigen, um Gruppen­richtlinien von einem Domain-Controller abzurufen. Außerdem nutzen praktisch alle Firmen einen File-Server oder ein NAS, die ohne den SMB-Client nicht mehr zugänglich wären.

Selbst wenn man den Server-Dienst abschaltet, bleibt daher immer noch die Aufgabe, den Client abzu­sichern. Eine Maßnahme besteht darin, dafür zu sorgen, dass SMB1 garantiert nicht läuft. Normaler­weise sollte heute kein System und keine Anwendung mehr dieses Steinzeit­protokoll erfordern.

SMB1 abschalten

In den neueren Versionen von Windows ist SMB1 per Voreinstellung deaktiviert. Dies kann man in PowerShell mit dem Aufruf von

Get-WindowsOptionalFeature -online | where FeatureName -like SMB*

überprüfen und, falls nötig, deinstallieren.

SMB-Verbindungen ins Internet blockieren

Nachdem man in Windows-Domänen nicht einfach auf SMB verzichten kann, kommt den Firewalls die Aufgabe zu, den Zugriff zu beschränken. So ist die SMB-Kommunikation zu Rechnern im Internet in der Regel nicht nötig, schon gar nicht wenn diese von außen initiiert wird. Daher sollte auf Perimeter-Firewalls der Port 445 für ein- und ausgehenden Traffic geschlossen sein.

Um interne Angriffe abzu­wehren, sollte man die Windows Defender Firewall auf Rechnern, die keine Ressourcen freigeben, entsprechend konfigurieren und den Zugriff auf diese Dienste blockieren:

• Anmeldedienst (NP eingehend)
• Datei- und Druckerfreigabe (SMB eingehend)
• Remote-Ereignisprotokollverwaltung (NP eingehend)
• Remotedienstverwaltung (NP eingehend)

Status der Regeln prüfen

Die gleich­namigen Regeln sind in Windows 10 per Voreinstellung für alle Profile deaktiviert. Dies lässt sich mit PowerShell so überprüfen:

Get-NetFirewallRule -Direction Inbound  |
where {($_.DisplayName -Like "*(NP*" -or $_.DisplayName -Like "*(SMB*")  } |
select DisplayName, Enabled, Profile

Microsoft empfiehlt darüber hinaus, eine zusätzliche Regel zu erstellen, um Port 445 für eingehenden Traffic zu blockieren und sich nicht auf die Standard­einstellungen zu verlassen. Die vorgegebenen Regeln könnten etwa durch die Installation einer Software aktiviert werden, do dass der PC eingehende SMB-Anfragen beantwortet.

Eine solche Port-Regel sollte für TCP, alle Remote-Computer, Programme und Profile gelten. In zentral verwalteten Umgebungen kann man sie über eine Gruppenrichtlinie verteilen.

Eigene Regel für Windows Server

Windows-Server verfügen über die gleichen Standardregeln für Port 445 wie Windows 10. Wenn dort Datei-/Speicherdienste aktiviert sind, was etwa auf DCs oder auf File-Server zutrifft, dann ist zumindest die Regel Datei- und Druckerfreigabe (SMB eingehend) aktiviert.

Diese könnte man wieder deaktivieren und eine eigene Regel erstellen, die den Zugriff auf bestimmte IP-Adressen einschränkt. Mit PowerShell ließe sich das so bewerkstelligen:

New-NetFirewallRule -Name "AllowSMB" -DisplayName "Allow SMB" -Enabled True `
-Profile Domain -Direction Inbound -Action Allow -RemoteAddress 192.168.0.64 `
-Protocol TCP -LocalPort 445 -Program System

Für RemoteAddress kann man auch einen Bereich in der Form 1.2.3.0-1.2.3.100 angeben. Alternativ akzeptiert dieser Parameter vordefinierte Konstanten wie DNS, DHCP, WINS, DefaultGateway, Internet oder Intranet, die aber nirgendwo dokumentiert sind. Für sich selbst spricht indes LocalSubnet, das in vielen Fällen passen wird.