Velen van ons zijn nu bezig met virtuele firewalls. Ik heb een eerdere post over de sterke en zwakke punten van veiligheid in de virtuele wereld , maar vandaag wil ik praten over de firewalling mogelijkheden met VMware. Er is een veel opwinding over relatief nieuwe VMware's VMsafe API . In het bijzonder, is iedereen versluiering te maken / te zetten snel weg firewalls. Maar zijn al snel weg implementaties op dezelfde manier gemaakt? Zijn er bezorgdheid over de veiligheid met gaan met een snelle pad oplossing? Laten we duiken in en te zien.
Verdeling van de VMsafe
Met de release van de VMsafe beveiligings-API, heeft VMware een versterking van de opties die beschikbaar zijn voor de uitvoering van veiligheid binnen een vSphere-omgeving door toe te staan leveranciers om rechtstreeks aansluiten op de hypervisor in ring 0. VMsafe bestaat uit drie componenten:
- VdDK - Disk blokkeren inspectie. API is publiekelijk vrijgegeven.
- vCompute - CPU en geheugen API. Is nog niet publiekelijk vrijgegeven. Onbekend welke derde partijen toegang hebben, indien aanwezig.
- vNetwork - API om toezicht te houden / filter tussen de vNIC en vswitch. Is nog niet publiekelijk vrijgegeven. Om het beste van mijn kennis, alleen Altor Networks & Reflex Systems toegang hebben (twee verkopers die assisteerde bij de ontwikkeling van de API).
In het bijzonder wil ik spreken met de vNetwork API. Bij het bedienen van het netwerk de verkeersstroom in een ESX-host, zijn er twee mogelijke implementatie, "langzaam weg" en "snel weg".
Langzaam Pad
Trage pad is de eenvoudigste uitvoering en de degene die we hebben gebruikt voor jaren. Effectief is dit gewoon een VM gast, vergelijkbaar met elke andere VM gast, die op de ESX host. Typisch elke gast is aangesloten op een unieke vswitch, en elk van deze vSwitches is aangesloten op een unieke vNIC op de firewall. Dit is vergelijkbaar met een erfenis firewall opzet, maar vrijwel geïmplementeerd. Het voordeel van het uitvoeren van in langzame pad is dat je kunt een volledige slag OS met alle bibliotheken of diensten die nodig zijn om de firewall te ondersteunen.
Fast Path
Snel weg is in feite een ring 0 driver die direct wordt aangesloten op de hypervisor kernel. Hierdoor kan een externe leverancier om gebruik te maken van de hypervisor voor het inbrengen tussen elke vNIC / vswitch verbinding. Omdat een snelle pad driver actief is in de kernel context, het voegt weinig overhead aan het systeem. Het resultaat is een code kan worden uitgevoerd binnen de snel weg is aanzienlijk sneller dan dezelfde code wordt uitgevoerd binnen de langzame weg (dus de VMware naamgevingsconventie voor iedere context). Belasting van de ESX-host is geminimaliseerd, zodat het eindresultaat is dat je kunt draaien veel meer virtuele gasten.
Snel Vs Slow
Dus het klinkt alsof je zou willen alles in het werk snel weg, maar er zijn een aantal zaken. Snel pad is een kernel driver wordt aangesloten op een geminimaliseerde hypervisor, niet een volledige klap besturingssysteem. Dit beperkt de bibliotheken en de diensten van de firewall beschikbaar heeft voor het regelen van de verkeersstroom. Verder zijn wij het aansluiten van een kernel driver, dus er moet een garantie dat deze niet bloat de hypervisor, verhoogt de attack surface of interfereren met andere hypervisor functies. VMware voert een code review op alle snel weg rijders voorafgaand aan de release. Dus als ik zou theoretisch implementeren al mijn code in snelle weg, zou ik nodig VMware goedkeuring voorafgaand aan elke andere pleister of feature release.
Met dit in gedachten, is een leverancier beweert 'fast path "ondersteuning daadwerkelijk gaat uiteindelijk implementeren van een deel van hun code zo snel weg, een gedeelte als langzaam weg, en dan een aansluiting tussen de twee te creëren. Hoeveel belasting wordt geplaatst op het systeem zal afhangen van hoeveel van deze code is geïmplementeerd in een snelle pad en hoeveel daarvan wordt uitgevoerd in langzame pad.
Mogelijke Fast Path-implementaties
Kan bijvoorbeeld een leverancier kiezen om een snel pad driver schrijven die eenvoudig tunnels alle pakketten terug tot een trage pad geïmplementeerd firewall. De langzame pad code bepaalt vervolgens of het verkeer moeten worden doorgegeven of vallen met gepasseerd packets worden teruggestuurd naar de snelle pad code voor het inbrengen in de hypervisor controle kanaal. Hoewel dit zou de gemakkelijkste manier van de inzet van snelle pad zijn, en misschien wel de veiligste en meest veilige, dan zou de minst prestatie voordelen. Belasting van het systeem zou waarschijnlijk niet veel beter dan een volledige trage pad implementatie. Ik zie deze optie als zeer aantrekkelijk voor legacy firewall leveranciers, want het zou de minste hoeveelheid wijziging van hun bestaande code nodig hebben en toch in staat om "snel weg support" te eisen.
Een andere optie zou zijn om de langzame pad ruimte voor administratieve functies te gebruiken met het snelle pad bestuurder als de firewall engine. Dus bijvoorbeeld de firewall beheerder zou leiden tot het beleid met behulp van een interface die op een langzame weg VM, die dan duw het beleid tot een snel pad driver. In deze opstelling de snelle pad bestuurder heeft een kopie van de polis, zodat het verkeer controle kunnen onmiddellijk worden toegepast. Het resultaat is een snellere verkeersafwikkeling met een minimale belasting van het systeem. De afweging is omvangrijker code op ring 0.
Het is ook mogelijk om een mengsel van de twee. Zo kon ik de snelle weg driver te gebruiken om de firewall-beleid uit te voeren, maar dan weer langs alle "aanvaard" pakketten naar het trage pad systeem voor het controleren van inbraak, is het scannen op virussen, of wat dan ook nodig is. Aanvaardbaar pakketten worden vervolgens weer doorgegeven aan de snelle pad driver voor het inbrengen. Dus in deze setup alle "laten vallen" pakketten worden afgehandeld via een snelle pad, terwijl de aanvaarde pakketten interactie met een trage pad component.
Als een zijde nota, moet u de bovenstaande informatie in gedachten te houden bij het overwegen van alle vNetwork implementaties, niet alleen firewalls. De vNetwork API kan ook worden gebruikt voor het beleid handhaving, QoS, het verzamelen van het netwerk van statistieken, enz. Zo is de allereerste vNetwork de uitvoering was eigenlijk VMWare Lab Manager. Deze tool wordt gebruikt voor self-service provisioning en bevat geen firewall-component (dit wordt uitgevoerd via vShield).
Overzicht
Terwijl een VMware product die integreert met VMsafe kan strikt worden een "trage weg" uitvoering, is het hoogst onwaarschijnlijk dat een product kan worden beschouwd als louter een 'fast path "uitvoering. Alle fast path product is het meest waarschijnlijk gaat om een hybride te zijn. Het is gewoon een kwestie van hoe veel code bestaat in de 'fast path "ruimte ten opzichte van de" trage weg "ruimte. Wanneer een product een snelle pad ondersteuning claims, moet je een beetje dieper graven om de implementatie te analyseren, om een echt betere prestaties te identificeren.
Gerelateerde berichten:
