Bij server-virtualisatie wordt er vaak te makkelijk omgesprongen met de beveiliging van de systemen en de daarop draaiende applicaties. In dit artikel worden de negatieve gevolgen nader toegelicht. Naast het elimineren van deze nadelen kan virtualisatie, onder voorwaarden, echter ook ingezet worden als een beveiligingscomponent.
Virtualisatie houdt in dat er meerdere ‘virtuele' machines gecreëerd worden op één fysieke machine. Als een serverpark bijvoorbeeld vier fysieke systemen omvat, die allemaal voor 20 procent gebruikt worden, zou dat gecombineerd kunnen worden op één fysiek systeem dat voor circa 80 procent benut wordt. Dan spaart het serverpark hiermee drie systemen uit, met de bijkomende aanschaf-, onderhoud- en energiekosten.
Waarom server-virtualisatie?
De belangrijkste reden om virtualisatie toe te passen is om de efficiency te verhogen: er kan namelijk veel geld bespaard worden als men de servers efficiënter gaat gebruiken (de meeste servers in serverparken worden nu namelijk maar voor 10-50 procent benut). Maar virtualisatie lijkt ook een negatief effect te hebben op de beveiliging van systemen, omdat beveiliging vaak minder de aandacht heeft bij het ontwerpen van een virtualisatie technologie. Tegelijk heeft het virtueel scheiden van applicaties over verschillende virtuele machines wellicht beveiligingsvoordelen. Dit wordt inzichtelijk door deze ogenschijnlijke tegenstrijdigheid eens van dichtbij te bekijken.
Kwetsbaarheden
Een niet gevirtualiseerd systeem is opgebouwd uit hardware, een besturingssysteem en een aantal applicaties (Zie het linker deel van nevenstaand schema). Op alle drie niveaus zullen beveiligingseisen moeten worden ingevuld, want op alle drie de niveaus kunnen namelijk kwetsbaarheden aanwezig zijn.
– Kwetsbaarheden in applicaties kunnen misbruikt worden door bijvoorbeeld SQL-injectie op een website, waardoor een aanvaller van buitenaf een database ongeautoriseerd kan wijzigen, vernielen of onklaar maken.
– Kwetsbaarheid in het besturingssysteem kunnen door een aanvaller uitgebuit worden en daarmee kan het integere functioneren van een applicatie beïnvloed worden. Bijvoorbeeld het wijzigen van beheerrechten, een gebruiker wordt dan beheerder en kan daarmee het hele systeem beschadigen.
– Kwetsbaarheden in de hardware kunnen door een aanvaller misbruikt worden om zo uiteindelijk het hele systeem te beïnvloeden. Een voorbeeld hiervan is de bluepill malware, die ongemerkt een besturingssysteem laat denken dat het een virtueel systeem is, waardoor de aanvaller het hele systeem onder zijn controle krijgt.
Extra kwetsbaarheden
Wanneer virtualisatie wordt toegepast bestaat ieder systeem nog steeds uit hardware, het besturingssysteem en de applicaties, met alle bijbehorende kwetsbaarheden. Maar met virtualisatie wordt er een virtualisatielaag aan toegevoegd (zie rechter deel van het schema). Deze laag verzorgt de virtualisatie, dit betekent dat ieder virtueel systeem afhankelijk wordt van het functioneren van deze virtualisatielaag. Een kwetsbaarheid in de virtualisatielaag ook dus ook gevolgen hebben voor alle gevirtualiseerde omgevingen en hun applicaties.
Net als bij veel andere software, is het praktisch onmogelijk om de virtualisatielaag zonder kwetsbaarheden te implementeren. In de praktijk zal een virtualisatielaag altijd kwetsbaarheden bevatten en deze kwetsbaarheden geven een aanvaller mogelijkheden. Theo de Raadt, één van de ontwikkelaars van het besturingssysteem ‘openBSD', heeft het als volgt verwoord: "You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes." Zo is er onlangs een beveiligingslek gevonden in de Amazon cloud. In dit geval was de scheiding tussen de verschillende omgevingen niet voldoende, waardoor de aanvallers vanuit één omgeving gegevens uit een andere omgeving konden lezen.
Een complicerende factor is de vraag wie waar verantwoordelijk voor is. Het is niet langer één systeem met één verantwoordelijke, maar één stuk hardware met verschillende verantwoordelijken. Er is een systeembeheerder verantwoordelijk voor de hardware en de virtualisatielaag en er zijn meerdere virtuele systemen die mogelijk verschillende verantwoordelijken hebben. Wat als het virtueel platform wordt aangeboden door bedrijf A, dat gebruikt wordt door bedrijven B en C, als nu het virtueel systeem van bedrijf B crasht, en bedrijf C hier last van krijgt. Wie is er dan verantwoordelijk voor de schade van bedrijf C?
– Is bedrijf A verantwoordelijk, omdat A verplicht is om een veilig (afgeschermd) platform aan te bieden?
– Is bedrijf B verantwoordelijk, omdat B had moeten voorkomen dat het systeem zou crashen?
– Is bedrijf C zelf verantwoordelijk, omdat dit voor alle partijen overmacht is, en iedereen zijn eigen schade moet betalen?
Beveiligingscomponent
In de eerder genoemde argumenten werd virtualisatie gebruikt om efficiënter met de hardware om te gaan. Er worden dan meerdere fysieke systemen samengevoegd tot één gevirtualiseerd systeem. Maar men kan ook één fysiek systeem met twee applicaties A en B vervangen door één gevirtualiseerd systeem waarbij iedere applicatie zijn eigen virtuele omgeving heeft. (Zie nevenstaand schema.) Het voordeel van deze aanpak is dat de gevirtualiseerde systemen, minder invloed op elkaar hebben. Dus als één applicatie crasht, hebben andere applicaties hier minder last van en ook kan het beter afgedwongen worden dat de resources eerlijk verdeeld worden. Virtualisatie wordt dan als beveiligingscomponent ingezet.
Dit is een terecht argument, systemen op gescheiden virtuele omgevingen hebben minder invloed op elkaar dan dezelfde applicaties die op één gedeeld systeem staan. Maar, dit gevirtualiseerde systeem is wel complexer, en zal toch vatbaarder zijn voor aanvallen van buitenaf. Bovendien is de scheiding minder strikt dan een scheiding tussen fysieke systemen. Stel dat de ene virtuele omgeving slachtoffer wordt van een aanval waardoor de harde schijf crasht, dan zullen alle virtuele omgevingen hier de gevolgen van merken. Dus hoewel virtualisatie een virtuele scheiding tussen de verschillende omgevingen afdwingt, zal deze scheiding altijd minder sterk zijn dan een fysieke scheiding.
Conclusie
Virtualisatie wordt vaak ingezet om hardware efficiënter te benutten. Maar, virtualisatie betekent niet automatisch dat een systeem ook veiliger wordt. In tegendeel, de virtualisatielaag zal juist nieuwe risico's introduceren.
Virtualisatie kan echter ook toegepast worden als een beveiligingscomponent. Dan worden er niet applicaties van verschillende systemen samengevoegd op één gevirtualiseerd systeem, maar krijgt iedere applicatie van een bestaand systeem een eigen virtuele omgeving. Concreet heeft dit als effect dat de invloed die de verschillende applicaties op elkaar hebben verminderd wordt. Dit stelt echter wel hele andere eisen aan de virtualisatieoplossing. Waar momenteel de nadruk voornamelijk op de efficiency ligt, zal het ontwerp van de virtualisatiesoftware en de hardware beter afgestemd moeten worden op beveiligingseisen.
Gerben Broenink en Harm Schotanus, security specialisten bij TNO Informatie- en Communicatietechnologie
Beveiliging is een heikel punt in servervirtualisatie. Net zoals het dat nog steeds is bij servertoegang, hardware, het OS en de applicatie zelf. Dat servervirtualisatie een laag toevoegd aan deze hele keten en daarmee de beveiliging nog essentieler maakt, kun je natuurlijk op je klompen aanvoelen. Echter om nu de focus te leggen op servervirtualisatie als het heikele punt in de beveiliging, lijkt me een stap te ver.
Beveiliging is al sinds jaar en dag een issue binnen de IT. Beveiliging staat of valt bij het hebben van een goede beveiligingsstrategie met daarbij behorend beleid en uitvoering. Dat we nu servervirtualisatie toevoegen aan de stack, maakt servervirtualisatie een deel van het geheel wat door beveiliging bekeken moet worden. Als het echter al schort aan de beveiliging van het gehele IT systeem, dan kunnen we er vanuit gaan dat de beveiliging van de servervirtualisatielaag ook niet tip-top in orde zal zijn.
Servervirtualisatie vergroot inderdaad de keten die beveiligd moet worden, maar is denk ik nog niet de meeste problematische schakel in die keten. Deze kan nog steeds gelegd worden bij de applicaties en het OS. Maar mocht er een beveiligingsissue zijn met de servervirtualisatielaag dan heeft dit wel meteen een grotere impact. Daar waar OS / applicatie meestal maar effect heeft op 1 systeem. Kan een issue in de servervirtualisatielaag potentieel gevolgen hebben voor de gehele virtuele infrastructuur.
Daar wel de kanttekening bij dat exploits op servervirtualisatielaag op dit moment schaars zijn. Maar zoals Project Bluepill (http://bluepillproject.org) aantoont, niet ondenkbaar.
Kijkend naar de markt wordt het beveiligingsrisico door vendoren van servervirtualisatie erkend. En zijn er diverse best practices aanwezig hoe de servervirtualisatielaag zo goed mogelijk in te richten met zo min mogelijk beveiligingsrisicos. Daarnaast zien we steeds meer producten die toegespits zijn op deze laag in de stack om de risico’s met betrekking tot beveiliging te minimaliseren. De nadruk ligt dus naast efficiency wel degelijk bij beveiliging.
Kortom, de focus op beveiliging van de servervirtualisatielaag moet er zeker zijn. En er zijn genoeg best practices en producten in de markt om dit te ondersteunen. Echter moet beveiliging van de servervirtualisatielaag wel in de context geplaats worden van het gehele IT systeem. De keten is immers zo sterk als de zwakste schakel. En het valt te betwijfelen of servervirtualisatie dat is…
Martijn Baecke
Technisch Consultant Virtualisatie
Inter Access
Virtualisatie komt de security juist ten goede. Denk daarbij eens aan VMware vmsafe, waarbij de data enz al gescanned is, voordat deze bij de VM’s terecht komt, zodat rootkit detectie mogelijk is.
Het project Bluepill zet ik mijn kanttekeningen bij, want de exploit die getoond wordt, gaat uit van een hosted virtualisatie oplossing, zoals vmware server. Waarbij ze al toegang hadden tot de server (wat is dan het nut om verder te gaan, je bent al binnen op de server) en een listener installeren op de host en de vm.
De virtualisatielaag zoals van VMware ESX is het niet mogelijk om met een bufferoverflow in de VM de ESX server over te nemen, dit komt doordat afhandeling van request per 8 bytes gaan. Voor een exploit in shell script heb je minimaal 24 bytes nodig.
Een goed OS hoort ervoor te zorgen dat wanneer er één applicatie crasht de andere applicatie(s) die op dat systeem draaien er geen last van hebben. Hetzelfde geldt voor het eerlijk verdelen van de resources. Waarom zou een virtualisatielaag per definitie beter aan deze eisen tegemoet komen? Ook qua efficiëntie is het een slechte oplossing omdat er extra twee OS-en en een virtualisatielaag mee moeten draaien.