Många av oss arbetar nu med virtuella brandväggar. Jag gjorde ett tidigare inlägg om styrkor och svagheter i säkerhet inom den virtuella sfären , men idag vill jag prata om brandväggar möjligheter med VMware. Det har varit en hel del spänning om VMwares relativt ny VMsafe API . Specifikt är alla klättra för att skapa / distribuera snabb väg brandväggar. Men alla är snabba vägen implementationer skapade lika? Finns det säkerhetsproblem med att gå med en snabb väg lösning? Låt oss dyka in och se.
Fördelning av VMsafe
Med lanseringen av VMsafe säkerhets-API har VMware förbättrat de tillgängliga alternativen för genomförandet av säkerhet inom ett vSphere miljö genom att tillåta leverantörer för att ansluta direkt i hypervisorn vid ring 0. VMsafe består av tre komponenter:
- VDDK - Disk blockera inspektion. API har varit offentligt släppts.
- vCompute - CPU och minne API. Har inte offentliggjorts. Okänd som utomstående har tillgång till, om något.
- vNetwork - API för att övervaka / filter mellan vNIC och vSwitch. Har inte offentliggjorts. Så vitt jag vet, bara Altor Networks & Reflex Systems har tillgång (två leverantörer som bidragit till utvecklingen av API).
Specifikt vill jag tala med vNetwork API. Vid styrning flöde nätverkstrafik i en ESX-värd, finns det två möjliga genomförande "långsam väg" och "snabb väg".
Långsam Path
Långsam väg är den enklaste genomförandet och den vi har använt i flera år. Effektivt detta är bara en VM-gäst, liknar någon annan VM-gäst, som körs på ESX-värd. Normalt varje gäst är ansluten till en unik vSwitch, och dessa vSwitchar är ansluten till en unik vNIC i brandväggen. Detta liknar ett arv brandväggskonfigurationen, men genomförs så gott. Fördelen med att köra i slow väg är att du kan köra en full blåsa OS med någon bibliotek eller tjänster som krävs för att stödja brandväggen.
Snabb bana
Snabb väg är faktiskt en ring 0 drivrutin som ansluts direkt i hypervisorn kärnan. Detta gör att en tredje part att utnyttja hypervisor för insättning mellan varje vNIC / vSwitch anslutning. Eftersom en snabb väg föraren kör i kernel-sammanhang, lägger minimal overhead till systemet. Resultatet är kod i snabb väg är betydligt snabbare än samma kod som körs i långsam väg (alltså VMware namnkonvention för varje sammanhang). Belastningen på ESX-värd minimeras, så slutresultatet är att du kan köra mycket mer virtuella gäster.
Snabb Vs Långsam
Så det låter som du skulle vilja göra allt snabb väg, men det finns ett antal frågor. Snabb väg är en kärna föraren koppla in ett minimerat hypervisor och inte en full blåsa operativsystem. Detta begränsar bibliotek och brandväggen har till sitt förfogande för att styra trafikflödet. Vidare är vi koppla in en kärna förare så måste det finnas garantier för att den inte svälla hypervisorn, öka attacken ytan eller störa andra hypervisor-funktioner. VMware utför en kodgranskning på alla snabba vägen förare innan de släpps. Så om jag skulle teoretiskt sett kunna genomföra alla min kod i snabba vägen, skulle jag behöva VMware godkännande före varje patch eller funktion release.
Med detta i åtanke är en säljare som hävdar "snabb väg" stöd kommer faktiskt att hamna genomföra en del av sin kod så snabbt väg, en andel som långsam väg, och sedan skapa en koppling mellan de två. Hur mycket belastning läggs på systemet kommer att bero på hur mycket av koden är implementerad i snabba vägen och hur mycket av det sker i långsam väg.
Möjliga Snabb Sökväg implementeringar
Till exempel kan en leverantör välja att skriva en snabb väg drivrutin som helt enkelt tunnlar alla paket till en långsam väg genomförs brandvägg. Den långsamma vägen koden avgör sedan om trafiken ska skickas eller tappas, med passerade paket skickas tillbaka till den snabba vägen koden för insättning i hypervisorn kontroll kanal. Även om detta skulle vara den enklaste metoden för att sprida snabba vägen, och otvivelaktigt den säkraste och mest säkra, skulle det ge minst prestanda. System belastning skulle förmodligen inte vara mycket bättre än en full långsam väg genomförande. Jag ser detta alternativ som mycket attraktiv för leverantörer gamla brandvägg, eftersom det skulle kräva minsta ändring av deras befintliga koden samtidigt som de kan göra anspråk på "snabba vägen support".
Ett annat alternativ skulle vara att använda den långsamma vägen utrymme för administrativa funktioner med den snabba vägen föraren agerar som brandvägg motorn. Så till exempel brandväggen administratör skulle skapa den politiken med hjälp av ett gränssnitt som körs på en långsam väg VM, som då skulle driva politiken ner till en snabb väg förare. Med den här inställningen den snabba vägen föraren har en kopia av den politiken så trafikkontroll kan genomföras omedelbart. Resultatet är snabbare trafik hantering med minimalt system belastning. Den avvägning är skrymmande kod vid ring 0.
Det är också möjligt att genomföra en blandning av de två. Till exempel kunde jag använda den snabba vägen föraren att genomföra brandväggen politiken, men då passerar alla "accepterade"-paket tillbaka till den långsamma vägen för intrång kontroll är virussökning, eller vad som behövs. Godtagbara paket skickas sedan tillbaka till den snabba vägen drivrutinen för isättning. Så i denna konfiguration alla "tappade" paket hanteras via snabba vägen, medan accepterade paket interagera med en långsam bankomponent.
Som en liten not, måste du hålla ovanstående information i åtanke när man överväger alla vNetwork implementationer, inte bara brandväggar. Den vNetwork API kan också användas för politiska verkställighet, QoS, insamling av nätverket statistik, etc. Till exempel den allra första vNetwork genomförande var faktiskt VMwares Lab Manager. Detta verktyg används för självbetjäning proviantering och inte innehåller en brandvägg komponent (Detta genomförs via VShield).
Sammanfattning
Medan en VMware produkt som integrerar med VMsafe kan vara strikt en "långsam väg" genomförande, är det högst osannolikt att någon produkt kan betraktas som enbart en "snabb väg" genomförande. Någon snabb väg produkt är mest sannolikt kommer att vara en hybrid. Det är bara en fråga om hur mycket kod finns i "snabb väg" utrymme kontra "långsam väg" utrymme. När en produkt påståenden snabb bana stöd, måste du gräva lite djupare för att analysera genomförandet i syfte att identifiera någon verklig prestanda.
Relaterade inlägg:
