NFV disaggregiert Firewall Appliance für mehr Skalierbarkeit
Eine traditionelle Firewall Appliance kann viele Services enthalten. Diese lassen sich mit NFV virtualisieren, so dass individuelle, besser skalierbare Services entstehen.
Network Functions Virtualization, kurz NFV, bleibt weiterhin ein viel diskutiertes Thema in der Netzwerkwelt, ist aber für Netzwerktechniker wie IT-Manager mitunter schwierig zu verstehen. Welche Arten von Funktionen lassen sich im Netzwerk virtualisieren, und wie gelingt dies? Prüfen wir einmal ein potenzielles Argument für den Einsatz von NFV: die Disaggregation der traditionellen Firewall Appliance.
In der Netzwerktechnik tendiert die Firewall zu einer Art Patentlösung. Wer Sicherheit benötigt oder auch nur ein Sicherheits-Audit bestehen will, installiert eine Firewall, konfiguriert sie – und das war's. Im Fall von Sicherheits-Compliance zirkulieren sogar Geschichten, dass jemand eine Firewall Appliance installiert und sie dann entweder so einrichtet, dass einfach kein Traffic durch das Gerät fließt, oder sie so konfiguriert, dass der gesamte Traffic, egal welcher Typ, durchgelassen wird. So lustig diese Anekdoten auch sein mögen, sie verdeutlichen eines der grundlegenden Probleme mit Firewalls: Sie gelten als Wundermittel bei Sicherheitsproblemen aller Art.
Um von einer Firewall Appliance auf eine virtualisierte Funktion umzusteigen, empfiehlt es sich, die Services zunächst genauer zu betrachten, die eine Firewall bietet. Zwar gibt es viele Optionen für Services, aber wir beschränken uns zur besseren Darstellung auf drei davon.
Der erste Service ist Stateful Filtering. Viele Anwendungsflüsse sind prinzipiell Stateful. Das bedeutet, der Client startet eine Sitzung, indem er eine bestimmte Folge von Signalen an den Server sendet, um eine Verbindung zu öffnen. Diese Verbindungen sind asymmetrisch. Dabei sendet der Client oder Server spezifische Anfragen auf einem Weg, und der Angesprochene antwortet, indem er bestimmte Informationen auf einem anderen Weg zurückschickt. Beim Stateful Filtering führt die Firewall Buch über diese Anfragen und Antworten, blockiert jedoch alle nicht angeforderten Antworten.
Der zweite Firewall-Service nennt sich Deep Packet Inspection (DPI). Hier untersucht die Firewall die Inhalte jedes Pakets, um bestimmte Probleme zu vermeiden oder Arten von Traffic zu blockieren. Zum Beispiel kann die Firewall nach spezifischen Anwendungen suchen, etwa Voice over IP (VoIP), die zu einem Host übertragen werden, der aus irgendeinem Grund diese Art von Traffic nicht akzeptiert. Durch Verwendung von DPI könnte die Firewall Pakete auch auf Virensignaturen oder ungewöhnliche Traffic-Muster untersuchen, die darauf hindeuten, dass ein Angriff stattfindet.
Abbildung 1: Ein Beispielnetzwerk mit einer einzigen, physischen Firewall für alle Services.
Zu guter Letzt übernehmen Firewalls häufig die Aufgabe, öffentliche und private Adressen per Network Address Translation (NAT) oder Adress- und Port-Paare per Port Address Translation (PAT) zu übersetzen. In einigen Fällen kann die Übersetzung von IPv4- und IPv6-Adressen zur Aufgabe gehören.
Obwohl viele Protokoll- und Anwendungsentwickler das Konzept der Adressübersetzung ablehnen, ist es nach wie vor ein wichtiger Bestandteil der Netzwerkinfrastruktur. Diese Übersetzung erlaubt die Kommunikation zwischen Netzwerken, die von überschneidenden privaten Adressräumen angesprochen werden, und liefert bei korrekter Anwendung ein mitunter recht nützliches Sicherheits-Tool.
Eine einzelne Firewall Appliance für jeden Service
Das Problem, das sich durch den Einsatz einer einzelnen physischen Firewall Appliance ergibt, lässt sich anhand Abbildung 1 erkennen.
Angenommen, Host A muss über dieses Netzwerk auf fünf verschiedene Services zugreifen. Herkömmlicherweise würde man eine Firewall (B) im Netzwerk unmittelbar vor – manchmal auch direkt hinter – dem Router platzieren. An dieser Position im Netzwerk empfängt die Firewall den gesamten Traffic, der an jeden dieser Services auf dem Server (D) gerichtet ist, und leitet ihn entsprechend weiter. Nehmen Sie jetzt an, dass die folgenden Richtlinien gelten:
Alle Pakete, die ins Netzwerk gelangen, durchlaufen einen DPI-Prozess, um zu gewährleisten, dass das Netzwerk vor potenziellen Viren und anderen allgemeinen Attacken geschützt ist.
Die Services 1 und 2 werden von einem privaten Adressraum aus angesprochen, so dass alle Datenströme zu und von diesen zwei Services einen Adressübersetzer durchlaufen müssen.
Bei den Services 3, 4 und 5 handelt es sich um Stateful Services. Jeder von ihnen besitzt einen anwendungsspezifischen Status, der beobachtet werden muss, um den Server und Anwender vor Man-in-the-Middle- und sonstigen Angriffen zu schützen.
Die oben beschriebene einzelne Firewall Appliance muss mit den richtigen Policies konfiguriert werden, damit all diese unterschiedlichen Anforderungen erfüllt werden. Um das zu erreichen, müssen DPI, Adressübersetzung und Stateful Filtering auf der Firewall eingerichtet werden. Policies, die bestimmte Datenströme von der Adressübersetzung ausnehmen, müssen eingerichtet werden, wahrscheinlich pro Ziel-IP. Die Firewall muss jede der unterschiedlichen anwendungsspezifischen Stateful-Inspection-Routinen unterstützen.
Mehrere Firewalls für virtuelle Topologien
Um die Sache noch komplexer zu machen, muss die Firewall das Ganze in großem Maßstab unterstützen und sich upgraden lassen, ohne dass einer der Services ausfällt. Einiges davon kann man durch die Installation mehrerer Firewalls lösen, eine pro Service, vielleicht als virtuelle Maschinen im Netzwerk oder indem man virtuelle Topologien aufbaut und je eine Firewall dafür vorsieht. Abbildung 2 zeigt eine Option mit virtuellen Topologien.
Abbildung 2: Ein Beispielnetzwerk mit einer Firewall pro Service und virtuellen Topologien.
In diesem Netzwerk wurden mehrere virtuelle Topologien zwischen C und der virtuellen Maschine oder dem Container, in dem jeder Service läuft, eingerichtet. Für jede virtuelle Topologie wurde eine Firewall konfiguriert. Hierbei ergibt sich der Vorteil, dass sich servicespezifische Richtlinien nur für die Firewalls konfigurieren lassen, die sie auch benötigen. So müssen etwa nur die zwei Firewalls für die virtuellen Topologien, die C mit S1 und S2 verbinden, mit Adressübersetzung konfiguriert werden. Zudem kann jede Firewall aktualisiert werden, ohne dass alle Services betroffen sind, und jede Firewall kann bei Bedarf mit dem Service skalieren.
Allerdings hat diese Konfiguration zwei entscheidende Nachteile. Erstens muss jede Firewall noch immer die gesamten Services unterstützen. Egal, ob es sich um physische oder virtuelle Appliances handelt, der Netzwerkbetreiber möchte zwecks einfacher Handhabung in der Lage sein, das gleiche Gerät an jedem Standort zu nutzen. Daher muss es sich bei jeder Netzwerk-Firewall um die gleiche Art von Gerät handeln, und sie muss die gleiche Art von Services unterstützen.
Was, wenn diese Services von der Firewall Appliance disaggregiert und als separater Service erstellt würden?
Der zweite Nachteil liegt darin, dass jeder Service, der unter allen Services häufig geteilt wird, auf jeder Firewall im Netzwerk konfiguriert werden muss. Außerdem muss die Konfiguration unter all diesen Geräten synchronisiert werden. Das lässt sich zwar leicht automatisieren, ist aber unnötig komplex.
Disaggregation der Firewall Appliance in separate Services
Beschäftigen wir uns damit, wie dieses Problem auf sinnvollere Weise gelöst werden kann. Ein Schritt auf dem Weg in die richtige Richtung besteht darin, nicht nur die Firewall zu virtualisieren, sondern sie in ihre einzelnen Servicekomponenten aufzuteilen. Erinnern Sie sich daran, dass in unserem Beispiel die Firewall aus drei Services besteht: DPI, Adressübersetzung und Stateful Filtering.
Was, wenn diese Services von der Firewall Appliance disaggregiert und als separater Service erstellt würden? Dann könnte man einzelne Firewall-Dienste dort ins Netzwerk einfügen, wo sie benötigt werden, und entsprechend konfigurieren. Jeder Firewall-Dienst würde alle Optionen für diesen speziellen Service bieten, aber nichts außerhalb genau dieses einen Service unterstützen und dadurch die Einrichtung vereinfachen. Die Abbildung 3 veranschaulicht diese Art der Virtualisierung.
Abbildung 3: Ein Beispielnetzwerk mit virtualisierten Firewall-Komponenten, wo sie erforderlich sind.
In diesem Netzwerk verfügt jede virtuelle Topologie jetzt über die Menge an Services, die auf den Anforderungen jeder Anwendung basieren. Alle virtuellen Netzwerke haben einen DPI-Service mit jeweils identischen Konfigurationen. Indem ein DPI-Service pro virtuellem Netzwerk zur Verfügung steht, kann dieser Service bei Bedarf entsprechend dem Traffic-Niveau und der Anzahl der angebotenen Services skalieren. Die Services 1 und 2 besitzen zwei unterschiedliche NAT-Instanzen. Beide könnten entweder gleich konfiguriert sein oder eine pro Service angepasste Konfiguration aufweisen. S3, S4 und S5 schließlich besitzen alle separate Stateful-Inspection-Services.
Indem man die Firewall Appliance in verschiedene Services aufteilt, diese anschließend virtualisiert, so dass sich mehrere Kopien erstellen und in die virtuellen Topologien einfügen lassen, können die Services entsprechend den Anforderungen der Anwendungen skalieren – und so spezifisch sein, dass die erforderlichen Services dort zum Einsatz kommen, wo sie benötigt werden.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
