Programmering

Linux-containere kontra virtuelle maskiner: En sikkerhetssammenligning

Utviklere elsker containere. De er enkle å bruke og raske i gang. Du kan kjøre mange av dem på til og med enkel maskinvare. Oppstartsomkostninger har alltid vært en bane for utvikling og testing, og denne overheaden øker bare med mikrotjenestearkitekturer. Hvis en utvikler trenger et halvt dusin tjenester, kan han lett kaste bort en dag eller to med oppsett - konfigurere maskinvare, kjøre installatører, bekjempe inkompatibilitet.

Med containere kollapser det til minutter eller sekunder og kan kjøres på en utviklingsarbeidsstasjon. De lett tilgjengelige arkivene med nyttige containerbilder multipliserer utviklerens produktivitet, omtrent som åpen kildekode gjør, men uten problemer med å bygge. Driftsteamene har gått tregere med å ta i bruk containere. En årsak er at mange applikasjoner de må støtte, ikke er containeriserte ennå. En annen grunn er motvilje mot å bevege seg bort fra virtuelle maskiner.

For ops var skiftet fra bart metall til virtuelle maskiner naturlig. Individuelle virtuelle maskiner ser ut og kan administreres som individuelle systemer, ved hjelp av de samme verktøyene og prosessene. Tidlige bekymringer for VM-sikkerhet ble dempet av den lange produksjonshistorien til virtuelle maskiner i mainframe-verdenen, av muligheten til å bruke de samme kontrollene som ble brukt for bare-metall-systemer, av maskinvarevirtualiseringsstøtte og av den utviklende modenheten til VM-styringsverktøy.

Mange tidlige sikkerhetsbekymringer kom ned på ett spørsmål: Var virtuelle maskiner like sikre som bart metall? Nå reises lignende spørsmål om containere. Hvor sikre er containere, og hvordan kan de sammenlignes med virtuelle maskiner? Absolutt hvis vi sammenligner tjenester som kjører i containere, mot de samme tjenestene som kjører som separate prosesser på samme system, er containerversjonen sikrere. Separasjonen som tilbys av Linux-navneområder og cgroups gir barrierer som ikke eksisterer mellom vanlige prosesser. Sammenligningen med virtuelle maskiner er mindre tydelig. La oss ta en titt på virtuelle maskiner og containere fra et sikkerhetsperspektiv.

I denne artikkelen tar jeg to forskjellige tilnærminger for å sammenligne VM og containersikkerhet. Den første tilnærmingen vil være mer strukturell eller teoretisk, og se på egenskapene til hver fra et sikkerhetsperspektiv. Deretter vil jeg bruke en mer praktisk analyse ved å se på hva som skjer i et typisk brudd og hvordan det kan bli påvirket av container- og VM-arkitekturer.

Strukturelt syn

For den strukturelle tilnærmingen vil jeg sammenligne angrepsflaten til begge systemene. En angrepsflate representerer antall punkter et system kan angripes på. Det er ikke nøyaktig definert (som et tall, for eksempel), men er nyttig for sammenligninger. For en innbruddstyv har et hus med 10 dører større angrepsflate enn et hus med en dør, selv om dørene er identiske. En dør kan være ulåst; en lås kan være defekt; dører på forskjellige steder kan gi en inntrenger mer privatliv, og så videre.

I datasystemer inkluderer angrepsoverflaten alt der angriperen (eller programvaren som handler på hans vegne) kan "berøre" målsystemet. Nettverksgrensesnitt, maskinvareforbindelser og delte ressurser er alle mulige angrepspunkter. Merk at angrepsoverflaten ikke innebærer at det eksisterer en faktisk sårbarhet. Alle de 10 dørene kan være helt sikre. Men en større angrepsoverflate betyr flere steder å beskytte, og jo større sannsynlighet vil angriperen finne en svakhet hos minst en.

Den totale angrepsoverflaten avhenger av antall forskjellige berøringspunkter og kompleksiteten til hver. La oss se på et enkelt eksempel. Se for deg et gammeldags system som betjener børsnoteringer. Den har et enkelt grensesnitt, en enkel seriell linje. Protokollen på den linjen er også enkel: Et aksjesymbol med fast lengde, si fem tegn, sendes til serveren, som svarer med et pristilbud med fast lengde - si 10 tegn. Det er ingen Ethernet, TCP / IP, HTTP og så videre. (Jeg jobbet faktisk med slike systemer for lenge siden i en galakse langt, langt borte.)

Angrepsoverflaten til dette systemet er veldig liten. Angriperen kan manipulere de elektriske egenskapene til serielinjen, sende feil symboler, sende for mye data eller på annen måte variere protokollen. Å beskytte systemet vil innebære å implementere passende kontroller mot disse angrepene.

Tenk deg den samme tjenesten, men i en moderne arkitektur. Tjenesten er tilgjengelig på Internett og viser en RESTful API. Den elektriske siden av angrepet er borte - alt som vil gjøre er å steke angriperens egen ruter eller bytte. Men protokollen er enormt mer kompleks. Den har lag for IP, TCP, muligens TLS og HTTP, som hver gir muligheten for et utnyttbart sårbarhet. Det moderne systemet har en mye større angrepsflate, selv om det fremdeles ser ut til angriperen som et enkelt grensesnittpunkt.

Angrepoverflate av bart metall

For en angriper som ikke er fysisk til stede i datasenteret, er den første angrepsoverflaten nettverket til serveren. Dette førte til "områdesynet" av sikkerhet: Beskytt inngangspunktene i datasenteret og ingenting kommer inn. Hvis angriperen ikke kan komme inn, spiller det ingen rolle hva som skjer mellom systemene på innsiden. Det fungerte bra når omkretsgrensesnittene var enkle (tenk oppringing), men fremmet svakheter på interne grensesnitt. Angripere som fant et hull i omkretsen, ville ofte oppdage at den interne angrepsflaten på serverfarmen var mye større enn den eksterne, og de kunne gjøre betydelig skade en gang inne.

Denne interne angrepsoverflaten inkluderte nettverkstilkoblinger mellom servere, men også prosess-til-prosess-interaksjoner på en enkelt server. Verre, siden mange tjenester kjører med forhøyede privilegier ("root" -bruker), ville det å lykkes med å bryte inn i en, effektivt bety uhindret tilgang til noe annet på systemet, uten å måtte lete etter flere sårbarheter. En hel bransje vokste opp rundt å beskytte servere - brannmurer, antimalware, gjenkjenning av inntrenging og om og om igjen - med mindre enn perfekte resultater.

Det er også interessante "sidekanal" -angrep mot servere. Forskere har vist eksempler på bruk av strømforbruk, støy eller elektromagnetisk stråling fra datamaskiner for å hente ut informasjon, noen ganger veldig sensitive data som kryptografiske nøkler. Andre angrep har utnyttet eksponerte grensesnitt som trådløse tastaturprotokoller. Generelt sett er imidlertid disse angrepene vanskeligere - de kan for eksempel kreve nærhet til serveren - så hovedveien for å komme "nedover ledningen" er mer vanlig.

VM-angrepsoverflate

Når virtuelle maskiner brukes på samme måte som bart metall, uten noen forskjell i arkitekturens applikasjon (som de ofte er), deler de fleste av de samme angrepspunktene. En ekstra angrepsflate er potensiell feil i hypervisor, OS eller maskinvare for å isolere ressurser mellom virtuelle maskiner riktig, slik at en VM på en eller annen måte kan lese minnet til en annen VM. Grensesnittet mellom VM og hypervisor representerer også et angrepspunkt. Hvis en virtuell maskin kan bryte gjennom og få kjørt vilkårlig kode i hypervisoren, kan den få tilgang til andre virtuelle maskiner på samme system. Hypervisoren representerer et angrepspunkt siden den avslører administrasjonsgrensesnitt.

Det er flere angrepspunkter avhengig av typen VM-system. Type 2 VM-systemer bruker en hypervisor som kjører som en prosess på et underliggende verts-OS. Disse systemene kan angripes ved å angripe verts-operativsystemet. Hvis angriperen kan få kode som kjører på vertssystemet, kan han potensielt påvirke hypervisor og virtuelle maskiner, spesielt hvis han kan få tilgang som en privilegert bruker. Tilstedeværelsen av et helt operativsystem, inkludert verktøy, administrasjonsverktøy og muligens andre tjenester og inngangspunkter (for eksempel SSH), gir en rekke mulige angrepspunkter. Type 1 VM-systemer, der hypervisor kjører direkte på den underliggende maskinvaren, eliminerer disse inngangspunktene og har derfor en mindre angrepsflate.

Containerangrep overflate

Som med virtuelle maskiner, deler containere de grunnleggende angrepspunktene for nettverksinngang for bare-metall-systemer. I tillegg, i likhet med Type 2 virtuelle maskiner, er containersystemer som bruker et "fullastet" verts-OS, utsatt for alle de samme angrepene som er tilgjengelige mot verktøyene og tjenestene til det verts-OS. Hvis angriperen kan få tilgang til verten, kan han prøve å få tilgang til eller på annen måte påvirke de containere som kjører. Hvis han får privilegert (“root”) tilgang, kan angriperen få tilgang til eller kontrollere hvilken som helst container. Et “minimalistisk” operativsystem (som Apcera’s KurmaOS) kan bidra til å redusere denne angrepsoverflaten, men kan ikke eliminere den helt, siden det kreves noe tilgang til verts-OS for containeradministrasjon.

De grunnleggende mekanismene for separasjon av containere (navnerom) tilbyr også potensielle angrepspunkter. I tillegg er ikke alle aspekter av prosesser på Linux-systemer navneområdet, så noen ting deles på tvers av containere. Dette er naturlige områder for angripere å undersøke. Til slutt er prosessen til kjernegrensesnittet (for systemanrop) stor og eksponert i hver container, i motsetning til det mye mindre grensesnittet mellom en VM og hypervisoren. Sårbarheter i systemanrop kan gi potensiell tilgang til kjernen. Et eksempel på dette er den nylig rapporterte sårbarheten i Linux-nøkkelringen.

Arkitektoniske hensyn

For både virtuelle maskiner og containere kan størrelsen på angrepsoverflaten påvirkes av applikasjonsarkitekturen og hvordan teknologien brukes.

Mange eldre VM-applikasjoner behandler virtuelle maskiner som bart metall. De har med andre ord ikke tilpasset arkitekturen sin spesielt for virtuelle maskiner eller for sikkerhetsmodeller som ikke er basert på områdesikkerhet. De kan installere mange tjenester på samme virtuelle maskin, kjøre tjenestene med root-rettigheter og har få eller ingen sikkerhetskontroller mellom tjenestene. Omarkitektur av disse applikasjonene (eller mer sannsynlig å erstatte dem med nyere) kan bruke virtuelle maskiner for å gi sikkerhetsskille mellom funksjonelle enheter, i stedet for bare som et middel til å administrere større antall maskiner.

Beholdere er godt egnet for mikrotjenestearkitekturer som "strenger sammen" et stort antall (vanligvis) små tjenester ved hjelp av standardiserte API-er. Slike tjenester har ofte en veldig kort levetid, der en containerisert tjeneste startes på forespørsel, svarer på en forespørsel, og blir ødelagt, eller der tjenester raskt rampes opp og ned basert på etterspørsel. Dette bruksmønsteret er avhengig av rask instantiering som containere støtter. Fra et sikkerhetsperspektiv har det både fordeler og ulemper.

Det større antallet tjenester betyr et større antall nettverksgrensesnitt og dermed en større angrepsflate. Imidlertid tillater det også flere kontroller på nettverkslaget. For eksempel i Apcera-plattformen, må all container-til-container-trafikk være eksplisitt tillatt. En useriøs container kan ikke vilkårlig nå ut til noe nettverksendepunkt.

Kort containerlevetid betyr at hvis en angriper kommer inn, er tiden han må gjøre noe begrenset, i motsetning til mulighetsvinduet fra en langvarig tjeneste. Ulempen er at rettsmedisin er vanskeligere. Når beholderen er borte, kan den ikke sonderes og undersøkes for å finne skadelig programvare. Disse arkitekturen gjør det også vanskeligere for en angriper å installere skadelig programvare som overlever etter ødeleggelse av containere, ettersom han kanskje på bart metall ved å installere en driver som lastes på oppstart. Beholdere lastes vanligvis fra et pålitelig, skrivebeskyttet lager, og de kan sikres ytterligere ved kryptografiske kontroller.

La oss nå vurdere hva som skjer under et brudd.

Beskyttelse mot brudd

Angripere har vanligvis ett eller to mål i å knekke inn i et serversystem. De ønsker å få data eller å gjøre skade.

Hvis de er ute etter data, vil de infiltrere så mange systemer som mulig, med høyest mulig rettigheter, og opprettholde den tilgangen så lenge som mulig. Å oppnå dette gir dem tid til å finne dataene, som kanskje allerede er der - for eksempel en dårlig sikret database - eller kan kreve langsom innsamling over tid når den siver inn, for eksempel å samle transaksjoner når de kommer inn fra brukerne. Å opprettholde tilgangen i lang tid krever stealth. Angrepet krever også en måte å få ut dataene.

Hvis angriperen bare prøver å gjøre skade, er målet igjen å få tilgang til så mange systemer og privilegier som mulig. Men det er en balansegang: Når skaden starter, vil den antagelig bli lagt merke til, men jo lenger angriperen venter på å starte (mens skadelig programvare filtrerer fra system til system), jo større er sjansen for å bli oppdaget. Å få ut data er mindre viktig enn koordinert kontroll av skadelig programvare. Ideen er å infisere så mange systemer som mulig, og deretter skade dem på et synkronisert punkt, enten forhåndsbestilt eller på kommando.

Brudd involverer en rekke elementer. La oss se på hver og se om virtuelle maskiner og containeriserte arkitekturer kan påvirke angrepsoverflaten for hver.

$config[zx-auto] not found$config[zx-overlay] not found