Wie Sie NSX-Firewall-Regeln optimal konfigurieren

Die Vorteile von NSX-Firewalls

Die verteilte Firewall (Distributed Firewall, DFW) von VMware NSX bietet Firewall-Schutz dort, wo die virtuelle Infrastruktur ihn am meisten benötigt: auf einzelnen VMs. Sie können Firewalls unter Windows oder Linux verwenden. Aber diese Host Firewalls verfügen über keine zentralisierte, herstellerübergreifende Konfigurationsfunktion.

Diese Host Firewalls lassen sich nicht so konfigurieren, dass sie den Traffic zwischen einzelnen VMs einschränken. Ihnen fehlt der Überblick über die gesamte virtuelle Infrastruktur, und eine zentralisierte Firewall hat keinen Einblick in die Beziehung zwischen VMs, um Traffic zuzulassen oder zu blockieren. Wenn Sie eine zentralisierte Firewall im Netzwerk einsetzen, muss das System den gesamten Traffic durch die Host Firewall transportieren, was zu Netzwerk-Overhead und Latenz führen kann.

Die DFW von NSX ist im Hypervisor-Kernel aktiv und wird auf jedem VM-Netzwerkadapter erzwungen. Diese Einstellung kann dazu beitragen, eine laterale Bewegung zwischen VMs einzuschränken, und ermöglicht eine zentralisierte Konfigurationsfunktion unabhängig von Betriebssystemen und Anwendungen.

Verteilte Firewalls bilden einen wichtigen Verteidigungsmechanismus in einer virtuellen Infrastruktur, da sie den Ost-West-Traffic schützen. Darüber hinaus schützt die Gateway Firewall von NSX-T Data Center den Nord-Süd-Traffic am Netzwerk-Edge, bevor er zum Hypervisor gelangt.

Erste Schritte mit NSX-Firewall-Regeln

Um diese virtualisierte Firewall zu nutzen, müssen Sie NSX inklusive NSX Manager vollständig bereitstellen und die Hypervisoren konfigurieren. Die NSX-DFW läuft sowohl auf ESXi als auch auf Kernel-basierten VMs.

NSX-Benutzer können die Gateway Firewall für Stateful Services einsetzen, weil die Firewall selbst ein Stateful Service ist. NSX erstellt Firewall-Regeln für Gateways ähnlich wie Regeln für verteilte Firewalls. Sie finden Gateway-Firewall-Regeln unter dem Abschnitt für die Nord-Süd-Sicherheit in der NSX-Administratoroberfläche. Der Hauptunterschied besteht darin, dass es kein Feld Applied To gibt, da NSX die Regeln am Netzwerk-Edge anwendet und durchsetzt, wo sich das Gateway befindet. Dennoch ist es bei einem Tier-0-Gateway im Active-Active-Modus nicht möglich, eine Stateful Firewall zum Routing-Pfad hinzuzufügen.

NSX verarbeitet Firewall-Regeln sowohl für verteilte als auch für Gateway Firewalls mithilfe der folgenden fünf Kategorien: Ethernet, Emergency, Infrastructure, Environment und Application (siehe Abbildung 1). Die einzelnen Regeln sind in einer Gesamtliste gestapelt und werden innerhalb dieser Kategorien von oben nach unten ausgeführt. Die Pfeile in den Kategorietiteln geben von links nach rechts die Reihenfolge an, in der die Verarbeitung der Firewall-Regeln erfolgt, beginnend mit der Kategorie Ethernet beziehungsweise Layer 2.

Wenn der Netzwerk-Traffic eine Firewall durchläuft und das System eine Regel findet, die mit den Traffic-Parametern übereinstimmt, setzt das System die Regel durch, und die Verarbeitung wird angehalten. Bei passenden Regeln wird der Traffic je nach Konfiguration entweder durchgelassen oder blockiert.

Administratoren des NSX-T Data Centers können die Regeln in der Ansicht Category Specific Rules verwalten. In der Ansicht All Rules werden alle Regeln für verteilte Firewalls in einer einzigen Liste angezeigt, geordnet nach ihrer endgültigen Reihenfolge.

Abbildung 2 zeigt eine Liste von Firewall-Regeln, die mit Default Layer 3 Rule (Standardregel für Layer 3) endet. Dies ist die letzte Regel, die in der Application-Kategorie verarbeitet wird, wenn keine andere Regel mit einem Traffic-Parameter übereinstimmt. Die Standardregel für Layer 3 lässt den gesamten Traffic durch das Netzwerk passieren. Dies macht die NSX-Bereitstellung komfortabel, da die Systeme wie gewohnt ohne Einschränkungen funktionieren. Wäre die Regel so eingestellt, dass der Traffic blockiert wird, käme es sofort zu einer Unterbrechung von Systemen und Anwendungen.

Als Best Practice empfiehlt sich ein Allowlist-Ansatz, bei dem die Standardregel so konfiguriert wird, dass der gesamte Traffic außer dem explizit erlaubten blockiert wird. Mit einem Allowlist-Ansatz bleiben VMs durch die Firewall geschützt. Wenn Sie jedoch vergessen, eine Regel zu konfigurieren, beschweren sich Nutzer möglicherweise darüber, dass eine Anwendung nicht funktioniert, weil Sie deren Traffic versehentlich blockiert haben.

So konfigurieren Sie Firewall-Regeln

NSX fasst Firewall-Regeln zu Richtlinien zusammen. Der Administrator kann Firewall-Regeln nach beliebigen Kriterien gruppieren. Abbildung 3 zeigt ein Beispiel für eine Richtlinie mit einer Sammlung von Regeln für eine mehrschichtige Anwendung mit dem Namen Phoenix.

Firewall-Gruppen erleichtern die Identifizierung von Firewall-Regeln, die Deaktivierung einer gesamten Richtlinie und die Konfiguration einer Richtlinie für die datums- und zeitbasierte Aktivierung. Verwenden Sie das Uhrensymbol in der Titelleiste der Richtlinie, um datums- und zeitspezifische Einstellungen zu erreichen.

Der Aufbau von Firewall-Regeln umfasst eine Quelle, ein Ziel, den Dienst, der zur Verarbeitung der Regeln verwendet wird, sowie die Aktionen für das Zulassen, Verwerfen und Zurückweisen. Im Allgemeinen arbeiten alle Firewalls auf diese Weise. Zusätzlich kann die NSX-DFW auch VMs gruppieren und diese Gruppen in den Feldern für die Quelle und das Ziel verwenden.

In Abbildung 3 verwendet NSX Policy-Gruppen für die Webserver, App-Server und Datenbankserver von Phoenix. Wenn Sie der virtuellen Infrastruktur eine VM als Webserver für diesen Anwendung-Stack hinzufügen, wird die VM zur Gruppe der Webserver hinzugefügt. Die für Webserver bestimmte Firewall-Regel schützt die VM dann unabhängig davon, wo sie ausgeführt wird. Auch ihr Netzwerkstandort und ihre IP-Adresse spielen keine Rolle.

Das Feld Applied To, das in Abbildung 3 zu sehen ist, erzwingt automatisch Firewall-Regeln für die gesamte NSX Distributed Firewall, sofern nicht anders konfiguriert. Das bedeutet, dass Firewall-Regeln für alle VMs gelten – NSX platziert diese Regeln auf den VMs, auch wenn die Regeln nicht erforderlich sind. Stellen Sie sicher, dass die VM-Gruppen im Quell- wie im Zielfeld im Feld Applied To stehen. Dadurch wird gewährleistet, dass NSX nur dort Regeln auf VMs platziert, wo dies nötig ist.

Das Service- und Profilfeld sind weitere einzigartige Merkmale der NSX-DFW. Das Servicefeld ist die Layer-4-Servicedefinition für einen Dienst oder Port, zum Beispiel TCP-Port 22 für Secure Shell (SSH) und TCP-Port 443 für HTTPS. Das Profilfeld stellt die Layer-7-Firewall-Funktionalität dar. Dort können Sie vordefinierte Anwendungen auswählen, etwa SSH oder HTTPS. Wenn die NSX-DFW Pakete auswertet, identifiziert sie Anwendungen anhand der Pakete und erlaubt oder blockiert den Traffic aufgrund der Anwendungs-ID, unabhängig vom verwendeten Port. Wenn beispielsweise SSH Port 80 statt Port 22 nutzt, blockiert die NSX-DFW trotzdem den Traffic.

So verwalten Sie Firewall-Regeln

Wenn Sie Firewall-Regeln für die NSX-DFW oder die Gateway Firewall erstellen, sind diese nur verfügbar, wenn Sie oben auf der Konfigurationsseite auf die Schaltfläche Publish klicken. Neue oder geänderte Regeln sind erst dann aktiv und wirken sich auf die virtuelle Infrastruktur aus, wenn Sie sie veröffentlichen.

Die NSX-Benutzeroberfläche enthält eine Funktion, um alle Änderungen an Firewall-Regeln rückgängig zu machen. Jedes Mal, wenn ein Administrator Firewall-Regeln veröffentlicht, speichert NSX automatisch Kopien der Regelsätze. Sie können zuvor gespeicherte Regeln bei Bedarf überprüfen und wiederherstellen. Abbildung 4 zeigt ein Beispiel für gespeicherte Regeln, die innerhalb eines einzigen Tages erstellt wurden. Jeder Punkt im Diagramm stellt einen Zeitstempel für gespeicherte Firewall-Regeln dar.

Wenn Sie auf einen Punkt klicken, zeigt das Diagramm die Änderungen an, die in dieser Version vorgenommen wurden. Mit diesen Informationen lassen sich Regeln reparieren und neu erstellen. Außerdem können Sie bei Bedarf einen kompletten Regelsatz auf eine frühere Version zurücksetzen.