Många av oss arbetar nu med virtuella brandväggar. Jag gjorde ett tidigare inlägg om de styrkor och svagheter säkerhet inom den virtuella sfären , men idag vill jag tala 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 / använda snabba väg brandväggar. Men alla 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 att genomföra säkerhet inom en vSphere miljö genom att tillåta leverantörer att ansluta direkt i hypervisorn i ringen 0. VMsafe består av tre komponenter:
- VDDK - Disk blocket inspektion. API-har publicly släppts.
- vCompute - CPU och minne API. Inte har offentliggjorts. Okända som utomstående har tillgång till, om något.
- vNetwork - API för att övervaka / filter mellan vNIC och Vswitch. Inte har offentliggjorts. Så vitt jag vet, bara Altor Networks och Reflex Systems har tillgång (två leverantörer som hjälpte i utvecklingen av API).
Specifikt vill jag tala med vNetwork API. Vid styrning flödet nätverkstrafik i en ESX värd, finns det två möjliga genomförande "långsam Path" och "snabb väg".
Långsam Sökväg
Långsam väg är den enklaste genomförandet och som vi har använt i flera år. Effektivt detta bara är en VM-gäst, liknande till någon annan VM-gäst, körs på ESX värden. Typiskt varje gäst är ansluten till en unik Vswitch, och vardera av dessa vSwitchar är ansluten till en unik vNIC på brandväggen. Detta liknar ett arv brandväggskonfigurationen, men genomförs virtuellt. Fördelen att exekvera i slow väg är att du kan köra en hel slag OS med några bibliotek eller tjänster som behövs för att stödja brandväggen.
Snabb Path
Snabb väg är faktiskt en ring 0 drivrutin som ansluts direkt i hypervisor kärnan. Detta gör att en tredje part att utnyttja hypervisor för insättning mellan varje vNIC / Vswitch anslutning. Därför att en snabb sökväg drivrutin körs i kernel-kontexten, tillägger den minimal overhead-till systemet. Resultatet är kod inom fast vägen är betydligt snabbare än samma kod som exekveras i långsam bana (alltså VMware namnkonvention för varje sammanhang). Belastning på ESX värden 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 som står i snabba väg, men det finns ett antal frågor. Snabb väg är en kernel driver koppla in en minimerad hypervisor, inte en fullständig slag operativsystem. Detta begränsar bibliotek och brandväggen har till förfogande för att styra trafikflödet. Vidare är vi koppla in en kernel föraren så måste det finnas garantier för att den inte svälla hypervisor, öka attacken ytan eller störa annan hypervisor-funktioner. VMware utför en kodgranskning på alla snabba vägen förare innan de släpps. Så om jag kunde teoretiskt genomföra alla min kod i snabb väg, skulle jag behöva VMware godkännande innan varje patch eller funktion release.
Med detta i åtanke, är en leverantör hävdar "snabb väg" stöd faktiskt går att sluta genomföra en del av sin kod så fort vägen, en del som långsam bana och sedan skapa en koppling mellan de två. Hur mycket last placeras på systemet kommer att bero på hur mycket av denna kod genomförs i snabb väg och hur mycket av det utförs i långsam väg.
Möjliga Fast Path implementeringar
Till exempel kan en leverantör välja att skriva en snabb väg drivrutin som helt enkelt tunnlar alla paket tillbaka till en långsam väg genomförts brandvägg. Den långsamma vägen koden bestämmer sedan om trafiken ska ledas eller tappas, med godkända paket att skickas tillbaka till den snabba vägen koden för insättning i hypervisorn styrkanalen. Även om detta skulle vara den enklaste metoden för att distribuera snabbt väg, och utan tvekan den säkraste och mest säkra, skulle det ge de minst prestandafördelar. System last skulle förmodligen inte vara mycket bättre än en hel långsam väg genomförande. Jag ser detta alternativ som är mycket attraktiv för leverantörer äldre brandvägg, eftersom det skulle kräva minsta ändring sina befintliga koden samtidigt som de kan göra anspråk "snabb väg 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ören skulle skapa policyn med ett gränssnitt som körs på en långsam väg VM, som då skulle skjuta 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 politiken så trafikkontroll kan genomföras omedelbart. Resultatet är snabbare trafik hantering med minimal belastningen på systemet. Handeln off är skrymmande kod vid ringen 0.
Det är också möjligt att implementera en blandning av de två. Till exempel kunde jag använder den snabba vägen föraren att genomföra brandväggen politik, men då klara alla "godkända" paket tillbaka till den långsamma vägen för intrång kontroll, virussökning, eller vad som behövs. Acceptabla paket skickas sedan tillbaka till den snabba vägen drivrutinen för insättning. Så i denna konfiguration alla "tappade" paket hanteras via snabba vägen, medan accepterade paket interagera med en långsam bankomponent.
Som en sida noterar, 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 genomdrivandet, QoS, insamling av nätverk statistik etc. Till exempel den allra första vNetwork genomförandet var faktiskt VMwares Lab Manager. Detta verktyg används för självbetjäning provisioning och innehåller inte en brandvägg komponent (detta genomförs via VShield).
Summary
Medan en VMware produkt som integrerar med VMsafe strikt kan vara 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. Alla snabba vägen produkten är mest sannolikt kommer att bli en hybrid. Det är bara en fråga om hur mycket kod finns i den "snabba vägen" utrymme kontra "slow path" utrymme. När en produkt hävdar snabb väg support, måste du gräva lite djupare för att analysera genomförandet i syfte att identifiera eventuella verkliga prestanda fördelar.