Jeg har hatt ovenfor spørsmålet nok ganger at jeg følte det verd et blogginnlegg. Mens noen få år tilbake svaret kan ha blitt "mindre sikker", i dag er svaret "begge". Jeg vet, høres ut som Chris være uforpliktende, men det svaret egentlig ikke beskrive mest nøyaktig den nåværende tilstanden av teknologien.

Virtualisering forandrer alt

Jeg har hørt noen folk bemerke at virtualisering er i ferd med å påvirke industrien på samme måte at Internett gjorde på 90-tallet. For å være ærlig, tror jeg det er fortjent i den mening. På begynnelsen av 90-tallet de fleste folk kjørte IPX, AppleTalk, NetBUI og en mengde andre protokoller på lukkede nettverk. Ved slutten av 90-tallet ble de fleste folk kjører IP utelukkende med tilkobling til hele verden. Måten vi gjorde forretninger, samt måten vi brukt sikkerhet, fullstendig forandret i løpet at 10 år. Både nettverksadministrasjon og sikkerhet ferdigheter som var cutting edge i 1990 var alle, men ubrukelige innen 1999.

Virtualisering er i ferd med å rampen opp til å ha samme innvirkning på bransjen. Virtualiseringsdistribuering krever en fullstendig gjennomtenkning av hvordan du søker sikkerhet. Tilbake på 1990-tallet, fikk admins som rett og slett koblet til Internett, uten hensyn til hvordan dette ville påvirke deres nettverk, brent big time. Vi er kø for å se et lignende utfall som folk vedta virtualisering.

Hva gjør Virtualisering mindre sikker

Achilles hæl av virtualisering er i selve programvaren. Vi håper vi kan stole på programvaren for å holde gjest systemene fra hverandre, samt vert og / eller hypervisor. Det er to store problemer med denne forventningen:

1. Ingen programvare er feilfri
2. Software kan være feilkonfigurert

For noen år tilbake kjerner Forskning viste at de kunne bryte ut av en gjest og få full kontroll over host OS . Mens en hypervisor er ment å begrense den type eksponering, har vi faktisk sett tilfeller der selv hypervisoren har blitt forbigått . Vi har selv sett tilfeller var programvaren blir utnyttbare bare når det kjøres i et virtualisert miljø . Disse lenkene viser et lite tverrsnitt av virtualisering problemene som har blitt oppdaget de siste årene. Google kan gi deg en mer komplett liste hvis du er interessert.

Så en forsvarlig sikkerhet faglig kommer til å være forsiktig med blindt å stole programvare for å være sikre. Problemet er leverandørene ikke alltid tar den samme tilnærmingen. Ta VMware med sin ESX (snart ESXi) produktet som et eksempel. Mange av oss var forbløffet når en VMware representant annonsert på CanSecWest at det var teoretisk umulig å angripe ESX hypervisor . Når vi bare anta noe er ubrytelige, er noen mer kreative kommer til å finne ut en måte å slå gjennom .

En av mine største bekymringer med ESX / ESXi er at VMware har utviklet det å være modulært (via VMSafe ). På pluss-siden, betyr dette at eksterne leverandører kan lage produkter for å bidra til å forbedre hypervisor funksjonalitet og sikkerhet. På nedsiden Dette øker sjansene for dårlig kode bli introdusert som kan kompromittere sikkerheten.

Vi har sett et godt eksempel på dette i det siste. Marcus Ranum skapte Gauntlet brannmur, som den gang var en av de mest sikre og sparke rumpe sikkerhet enheter tilgjengelig. Når tre brev byråer ønsket den beste sikkerheten, vendte de til Gauntlet. Marcus solgt Gauntlet til Network Associates (senere ble McAfee) som straks begynte å legge på funksjoner. Det var ikke lenge før en jevn rekke sårbarheter ble oppdaget, hver introdusert av disse nye "funksjoner". Derfra produktet mistet sin trygghet cred og skled ut av radar.

Nå er det absolutt mulig å legge til funksjoner og holde ting sikkert. Den FreeBSD folk er et utmerket eksempel på hvordan du gjør dette riktig. For å sikre sikkerheten de opprettholde en meget streng auditeringsprosess . Er den perfekt? Absolutt ikke, men deres auditeringsprosess har satt standarden for sikker programvare gjennomføring. Med litt hell VMware vil gjøre lignende, men jeg har ikke hørt noen buzz om dette blir tilfelle.

Komme Your Head Rett

OK, så vi kan ikke blindt stoler på virtualisering programvare for å holde angriperne i sjakk. Vi kan imidlertid fortsatt ta forholdsregler for å minimere virkningen hvis det verste skjer. En av de største skritt du kan ta er å nøye vurdere hvilke servere blir vertskap, og hva andre gjest systemer er tillatt å kjøre på samme boks. Sikkerhetssonen Begrepet brukes av nettverk arkitekter er like aktuelt her.

En sikkerhetssone er rett og slett en samling av systemer som deler den samme relative nivå av risiko. For eksempel Web, og SMTP-servere er vanligvis alt ligger på en DMZ, fordi de alle deler tilsvarende risiko fra direkte angrep. På den interne delen av nettverket, er stasjonære vanligvis plassert i en annen sikkerhetssone enn servere. Dette er fordi serverne har liten eller ingen tilgang til Internett mens stasjonære er som regel lov til å kommunisere direkte. Dette plasserer skrivebordene høyere risiko for angrep enn servere.

Vi kan bruke den samme logikken når implementere virtualisering. En DMZ server og en intern server bør ikke være gjester på den samme maskinvaren (både CPU og disk array). Gjør du det kan gi en angriper å lage en alternativ rute til nettverket vårt. Snarere enn å måtte passere gjennom en brannmur, NIDS, nips, etc. enheter som har vært utplassert på ledningen, kan en angriper kan få tilgang til interne ressurser via virtualisering programvaren. Er det en enkel angrep? Ikke fra det vi har sett så langt. Funksjonell utnytter har blitt oppdaget imidlertid så hvorfor introdusere unødig risiko hvis vi ikke må.

Forresten, bør de samme sikkerhetssone regler skal anvendes til virtualiserte nettverk gear. For eksempel er det en dårlig idé å bruke de samme fysiske bryteren til VLAN DMZ og det interne nettverket. Jeg har sett et par kunder får whacked den måten.

Hva gjør Virtualisering More Secure

Heldigvis, fra et sikkerhetsperspektiv, er virtualisering ikke alle dårlige nyheter. Faktisk er det noen veldig kule sikkerhetsrutiner kan du søke i et virtualisert miljø som du bare ikke kan klare seg uten det. Dette var en av grunnene til at vi begynte å bruke virtualisering innen Honeynet så tidlig som 2000.

En av de største sikkerhetsproblemene vi står overfor i dag er kjernen nivå rootkits . Hva gjør dette stamme av malware så lumske det blir effektivt selve operativsystemet til malware. Dette gjør påvisning ekstremt vanskelig, som alle sikkerhetskontroller må passere gjennom kjernen. Hvis kjernen i seg selv er kompromittert, kan vi ikke stole på kjernen til nøyaktig rapport sikkerhetsinformasjon. Vi ender opp med å måtte nedleggelse systemet, montere harddisken på en kjent for å være ren OS, og utfører våre rettsmedisinske sjekker derfra. Å selvfølgelig problemet med denne prosessen er at den ikke skalere godt. Hvis vi har dusinvis eller hundrevis av servere, det er rett og slett ikke nok tid på en dag for å sjekke dem alle riktig.

Som nevnt tidligere, er VMware nå tillater tredjeparts leverandører tilgang til hypervisoren API via VMSafe. Dette tillater tilgang til privilegert tilstand informasjon, for eksempel minne og nettverkstrafikk, på hver av gjesten OSS. Ved å plugge inn i hypervisor, noen ekstremt kule sikkerhetsalternativer blitt mulig.

For eksempel la oss si en gjest OS er angrepet av en kjerne nivå rootkit. Ved å analysere gjest minnet, kan rootkit bli oppdaget fra utsiden av det virtuelle operativsystemet. Når du utfører kontrollene via hypervisor, er det langt mindre sjanse for at en rootkit kan stealth sine aktiviteter og gå ubemerket. Som nevnt tidligere, er det ingen tilsvarende alternativ med et ikke-virtualisert system.

API plug skaper også nye muligheter for å håndtere kryptert trafikk. Når ende til ende kryptering er ansatt (som en VPN), nettverk basert kontroller av applikasjonslaget er lett forbigått. Din eneste reelle alternativet var å kjøre agenten programvare på endepunktet, kunne så sikkerheten skal gjennomføres etter dekryptering prosessen. Selvfølgelig problemet her er at hvis agenten blir angrepet, alle spill off. Igjen, ved å plugge inn i hypervisoren er vi i en bedre posisjon til mer trygt granske disse dataene.

Vi er bare å begynne å se nye produkter som utnytter VMSafe API pluggen . Siden alle produktene er relativt nye, er juryen fortsatt ute på hvor effektive de kan være. Tilbudene kjøre gambit fra å erstatte host basert brannmur og IDS beskyttelse til fullstendige retningslinjer håndheving. Det vil være interessant å se hvordan dette produktet nisje rister ut over neste år.

Oppsummering

Så som jeg nevnte i begynnelsen av dette innlegget, har virtualisering evnen til å gjøre miljøet mer eller mindre sikker, avhengig av hvordan du distribuerer det. Hvis du bare begynne å kjøre alt på en enkelt boks, er du sannsynligvis kommer til å få whacked. Hvis du utvide beste praksis som er utviklet gjennom årene inn i virtualisering riket, samt utnytter noen av de nye sikkerhetsfunksjonene som blir frigitt, kan du faktisk lage en bedre totale sikkerheten holdning.