I vanliga fall har vi samma förutsättningar för att skapa säkerhetslösningar i en virtuell miljö som i en fysisk. I båda miljöerna finns växlar och vlan som förbinder servrar med varandra och med klienterna. För att separera olika nät behövs vlan och för att separera viss trafik på nätverksnivå mellan olika subnät behövs oftast någon routning mellan näten i form av en brandväggslösning.
Tänk om vi kunde få en brandväggsfunktion utan att behöva dedikerade brandväggar och utan att behöva rita om nätverkskartan? Här kommer Vshield Zones in i bilden.
Kräver Vcenter 4.0
Vshield Zones är resultatet av Vmwares köp av företaget Blue Lane, som skapade produkter för intrångsdetektering och brandväggslösningar i virtuella miljöer. Produkten har sedan dess gjorts om något för att kunna arbeta på lägre nivåer i den virtuella miljön.
För att använda Vshield behöver du Vcenter 4.0. De fysiska servrarna ska köra ESX 4.0. Det är egentligen de enda hårda kraven, förutom att du behöver minne och diskyta för att kunna köra de virtuella maskiner som bygger upp Vshield. Det är dock inga enorma krav de ställer.
Du installerar Vshield genom att först infoga en virtuell maskin som blir hanteringsserver. Det är lätt gjort eftersom den laddas ned som ett ovf-paket (open virtualization format). Därefter infogar du ännu en server som görs till en template (mall) och blir den egentliga virtuella maskin som kommer att filtrera trafiken. Även den laddas hem i form av en ovf-fil.
Du måste manuellt skapa en portgrupp som heter vsmgmt och ansluta hanteringsservern till den. Det är viktigt, eftersom Vshield då vet att den inte ska flytta servrar som är anslutna till en portgrupp med just detta namn.
A. Vid installationen av Vshield skapas automatiskt en skuggkopia av den virtuella växeln. Den får namnet switchnamn_VS. Portgrupperna flyttas också automatiskt till den nya växeln, vilket innebär att alla virtuella maskiner blir inkopplade till den i stället. Inget fysiskt nätverkskort är kopplat till växeln och vi får absolut inte koppla in några, då skapar vi en trafikloop i nätverket.
B. Det här är själva Vshield, en virtuell maskin som är förbunden både med den helt nyskapade växeln och med den gamla. På båda skapas portgrupper som datorn ansluter till. Portgrupperna placeras i så kallat promiscuous mode för att Vshield ska kunna se och vidarebefordra all trafik som passerar mellan växlarna, oavsett vlan.
C. Det här är den gamla växeln, som fanns innan vi installerade Vshield. Den är förbunden med omvärlden via ett eller några nätverkskort som gör att de virtuella maskinerna får extern kontakt, trots att de egentligen är förbundna med skuggväxeln.
D. Den slutgiltiga destinationen kan vara ett helt externt nätverk såsom internet eller till och med samma subnät. All trafik kommer att filtreras och det är just det som är det trevliga med Vshield, förmågan att kunna filtrera trafik utan att behöva genomföra routning av den.
Skapar en skuggväxel
Via hanteringsservern installerar du sedan Vshield i den virtuella miljön. Det sker per fysisk värd. Kortfattat går det till så att en skuggkopia skapas av de befintliga virtuella växlarna. Sedan skapas en virtuell maskin och infogas nätverksmässigt så att den bryggar trafiken mellan den gamla växeln och den nyskapade skuggväxeln. Två portgrupper skapas och placeras i promiscuous mode, så att all trafik verkligen kan transporteras mellan växlarna oavsett vilket vlan de är anslutna till. Det gör det möjligt för Vshield att inspektera all trafik oavsett källa och destination.
Nu förstår vi också att här finns en begränsning i Vshield: Det är endast trafik som kommer till eller lämnar en virtuell växel som kan filtreras. All trafik som flyter inom en lokal portgrupp på en växel eller mellan portgrupper på samma växel kommer att gå ”direkt” mellan dessa enheter, aldrig lämna växeln, och kan följaktligen inte filtreras. Däremot behöver inte trafiken routas för att filtrering ska kunna ske.
”Trots att trafiken flyter direkt
mellan växlarna passerar den minst en
Vshield och kan därmed filtreras.”
Ett scenario, kanske lite krystat men det visar en viktig funktion i Vshield, är att ett och samma ip-subnät finns nåbart från två virtuella växlar. I nätet finns två virtuella maskiner, säg 192.168.0.80/32 i ena växeln och 192.168.0.81/32 i den andra. Trots att trafiken flyter direkt mellan dem passerar den minst en Vshield och kan därmed filtreras, även om ingen routning är inblandad. Den möjligheten är inte så vanlig i en fysisk värld och vi får ännu ett exempel på att en virtuell lösning är bättre än en fysisk.
Här har Vshield har skapat en ny växel som kallas vSwitch1_VS. Den har två portgrupper, där våra virtuella maskiner kopplas till VM Net och Vshield till VSProt. Växeln vSwitch1 har nätverkskort som kopplar virtuella maskiner ut på nätverket och den ska bara ha en portgrupp. Det är där det andra benet av Vshield ansluts. Vi ser också portgruppen vsmgmt i vSwitch0, dit vi ansluter hanteringsservern för Vshield.
Regler styr trafiken
Det regelverk som kan skapas är ganska enkelt till sin uppbyggnad. Det går att skapa regler antingen på datacenternivå eller på klusternivå. På datacenternivå skapar du antingen regler som gäller hela datacentret, oavsett vad som konfigureras på klusternivå, eller anger regler som har lägre prioritet än klusternivån. Alla regler gås igenom uppifrån och ner och den första regeln som stämmer in på trafiken som flyter förbi används för att antingen tillåta eller förbjuda den.
I vanlig ordning är det alltså smart att placera alla hindrande regler ovanför de tillåtande, eftersom de hindrande annars aldrig kommer att användas. På så vis kan du skapa ett omfattande regelverk som anger vilka virtuella maskiner som får prata med vilka andra och även vilka som får nå helt externa servrar eller klienter, som sådana som är placerade på internet.
Så här skapas regelverket i Vshield. På datacenter- eller klusternivå skapar vi L3/4-regler som anger vilka nät eller adresser som ska få nå andra nät, och kan på så vis segmentera nätet och skapa säkerhetszoner utan att behöva skapa separata växlar, vlan eller portgrupper.
Går att backa tillbaka
En regel består av käll- och destinationsadress som kan vara ett ip-subnät eller en enskild dator (/32 subnät), en källport och en destinationsadress och -port samt protokoll (tcp eller udp). Du anger förstås också om regeln ska tillåta eller stoppa trafik och om trafiken ska loggas i en loggbok eller inte.
När du har genomfört en regeländring och sparar den skapas automatiskt en säkerhetskopia av den gamla konfigurationen. Då kan du lätt komma tillbaka igen till ett fungerande läge om förändringen inte får önskad effekt.
De virtuella maskiner som berörs av brandväggsreglerna har förstås ingen aning om att de egentligen omfattas av skyddet från Vshield. Eftersom Vshield arbetar direkt med den trafik som kommer och går till och från en växel arbetar den ”under” en virtuell maskin, som inte på något vis kan undvika att filtreras av Vshield.
Kan schemalägga kopiering
En bra funktion är att du kan schemalägga en säkerhetskopiering av hela konfigurationen i Vshield genom att peka ut en ip-adress, ett mappnamn samt ange login och lösenord för en ftp- eller sftp-destination där konfigurationen ska sparas.
Vshield har också en egen kontohantering. Från början finns endast ett konto, admin, som du loggar in med. Du kan sedan skapa ytterligare konton och tilldela dem rättigheter på system- eller regelnivå. En användare har antingen rätt att genomföra ändringar på respektive nivå eller endast rätt att se vilka inställningar som har gjorts.
Är du van vid att använda active directory-integrerad kontohantering i resten av Vmwaremiljön kan det kännas lite udda att plötsligt behöva ha en separat kontohantering för just detta ändamål. I en framtida version vore det önskvärt med en integration på samma sätt som i resten av miljön.
Inget stöd för ip v 6
Vshield kan alltså bara filtrera trafik på adress- och portnivå. Ingen protokollverifiering sker, eftersom den bara arbetar på nivå 4 i osi-modellen (open systems interconnection). Det ger högre prestanda, men förstås även ett sämre skydd än med mer avancerade brandväggar, som kan arbeta på nivå 7.
Förutom att filtrera trafik på nivå 4, det vill säga tcp/udp-portnivå, kan du ange regler för nivå 3. Det innebär att du kan stoppa eller tillåta främst olika sorters icmp-kommandon, som till exempel ping. Du kan också ange en regel på denna nivå som heter Other IP v4, vilket innebär att du kan stoppa all trafik som inte är traditionell tcp/ip. Det inkluderar ip v 6, som denna version av Vshield inte kan hantera.
”För att vara på den säkra sidan
måste du lägga en regel högt i listan som stoppar allt annat än ip v 4.”
Det kan leda till bekymmer och faktiskt säkerhetsproblem, eftersom ip v 6-trafik flyter genom Vshield helt okontrollerat. Med tanke på att Windows Server 2008 och Windows Vista båda använder ip v 6 som standardprotokoll kan du få bekymmer om du vill kunna filtrera trafiken. För att vara på den säkra sidan måste du lägga en regel högt upp i listan på datacenternivå som stoppar allt annat än ip v 4. Vmware kan i dag inte säga om eller när Vshield kommer att klara ip v 6.
Vill inte göra Vmotion
Eftersom dina virtuella maskiner numera sitter instoppade i en portgrupp på en växel som inte har något nätverkskort inkopplat kommer Vcenter att vägra genomföra Vmotion. Detta eftersom du i normala fall inte kommer att kunna ge den flyttade servern samma nätförbindelse som den hade innan. En växel utan nätverkskort kallas vanligen för ett virtual intranet.
I det här fallet bryggas trafiken ut på nätverket av Vshield och du måste tala om för Vcenter att det är okej att genomföra Vmotion på en server trots att den ser ut att vara förbunden med ett virtual intranet. Det sker genom att du justerar innehållet i en textfil på Vcenterservern.
Här och var märks att produkten inte har hunnit med när Vmware nu har släppt Vsphere. Ett exempel är att den inte kan installera sig på en server som använder de nya distribuerade växlarna. I handboken till Vshield anges alla steg för hur du manuellt ska göra det, men det vore förstås snyggare om produkten var kompatibel med ”sig själv”.
Prestandaförlust på sju procent
Det går att få en integration mellan Vcenterklienten, som du använder för att administrera din ESX-miljö, och Vshield. Den består dock endast av att du kan få en tilläggsmodul registrerad som gör att du får en genväg i klienten. Den startar en webbläsare som tar dig till loginsidan för Vshields hanteringsserver.
Det hade förstås varit ännu snyggare om administrationen av Vshield kunde ske integrerat i klienten, men så ser det inte ut i dag. Vmware är förteget med information om huruvida Vshields funktioner kommer att byggas in helt i produkten. En gissning är att det kommer att ske i en framtida lansering av en större versionsuppgradering av Vsphere.
Om du anger i en regel att den ska logga viss trafik kan information skickas till en utpekad syslogserver. Samma information loggas också lokalt på hanteringsservern. Loggen är dock synnerligen rå till formatet och erbjuder inga speciella sök- eller filtreringsfunktioner. Dessutom är den ganska svår att hitta, den är gömd långt ned på en webbsida, flera nivåer ned i verktyget.
All form av inspektion av trafik ger ofelbart en prestandaförlust. Vmwares interna tester av Vshield visar att du på en fullt belastad gigabitförbindelse kan räkna med en prestandaförlust i bandbredd på cirka sju procent. Vshield har också en komponent som gör att du kan se grafiskt hur mycket trafik som flyter förbi och kan sortera den per protokoll. Det ger en mer detaljerad information än med VI Client, där du bara kan se hur mycket data som flyter till eller från en fysisk värd totalt sett, inte uppdelat per protokoll.
TechWorlds slutsats
Vshield är en intressant produkt, speciellt med tanke på att den troligen ingår gratis i den licens du redan har. Om du har ett nät som i dag är baserat på ip v 4 är det ett snabbt och enkelt sätt att få en möjlighet att segmentera nätet och få en brandväggsfunktion.
Nackdelar är avsaknaden av stöd för ip v 6, en svag loggningsfunktion och att den inte riktigt är i synk med Vsphere i stort.
Illustration & grafik: Jonas Englund
» Så går du vidare- www.vmware.com/products/vshield-zones/ – Här kan du läsa mer om produkten och själv ladda hem en testversion.
- www.vmware.com/support/pubs/vsz_pubs.html – Direktlänk till dokumentationen för Vshield utan inloggning.
Det är troligt att du har rätt att använda Vshield Zones om du redan har köpt licens för Vsphere. Vshield Zones ingår i dessa paketeringar: Advanced, 1 820 euro (cirka 18 600 kronor) per sockel, Enterprise, 2 330 euro (cirka 24 000 kronor) per sockel samt Enterprise Plus, 2 835 euro (cirka 29 000 kronor) per sockel.
För att kunna installera Vshield behöver du ha en miljö baserad på Vsphere. Det innebär i praktiken att dina fysiska servrar kör ESX 4.0 och att din Vcenter Server är version 4.0.
Du behöver också ha rätt behörigheter i den virtuella miljön så att du kan installera nya virtuella maskiner och konfigurera om virtuella nätverksinställningar. I praktiken är det troligt att du gör allt detta när du är inloggad som administratör.
VS-hanteringsservern behöver också ha en fast ip-adress och samma sak gäller för Vshields virtuella maskiner.
Eftersom både hanteringsservern och Vshieldmaskinerna egentligen är virtuella maskiner går det förstås också åt en del ram-minne för att driva dem samt diskyta för att lagra deras diskfiler.
Räkna med en gigabyte minne per virtuell maskin. Det kan du förstås justera, men då frångår du den mall som Vmware har skapat och du får själv se till att de virtuella maskinerna inte arbetar med för lite minne.
Hallå där Marcus Weman, it-ansvarig på Skistar, som är i full färd med att uppgradera till Vsphere.
Hur ser ni på Vshield
Zones?
Vi kommer definitivt att införa Vshield Zones i vår Vspheremiljö inom kort.
Varför kommer ni att göra det?
Det kommer att underlätta för oss att leva upp till våra fastställda ramverk för säkerhet. Framför allt kommer det att bli mycket lättare att hantera säkerheten internt i miljön och vi kommer att kunna bygga lager på lager av säkerhet betydligt smidigare än i dag.
Eftersom Vshield egentligen inte är något annat än en paketfiltrerande brandvägg placerad mellan två växlar kan du förstås bygga en liknande lösning på annat vis.
Du kan skapa en virtuell maskin som dina övriga virtuella maskiner pekar på som tcp/ip-default gateway och köra en produkt som kan filtrera trafiken. Det kräver förstås att du ritar om routningkartan något för ditt nätverk. Fördelen är å andra sidan att du kan använda en mer avancerad produkt som till exempel kan filtrera trafik på osi-nivå 7 och genomföra mycket avancerade kontroller av trafiken, allt till en viss kostnad i prestandaförlust, förstås.
Med tanke på att du troligen har rätt att köra Vshield gratis finns det i och för sig få skäl att använda något annat om du är ute efter en L3/4-brandvägg. Produkten smälter väl in i den virtuella lösningen.
