Viele von uns sind jetzt die Arbeit mit virtuellen Firewalls. Ich habe einem früheren Beitrag über die Stärken und Schwächen der Sicherheit innerhalb der virtuellen Welt , aber heute möchte ich über die Firewall-Möglichkeiten mit VMware zu sprechen. Es hat eine Menge Aufregung in Bezug auf VMware ist relativ neu gewesen VMsafe API . Insbesondere ist jeder Scrambling zu erstellen / deploy schnelle Weg Firewalls. Aber sind alle Fast-Path-Implementierungen gleich? Gibt es Sicherheitsbedenken mit dem Gehen mit einer schnellen Weg Lösung? Lassen Sie uns in Tauch-und zu sehen.
Aufgliederung der VMsafe
Mit der Veröffentlichung des VMsafe Security API hat VMware die verfügbaren Optionen für die Implementierung der Sicherheit in einer vSphere-Umgebung durch die Möglichkeit Anbieter direkt Stecker in den Hypervisor in Ring 0 erweitert. VMsafe besteht aus drei Komponenten:
- VDDK - Disk Block Inspektion. API wurde öffentlich freigegeben.
- vCompute - CPU und Speicher-API. Wurde nicht öffentlich freigegeben. Unknown denen Dritte Zugang haben, wenn überhaupt.
- vNetwork - API zur Überwachung / Filter zwischen dem vNIC und vSwitch. Wurde nicht öffentlich freigegeben. Um das Beste aus meinem Wissen, nur Altor Networks & Reflex-Systeme Zugriff haben (zwei Anbieter, die in der Entwicklung des API unterstützt werden).
Insbesondere möchte ich auf die vNetwork API zu sprechen. Bei der Steuerung des Netzwerkverkehrs Strömung innerhalb eines ESX-Hosts gibt es zwei mögliche Umsetzung, "slow-Pfad" und "Fast-Path".
Langsamen Pfad
Langsame Bahn ist die einfachste Implementierung und die, die wir seit Jahren mit. Effektiv ist das nur ein VM-Gast, wie jede andere VM-Gast, auf dem ESX-Host. In der Regel jeden Gast ist ein einzigartiges vSwitch verbunden, und jede dieser vSwitches ist eine einzigartige vNIC auf der Firewall verbunden. Dies ist vergleichbar mit einem Legacy-Firewall-Setup, aber umgesetzt praktisch. Der Vorteil der Ausführung in langsamen Pfad ist, dass man eine volle Schlag OS mit allen Bibliotheken oder Dienstleistungen benötigt, um die Firewall-Unterstützung laufen.
Fast Path
Schneller Weg ist tatsächlich ein Ring 0 Treiber, der direkt in den Hypervisor-Kernel. Dies ermöglicht einen Drittanbieter zu nutzen, den Hypervisor zum Einbau zwischen den einzelnen vNIC / vSwitch Verbindung. Da ein schneller Weg Treiber im Kernel-Kontext ausgeführt wird, fügt es einen minimalen Aufwand in das System. Das Ergebnis ist die Ausführung von Code innerhalb schnelle Weg ist wesentlich schneller als der gleiche Code in langsamen Pfad der Ausführung (also die VMware Namenskonvention für jeden Kontext). Last auf dem ESX-Host wird minimiert, so das Endergebnis ist, können Sie weit mehr virtuelle Gäste ausführen.
Schnelle Vs Langsame
So klingt es wie Sie möchten, um alles in schnellen Weg zu tun, aber es gibt eine Reihe von Fragen. Schneller Weg ist ein Kernel-Treiber Einstecken in eine minimierte Hypervisor, nicht eine volle Schlag-Betriebssystem. Dies schränkt die Bibliotheken und Dienste die Firewall zur Steuerung des Verkehrsflusses. Darüber hinaus sind wir in der Kernel-Treiber Einstecken so muss es versichert, dass es nicht aufblähen wird der Hypervisor, erhöhen die Angriffsfläche stört, oder mit anderen Funktionen Hypervisor werden. VMware führt eine Code-Review für alle Fast-Path-Treiber vor dem Release. Also, wenn ich könnte theoretisch umzusetzen alle meine Code in schnellen Weg, brauche ich VMware Genehmigung vor jedem Patch oder Feature Release.
In diesem Sinne, ist ein Anbieter behaupten "schnellen Weg" zu unterstützen eigentlich vor sich geht, um am Ende der Umsetzung einen Teil ihres Codes als schnelle Weg, einen Teil als langsame Weg, und erstellen Sie einen Anschluss zwischen den beiden. Wie viel Last auf dem System platziert, wie viel dieses Codes ist in schnellen Weg umgesetzt und wie viel davon ist in langsamen Pfad ausgeführt abhängen wird.
Mögliche Fast Path-Bereitstellungen
Zum Beispiel könnte ein Anbieter wählen, um einen schnellen Weg-Treiber zu schreiben, die einfach Tunnels alle Pakete wieder zu einem langsamen Pfad implementiert Firewall. Der langsame Weg-Code bestimmt dann, ob der Verkehr sollte weitergegeben oder gelöscht werden, mit übergebenen Pakete zurück zu den Fast-Path-Code zum Einfügen geschickt in die Hypervisor-Kontroll-Kanal. Während dies die einfachste Methode der Bereitstellung von schnellen Weg, und der wohl sichersten wäre es am wenigsten Performance-Vorteile bieten. Systemauslastung wäre wahrscheinlich nicht viel besser als eine vollständige langsamen Pfad Umsetzung. Ich sehe diese Option als sehr attraktiv für ältere Firewall-Anbieter, da sie die geringsten Änderungen an ihren vorhandenen Code erfordern würde, während noch in der Lage zu "Fast-Path-Unterstützung" zu verlangen.
Eine andere Möglichkeit wäre, den langsamen Pfad Raum für administrative Funktionen mit den schnellen Weg-Treiber als die Firewall-Engine verwenden. So zum Beispiel die Firewall-Administrator würde die Politik über eine Schnittstelle, die auf einem langsamen Pfad VM, die dann schieben würde die Politik auf eine schnelle Weg Treiber. In diesem Setup der schnelle Weg Treiber hat eine Kopie der Politik so Verkehrskontrolle sofort umgesetzt werden können. Das Ergebnis sind schnellere Verkehrsabwicklung mit minimaler Systembelastung. Die Trade-off ist sperriger Code am Ring 0.
Es ist auch möglich, eine Mischung der beiden zu implementieren. Zum Beispiel könnte ich der schnelle Weg Treiber verwenden, um die Firewall-Richtlinie umzusetzen, aber dann gehen alle "akzeptiert" Pakete zurück zu den langsamen Weg-System für Intrusion Überprüfung wird Virenscanner, oder was auch immer benötigt wird. Acceptable Pakete werden dann zurück in die Fast-Path-Treiber für die Insertion weitergegeben. So in diesem Setup alle "fallengelassen"-Pakete werden über schnelle Weg abgewickelt, während akzeptierte Pakete mit einem langsamen Pfad-Komponente zu interagieren.
As a side note, müssen Sie die oben genannten Informationen im Hinterkopf behalten, wenn man alle vNetwork-Implementierungen, nicht nur Firewalls. Die vNetwork API kann auch für Policy Enforcement, QoS, Sammeln von Netzwerk-Statistiken, etc. Zum Beispiel das erste vNetwork Umsetzung war eigentlich VMWare Lab Manager verwendet werden. Dieses Tool ist für Self-Service-Provisioning verwendet und enthält keine Firewall-Komponente (dies ist über vShield implementiert).
Zusammenfassung
Während ein VMware Produkt, das mit VMsafe integriert werden streng eine "langsame Weg" Umsetzung sein, ist es höchst unwahrscheinlich, dass ein Produkt betrachtet werden kann ausschließlich eine "schnelle Weg" Umsetzung sein. Jede schnelle Weg Produkt ist am ehesten zu einer hybriden werden. Es ist nur eine Frage davon, wie viel Code in der "schnellen Weg" Raum im Vergleich zu den "langsamen Weg" Raum. Wenn ein Produkt schnelle Weg zu unterstützen Ansprüche, müssen Sie ein bisschen tiefer graben, um die Umsetzung zu analysieren, um eine wirkliche Performance-Vorteile zu identifizieren.
Related posts:
