VMware deckt mit Software-defined Networking via NSX sehr viele Anwendungsfälle ab. VMware hat NSX seit 2012 nach der Übernahme des Startups Nicira im Portfolio. NSX verlagert Netzwerk und Sicherheit näher an die Anwendungen, unabhängig davon, ob die Workloads im eigenen Rechenzentrum, in der Cloud oder bei einem Service Provider laufen. Die Anwendungsfälle sind Sicherheit, Netzwerkvirtualisierung mit Overlaytechnologie von GENEVE, Automatisierung, Container und Multicloud. Im Gegensatz zu anderen Herstellern agiert VMware dabei unabhängig von IP-Adressen, der Netzwerkinfrastruktur oder Agents. Die Kommunikationen von zwei virtuellen Maschinen im gleichen IP-Netzbereich (etwa 10.20.20.0/24) lässt sich daher direkt voneinander am Hypervisor schützen. Für eine virtuelle Maschine wird die Firewallfunktion an jeder einzelnen virtuellen Netzwerkschnittstelle abgebildet.

Mikrosegmentierung ist ein wichtiger Bestandteil auf dem Weg zum Zero-Trust-Sicherheitsmodell. Vereinfacht ausgedrückt bedeutet Zero Trust: Vertraue keinem Gerät und vertraue keinem Benutzer, unabhängig davon, ob es sich um eine externe oder interne Kommunikation handelt. Der Zugang wird für jeden Benutzer und jedes System ständig neu bewertet und alle Geräte und Benutzer-identitäten durchlaufen eine Multifaktor-Überprüfung. Zero Trust geht aber noch weiter, denn es überwacht, wie sich ein Gerät und ein Benutzer in einem Netzwerk verhalten. Folgende Fragen müssen Sie stellen: Von welchem Standort aus greift ein Benutzer oder Gerät beispielsweise auf Daten zu? Gilt der Zugriff auf diese Daten als normales Verhalten für diesen Benutzer oder dieses Gerät? Nur wenn die Antworten auf diese Fragen akzeptabel sind, ist der erforderliche Mindestzugang für diese spezifische Aktivität zu gewähren.

Einige grundlegende Prinzipien der Cyberhygiene für Zero Trust sind:

- Härtung und Patching: Halten Sie Ihre Systeme auf dem neuesten Stand und warten Sie diese konsequent. Jedes kritische System, das nicht mehr auf dem neuesten Stand ist, stellt ein erhebliches Sicherheitsrisiko dar.

- Multifaktor-Authentifizierung: Überprüfen Sie Benutzer- und Systemkomponenten mit mehreren Faktoren (nicht nur mit einfachen Passwörtern) unter Einbeziehung des Risikos, das mit dem gewünschten Zugriff oder der Funktion verbunden ist.

- Least Privilege: Erlauben Sie den Benutzern nur den minimal notwendigen Zugriff, um ihre Arbeit auszuführen, und nicht mehr. Systemkomponenten sollten nur die minimal erforderliche Funktion beinhalten.

- Verschlüsselung: Verschlüsseln Sie alle Daten, egal ob sie gespeichert oder übertragen werden. Im Fall einer Datenpanne sollten kritische Dateien nur zu unlesbaren Daten führen.

- Mikrosegmentierung: Unterteilen Sie die gesamte IT-Umgebung in kleinere Teile. Falls ein Teil kompromittiert wird, können Sie den Schaden zudem besser begrenzen.

Grundsätzlich ist die Mikrosegmentierung bei NSX bereits von Anfang an verfügbar. Die initiale Version NSX vor vSphere (NSX-v) unterstützte ausschließlich vSphere als Hypervisor und beinhaltete keine Unterstützung für die Absicherung von Workloads, die in Containern abgebildet waren. Seit 2017 ist die aktuelle Version NSX-T auf dem Markt und unterstützt neben ESXi auch Bare-Metal-Server (CentOS Linux, Red Hat Enterprise Linux, Oracle Linux, SUSE Linux Enterprise Server, Ubuntu und Windows Server). Bevor Sie NSX installieren, sollten Sie die jeweiligen Versions- und Hardwareanforderungen im "Installation Guide" von VMware verifizieren [1].

NSX Mikrosegmentierungsfunktion wird von VMware "Distributed Firewall" genannt. Das "Distributed" ist eine Herleitung von der Hypervisor-basierenden Firewallanwendung, das heißt, es existiert eine Firewall-Engine direkt im ESXi-Host (Bild 1). Die DPI-(Deep Packet Inspection)-Engine bildet das L7-Stateful-Firewall-Feature ab. So kann etwa in einer Policy die TLS-Version 1.3 erlaubt und alle darunter liegenden TLS-Versionen geblockt werden.

Da viele Firmen nicht das komplette Routing inklusive der Overlay-Funktionen von NSX nutzen möchten und die Implementierung in eine bestehende Umgebung nicht ohne weiteres umzusetzen ist, hat VMware seit der NSX-T-Version 3.2, die seit Dezember 2021 verfügbar ist, die Möglichkeit bereitgestellt, die "NSX Distributed Firewall" (DFW) Switch-agnostisch zu konfigurieren. Dies bedeutet einerseits, dass sich die bestehenden Portgruppen eines vSphere-Distributed-Switch (VDS) nutzen lassen, und andererseits, dass über ein NSX-Plug-in im vCenter die Installation und spätere Konfigurationen von NSX möglich sind.

NSX-T 3.1 und frühere NSX-T-Versionen hatten bereits VLAN-basierte als auch Netzwerk-Overlay-basierte Netzwerk-segmente für Mikrosegmentierung unterstützt. Workloads, die mit VDS-spezifischen VLAN-Netzwerken (also mit verteilten virtuellen Port-Gruppen) verbunden sind, wurden jedoch nicht direkt für Mikrosegmentierungszwecke unterstützt. NSX-T-Administratoren mussten diese Workloads zunächst in der NSX-Management-GUI auf NSX-VLAN-Segmente migrieren. Sicherheitsteams, die eine verteilte Firewall für VDS-basierte VLAN-Netzwerke bereitstellen, haben die Migration von VDS Portgruppen zu NSX VLAN-Segmenten als schwierig empfunden, da der Prozess die Zusammenarbeit mit dem Netzwerkteam als obligatorischen ersten Schritt erforderte, bevor die Sicherheits-Workflows in Angriff genommen werden konnten.

Da sich wie erwähnt die NSX-Distributed-Firewall VDS an Organisationen mit reinen Sicherheitsanforderungen in bestehenden Umgebungen richtet, ist bei dieser Variante in Zukunft keine Migration auf die NSX-Overlay-Technologie möglich; dies sollte im Vorfeld beachtet werden. Außerdem sind folgende Punkte als Voraussetzung für die Installation notwendig:

- NSX-T Data Center Version 3.2 oder höher

- Das NSX-Plug-in im vCenter benötigt mindestens die vSphere Version 7.0.3 oder höher

- ESXi-Version 6.7 und 7.0 wird unterstützt (NSX-Plug-in jedoch nur ab vSphere 7.0.3)

- Installation eines VDS (vSphere Distributed Switch) mit Version 6.6 oder höher

- Für die Bereitstellung einer "thick disk" muss auf dem Host mindestens 300 GByte freier Speicherplatz bereitstehen

- Der vCenter muss als Compute Manager im NSX eingetragen werden (automatischer Prozess)

- Zwischen dem NSX-Manager und dem vCenter gibt es eine 1:1 Beziehung, der NSX-Manager kann daher keine zusätzlichen vCenter administrieren.

Außerdem sollten Sie vorab die Spezifikationen der IP-Adressen, NTP-Server, DNS-Server und Domain Search List heraussuchen. Für den NSX-Manager müssen Sie einen Eintrag im DNS-Server erstellen. Im ersten Schritt laden Sie die Software des NSX-Managers vom VM-ware-Portal herunter. Wählen Sie hierfür die OVA-Datei (Open Virtual Appliance) namens "NSX Manager with vCenter

Plugin" [2]. Anschließend starten Sie direkt aus dem vCenter über das NSX-Plug-in die NSX-Manager-Installation. Nun beginnt die Konfiguration der NSX-Manager-Appliance. Hierbei führt Sie der Wizard durch insgesamt acht verschiedene Menüpunkte (Bild 2). Der erste Schritt ist das Auswählen der lokalen Installationsdatei, die Sie zuvor heruntergeladen haben. Anschließend definieren Sie den Namen der virtuellen Maschine und der Ordner im vCenter. Nachdem Sie die Compute-Ressourcen vergeben haben, werden im vierten Punkt die Installationsschritte von eins bis drei verifiziert.

Danach legen Sie die Größe der Appliance fest. Hierbei stehen die Optionen "Extra Small", "Small", "Medium" und "Large" zur Verfügung. "Extra Small" ist nur für die "NSX Cloud"-Variante spezifiziert und "Small" nur für Testumgebungen unterstützt. NSX Cloud dient dazu, über die NSX-Managementumgebung im eigenen Rechenzentrum native Firewallregeln in AWS oder Azure zu verwalten. "Medium" ist für eine Umgebung mit bis zu 128 Hypervisoren ausgelegt und "Large" für Installationen ab 128 Hypervisoren.

Im sechsten Schritt geben Sie die Quelle des Speicherplatzes an. Nun werden die Netzwerkparameter abgefragt wie Portgruppe, Hostname, die IP-Adresse, Subnetmaske, Default-Gateway, DNS-Server, Domain Search List und NTP Server. Anschließend erfolgt die Vergabe verschiedener Passwörter. Diese müssen mindestens zwölf Zeichen lang sein und gewisse Sicherheitsanforderungen inklusive Sonderzeichen erfüllen. Nach Abschluss der OVA-Konfiguration wird die virtuelle Maschine ausgerollt. Den zeitlichen Vorgang können Sie im vCenter unter dem Fenster "Task" beobachten.

Aktuell wird nur ein NSX-Manager mit der NSX-Security-VDS-Konfiguration implementiert. Bei einer standardmäßigen NSX-Installation bilden drei Manager einen Cluster. Datenbanken und Konfigurationen werden dementsprechend synchronisiert. Der Manager-Cluster wird über eine virtuelle IP-Adresse (VIP) angesprochen. Am Cluster sind die Management-Plane- und Control-Plane-Funktion intern komplett separiert (Bild 3). Die Management-Kommunikation vom Manager zum ESXi-Host findet über den TCP-Port 1234 statt. Die Control-Plane-Funktion vom Manager zum ESXi-Host läuft über TCP-Port 1235. Die Firewallregeln werden über die Control-Plane-Konnektivität gepusht beziehungsweise administriert. Wenn Sie eine virtuelle Maschine von Host zu Host via vMotion verschieben, pusht NSX automatisch die Firewallregeln zum neuen ESXi-Host.

Nun ist der Manager mittels HTTPS bereits über den Browser erreichbar. Gehen Sie in der Manager-GUI auf den Menüpunkt "NSX License Key" und tragen Sie den Lizenzschlüssel ein. VMware bietet hierzu dedizierte Lizenzen für Kunden an, die nur die Sicherheitsfeatures von NSX nutzen möchten. Die genauen Spezifikationen können Sie im VMware-Knowledge-Base-Artikel 87077 [3] nachlesen. Als Nächstes haben Sie am vCenter über das NSX-Plug-in die Wahl zwischen "Security Only" und "Virtual Networking". Starten Sie für den Sicherheitsanwendungsfall die "Security Only"-Option. Die "Virtual Networking"-Variante konfiguriert ein standardisiertes Routing- und Switching-Konstrukt.

Jetzt folgt das Präparieren der Hosts für NSX über die vCenter-GUI. Hierbei wird ein sogenanntes VIB (vSphere Installation Bundle) ausgerollt. Sie können die ESXi-VIB-Installation pro vSphere-Cluster auswählen; dedizierte einzelne ESXi-Host wie bei der generellen NSX-Variante lassen sich nicht selektieren.

Die Grundinstallation der NSX-Security-VDS-Version ist damit abgeschlossen. Der Manager-Cluster korrespondiert mit den ESXi-Hosts. Eine erfolgreiche Kommunikation können Sie in der Manager-GUI unter "System / Fabric / Host Transport Nodes" verifizieren. Alternativ verbinden Sie sich per SSH auf den ESXi-Host und führen folgende Befehle zur Überprüfung der Konfiguration aus:

1. vSphere Installation Bundle: esxcli software vib list | grep nsxt

2. Management-Plane-Kommunikation vom NSX-Manager zum ESXi-Host: esxcli network ip connection list |grep 1234

3. Control-Plane-Kommunikation vom Manager zum ESXi-Host: esxcli network ip connection list |grep 1235

Im Fall eines Fehlers sind diese Befehle ebenfalls sehr nützlich und geben beispielsweise Aufschluss, wenn ein Datenstrom zwischen ESXi-Host und NSX-Manager nicht funktioniert oder falls ein Service am ESXi-Host nicht startet.

Das vCenter-Installations-Plug-in hat derweil bei unserem Setup im Hintergrund einige Objekte über API-Calls am NSX-Manager angelegt. Auch wurde der "Compute Manager" (vCenter) implementiert, um die Kommunikation zwischen vCenter und NSX-Manager zu gewährleisten. Schließlich wurde eine Transportzone und ein "Transport Node Profile" erzeugt. Sie können diese Konfiguration am NSX-Manager verifizieren.

Über einen Wizard im vCenter beginnen Sie nun mit der Konfiguration der NSX-Firewallregeln. Das Setup ist in drei Schritte unterteilt:

1. Erstellen von Securitygruppen

2. Definieren der Kommunikationen beziehungsweise Regelwerke

3. Prüfen und Konfigurieren

Als Erstes erstellen Sie die Infrastruktur-Securitygruppen. Sie legen dabei eine oder mehrere Gruppen für Infrastrukturdienste wie DNS, AD, DHCP oder NTP an.

Dabei besteht die Möglichkeit, über verschiedene Kriterien virtuelle Maschinen in die Securitygruppe aufzunehmen. Im Wizard wird automatisiert für die Securitygruppe ein Tag erzeugt. Durch das Anhaken weisen Sie den Tag der jeweiligen virtuellen Maschine zu. Alternativ können Sie über IP-Adressen oder Portgruppen Systeme in Gruppen zuordnen. Außerhalb des Wizards besteht die Möglichkeit, mit dynamischen oder statischen Elementen zu arbeiten. Die dynamische Gruppeneinbindung für VMs kann auf Tags, Rechnernamen, Betriebssystemnamen oder Computernamen basieren. Statische Kriterien für Gruppen gelten für VMs, VIFs, Segmente, Segmentports, IP-Sets, MAC-Sets, AD-Benutzergruppen, physische Server und verschachtelte Gruppen.

Anschließend definieren Sie die sogenannten "Environment Groups". Dies sind Securitygruppen, die verschiedene Bereiche wie beispielsweise Produktion, Test und Entwicklung abgrenzen. Auch hier weisen Sie bestimmte Workloads der jeweiligen Sicherheitsgruppen zu. Zuletzt erstellen Sie die "Application Groups". Hier legen Sie Securitygruppen für dedizierte Applikationen fest, die in Ihrem Unternehmen im Einsatz sind.

Nun beginnen Sie mit dem Erstellen der Firewallregeln. Dieser Konfigurationsabschnitt unterteilt sich in drei Schritte (Bild 4):

1. Zugriff auf die Infrastrukturdienste

2. Festlegen der Kommunikationsbeziehungen zwischen den verschiedenen Umgebungen

3. Definieren der Aktion am Ende des Firewallregelsatzes

Zuerst richten Sie den Zugriff auf die Infrastrukturdienste ein. Als Quellangabe kommt hierbei generell "any" zum Einsatz, da alle Komponenten Zugriff auf DNS, AD, DHCP und NTP benötigen. Als Zielangabe definieren Sie die Infrastrukturgruppen, die Sie zuvor festgelegt haben. Es bleibt Ihnen freigestellt, ob Sie dedizierte Gruppen beispielsweise für DNS nutzen oder eine Gruppe für alle Infrastrukturdienste. Alternativ können Sie auch mit "Child"-Gruppen arbeiten, so etwa eine "Infra"-Gruppe festlegen und darin eine Gruppe für DNS, eine für AD, eine für NTP und eine für DHCP definieren.

Im nächsten Schritt legen Sie die Kommunikation zwischen verschiedenen Umgebungen fest. Sie können etwa definieren, dass die Produktionsumgebung nicht mit der Testumgebung sprechen darf. Anschließend müssen Sie die "Default"-Regel konfigurieren, die am Ende des Firewallregelsatzes greifen soll. Diese setzen Sie zum Beispiel auf "deny all" und verbieten damit alles, was nicht explizit erlaubt ist. Wir empfehlen hierzu, die "Default"-Regel zunächst auf "permit all" zu konfigurieren und das Logging für die Regel zu aktivieren. Dadurch lässt sich in den Logdateien verifizieren, ob Kommunikationen in der "Default"-Regel auftauchen, die eigentlich erlaubt sein sollten. Wenn nur noch ungewollte Zugriffe in dieser Regel auflaufen, können Sie die Methode auf Blockieren umstellen.

Als letzten Punkt überprüfen Sie die Konfigurationen aus dem Wizard nochmals und implementieren sie über den Button "Publish". Anschließend werden Sie über das vCenter-Plug-in direkt auf die NSX-Manager-GUI umgeleitet. Hier können Sie Ihre Securitygruppen, Tags, Gruppenmitgliedschaften und Firewallregeln nochmal anschauen und bei Bedarf anpassen. Sie haben nun innerhalb kurzer Zeit in einer bestehenden Umgebung mit kleinem Aufwand eine Softwarefirewall implementiert. Im Anschluss lassen sich über den NSX-Manager weitere Firewallregeln definieren.

Als zusätzliche Sicherheitsfunktionen am Hypervisor können Sie nun die Features IDPS (Intrusion Detection Prevention System) und Malware-Prevention aktivieren. Für das IDPS-Feature ist keine zusätzliche Management-Plane-Konfiguration notwendig. Die zentrale Komponente ist der NSX-Manager, während ESXi durch die initiale Distributed-Firewall-Implementation bereits für IDPS vorbereitet ist.

Für den Malwareschutz müssen Sie eine sogenannte "NSX Application Plattform" konfigurieren. NAPP benötigt für eine initiale Implementierung eine Kubernetes-Infrastruktur als Basisplattform. Kubernetes lässt sich über TANZU am Hypervisor bereitstellen oder als Vanilla-Kubernetes. Über die NAPP-Plattform werden weitere Funktionen wie NSX Intelligence, Network Traffic Analysis, Metrics und Network Detec-tion and Response zur Verfügung gestellt. Letztendlich bietet VMware mit Carbon Black EDR (Endpoint Detection and Response) noch eine Sicherheitslösung für Endpunkte an. Die übliche Bezeichnung lautet XDR (Extended Detection and Response), wenn Informationen vom Netzwerk und dem Endpunkt als Quelldaten für eine Sicherheitsplattform zur Verfügung gestellt werden. Nicht zuletzt besteht die Möglichkeit, eine Perimeterfirewall für den Schutz der Nord/Süd-Kommunikation zu konfigurieren. Die NSX-NGFW (Next-Generation Firewall) bildet Features wie TLS-Inspection, URL-Filterung, IDPS (Intrusion Detection Prevention System) und Malwareschutz ab.

Im Bereich Containerschutz nutzt VMware das NSX-Container-Plug-in (NCP) und Antrea als Container Network Interface (CNI). NCP ist spezifisch für NSX; eine NSX-Konfiguration ist zwingend notwendig. Antrea ist ein Open-Source-CNI und wurde von VMware für die Community bereitgestellt. Eine Integration von NSX und Antrea steht ebenfalls zur Verfügung. Da die Container-Technologie sehr dynamisch ist und Skalierung, Löschen und Neuprovisierung an der Tagesordnung sind, existieren hier nicht nur Anforderungen an die Sicherheit. Es müssen verschiedene Netze, Loadbalancing für interne und externe Kommunikation und NAT für den ausgehenden Verkehr zur Verfügung stehen. VMware bietet über TANZU die Möglichkeit, eine Kubernetes-Umgebung direkt am Hypervisor abzubilden. NSX sorgt hierbei für die notwendige Netzwerk- und Sicherheitsstruktur.

Dynamische Workloads bedürfen besonderer Schutzmechanismen. NSX bietet eine einfache Möglichkeit, Mikrosegmentierung ohne Ausfallzeit in bestehenden Umgebungen zu implementieren. Die Konfiguration im ESXi-Umfeld erfolgt ohne Agenten. Zudem können Bare-Metal-Server geschützt werden. Container lassen sich über die VMware-CNIs, NCP oder Antrea ebenfalls absichern.