Linux spremnici nasuprot VM-ovima: Sigurnosna usporedba

Programeri vole kontejnere. Jednostavni su za upotrebu i brzi za pokretanje. Mnogo ih možete pokrenuti čak i na jednostavnom hardveru. Općeniti troškovi pokretanja uvijek su bili napor za razvoj i testiranje, a ovi se troškovi samo povećavaju s arhitekturama mikro usluga. Ako programeru treba pola tuceta usluga, lako bi mogao izgubiti dan ili dva s postavljanjem - konfiguriranjem hardvera, pokretanjem instalacijskih programa, borbom protiv nekompatibilnosti.

S kontejnerima, koji se sruši na minute ili sekunde i može se pokrenuti na jednoj razvojnoj radnoj stanici. Lako dostupna spremišta korisnih slika spremnika povećavaju produktivnost programera, slično kao što to čini otvoreni izvor, ali bez problema s izradom. Operativni timovi sporije su usvajali kontejnere. Jedan od razloga je taj što mnoge aplikacije koje moraju podržavati još nisu u kontejneru. Drugi razlog je nevoljkost da se odmakne od VM-ova.

Za operativne sustave prelazak s golog metala na VM bio je prirodan. Pojedinačni VM-ovi izgledaju i njima se može upravljati poput pojedinačnih sustava, koristeći iste alate i procese. Rane zabrinutosti oko sigurnosti VM-a ublažene su dugom poviješću proizvodnje VM-ova u svijetu mainframe-a, sposobnošću primjene istih kontrola koje se koriste za golo-metalne sustave, podrškom za hardversku virtualizaciju i evolutivnom zrelošću alata za upravljanje VM-ima.

Mnoge rane sigurnosne brige svele su se na jedno pitanje: Jesu li VM-ovi bili sigurni poput golog metala? Sada se postavljaju slična pitanja o kontejnerima. Koliko su spremnici sigurni i kako se uspoređuju s VM-ovima? Svakako ako usporedimo usluge koje se izvode u spremnicima s istim uslugama koje se izvode kao zasebni procesi na istom sustavu, verzija spremnika je sigurnija. Odvajanje koje osiguravaju Linuxovi prostori imena i cgroups pruža prepreke koje ne postoje između običnih procesa. Usporedba s VM-ima manje je jasna. Pogledajmo VM-ove i spremnike iz sigurnosne perspektive.

U ovom ću članku primijeniti dva različita pristupa uspoređivanju VM-a i sigurnosti spremnika. Prvi pristup bit će strukturniji ili teoretski, gledajući obilježja svakog iz sigurnosne perspektive. Tada ću primijeniti praktičniju analizu promatrajući što se događa u tipičnom proboju i kako na to mogu utjecati arhitekture spremnika i VM.

Strukturni pogled

Za strukturni pristup usporedit ću površinu napada oba sustava. Napadna površina predstavlja broj točaka u kojima sustav može biti napadnut. Nije precizno definiran (na primjer, kao broj), ali je koristan za usporedbe. Provalniku kuća s 10 vrata ima veću površinu za napad od kuće s jednim vratima, čak i ako su vrata identična. Jedna vrata mogu ostati otključana; možda je jedna brava neispravna; vrata na različitim mjestima mogu uljezu ponuditi više privatnosti i tako dalje.

U računalnim sustavima, površina napada uključuje sve ono što napadač (ili softver koji djeluje u njegovo ime) može "dodirnuti" ciljni sustav. Mrežna sučelja, hardverske veze i zajednički resursi sve su moguće točke napada. Imajte na umu da površina napada ne implicira da postoji stvarna ranjivost. Svih 10 vrata moglo bi biti savršeno sigurno. Ali veća površina napada znači više mjesta za zaštitu i veća je vjerojatnost da će napadač pronaći slabost barem u jednom.

Ukupna površina napada ovisi o broju različitih dodirnih točaka i složenosti svake od njih. Pogledajmo jednostavan primjer. Zamislite staromodni sustav koji opslužuje burzovne kotacije. Ima jedno sučelje, jednostavnu serijsku liniju. I protokol na toj liniji je jednostavan: simbol dionice fiksne duljine, recimo pet znakova, šalje se poslužitelju koji odgovara kotacijom cijena fiksne duljine - recimo, 10 znakova. Ne postoji Ethernet, TCP / IP, HTTP i tako dalje. (Zapravo sam radio na takvim sustavima davno u dalekoj galaksiji.)

Napadna površina ovog sustava vrlo je mala. Napadač može manipulirati električnim karakteristikama serijske linije, slati pogrešne simbole, slati previše podataka ili na drugi način mijenjati protokol. Zaštita sustava uključivala bi provođenje odgovarajuće kontrole protiv tih napada.

Sada zamislite istu uslugu, ali u modernoj arhitekturi. Usluga je dostupna na Internetu i nudi RESTful API. Električna strana napada je nestala - sve što će učiniti je spržiti napadač na vlastitom usmjerivaču ili prekidaču. Ali protokol je izuzetno složen. Sadrži slojeve za IP, TCP, moguće TLS i HTTP, a svaki nudi mogućnost ranjivosti koja se može iskoristiti. Suvremeni sustav ima puno veću površinu napada, iako napadaču i dalje izgleda kao jedna točka sučelja.

Gola metalna površina napada

Za napadače koji nisu fizički prisutni u podatkovnom centru, početna površina napada je mreža na poslužitelju. To je dovelo do "perimetarskog pogleda" sigurnosti: Zaštitite ulazne točke u podatkovni centar i ništa ne uđe. Ako napadač ne može ući, nije važno što se događa između sustava iznutra. Dobro je funkcioniralo kad su obodna sučelja bila jednostavna (pomislite na dial-up), ali je potaknula slabosti na unutarnjim sučeljima. Napadači koji su pronašli rupu u obodu često bi otkrili da je unutarnja napadačka površina farme poslužitelja mnogo veća od vanjske i da bi mogli nanijeti značajnu štetu kad jednom uđu.

Ova unutarnja površina napada uključivala je mrežne veze između poslužitelja, ali i interakcije od procesa do procesa unutar jednog poslužitelja. Još gore, budući da se mnoge usluge pokreću s povišenim privilegijama („root“ korisnik), uspješno probijanje u jednu učinkovito bi značilo nesmetan pristup bilo čemu drugom u tom sustavu, bez potrebe za traženjem dodatnih ranjivosti. Čitava je industrija odrasla oko zaštite poslužitelja - vatrozida, antimalvera, otkrivanja upada i više i više - s manje nego savršenim rezultatima.

Postoje i zanimljivi napadi na bočni kanal protiv poslužitelja. Istraživači su pokazali primjere korištenja potrošnje energije, buke ili elektromagnetskog zračenja računala za izdvajanje podataka, ponekad vrlo osjetljivih podataka poput kriptografskih ključeva. Drugi su napadi iskoristili izložena sučelja poput protokola bežične tipkovnice. Općenito, međutim, ovi su napadi teži - možda će im trebati blizina poslužitelja, na primjer - pa je glavni put dolaska "niz žicu" češći.

VM napadačka površina

Kada se VM-ovi koriste na isti način kao goli metal, bez ikakve razlike u arhitekturi aplikacije (kao što su često), oni dijele većinu istih napadačkih točaka. Dodatna površina napada je potencijalni neuspjeh u hipervizoru, OS-u ili hardveru da pravilno izolira resurse između VM-ova, omogućujući VM-u da nekako pročita memoriju drugog VM-a. Sučelje između VM-a i hipervizora također predstavlja točku napada. Ako se VM može probiti i pokrenuti proizvoljni kôd u hipervizoru, tada može pristupiti drugim VM-ovima na istom sustavu. Sam hipervizor predstavlja napadnu točku jer izlaže upravljačka sučelja.

Postoje dodatne točke napada ovisno o vrsti VM sustava. VM sustavi tipa 2 koriste hipervizor koji se izvodi kao proces na osnovnom OS-u hosta. Ti se sustavi mogu napadati napadom na OS-a domaćina. Ako napadač može pokrenuti kôd na glavnom sustavu, potencijalno može utjecati na hipervizor i VM-ove, posebno ako pristup može dobiti kao privilegirani korisnik. Prisutnost cijelog OS-a, uključujući uslužne programe, alate za upravljanje i možda druge usluge i ulazne točke (kao što je SSH) pruža brojne moguće točke napada. VM sustavi tipa 1, gdje hipervizor radi izravno na osnovnom hardveru, uklanjaju te ulazne točke i stoga imaju manju površinu napada.

Napadačka površina kontejnera

Kao i kod VM-ova, spremnici dijele osnovne točke napada mrežnih unosa golo-metalnih sustava. Uz to, poput virtualnih strojeva tipa 2, sustavi spremnika koji koriste "potpuno učitani" host OS podložni su istim napadima dostupnim na uslužne programe i usluge tog OS OS. Ako napadač može dobiti pristup tom hostu, može pokušati pristupiti ili na drugi način utjecati na tekuće spremnike. Ako dobije privilegirani ("root") pristup, napadač će moći pristupiti bilo kojem spremniku ili ga kontrolirati. „Minimalistički“ OS (poput Apcera-ovog KurmaOS-a) može pomoći u smanjenju ove površine napada, ali je ne može u potpunosti eliminirati, jer je za upravljanje spremnikom potreban određeni pristup glavnom OS-u.

Osnovni mehanizmi za odvajanje spremnika (prostori imena) također nude potencijalne točke napada. Uz to, nisu svi aspekti procesa na Linux sustavima razmaknuti imenima, pa se neke stavke dijele kroz spremnike. To su prirodna područja za napadače. Napokon, proces sučelja jezgre (za sistemske pozive) velik je i izložen u svakom spremniku, za razliku od mnogo manjeg sučelja između VM-a i hipervizora. Ranjivosti u sistemskim pozivima mogu ponuditi potencijalni pristup jezgri. Jedan od primjera toga je nedavno prijavljena ranjivost u privjesku za Linux.

Arhitektonska razmatranja

I za VM-ove i za spremnike, na veličinu napadane površine može utjecati arhitektura aplikacije i način na koji se tehnologija koristi.

Mnoge stare VM aplikacije tretiraju VM kao goli metal. Drugim riječima, nisu prilagodili svoje arhitekture posebno za VM-ove ili za sigurnosne modele koji se ne temelje na perimetarskoj sigurnosti. Mogli bi instalirati mnoge usluge na isti VM, pokretati ih s root privilegijama i imati malo ili nimalo sigurnosnih kontrola između usluga. Prearhitektiranje ovih aplikacija (ili vjerojatnije njihova zamjena novima) moglo bi koristiti VM-ove za osiguravanje sigurnosnog razdvajanja između funkcionalnih jedinica, umjesto kao sredstvo za upravljanje većim brojem strojeva.

Spremnici su vrlo pogodni za arhitekture mikroservisa koji "spajaju" velik broj (obično) malih usluga koristeći standardizirane API-je. Takve usluge često imaju vrlo kratak vijek trajanja, kada se kontejnerizirana usluga pokreće na zahtjev, odgovara na zahtjev i uništava se ili se usluge brzo povećavaju i smanjuju na temelju potražnje. Taj obrazac upotrebe ovisi o brzoj instanciji koju spremnici podržavaju. Iz sigurnosne perspektive ima i prednosti i nedostatke.

Veći broj usluga znači veći broj mrežnih sučelja, a time i veću površinu napada. Međutim, omogućuje i više kontrola na mrežnom sloju. Na primjer, na platformi Apcera, sav promet od kontejnera do kontejnera mora biti izričito dopušten. Pokvareni spremnik ne može proizvoljno doći do bilo koje krajnje točke mreže.

Kratki vijek trajanja spremnika znači da je, ako napadač ipak uđe, vrijeme koje mora nešto poduzeti ograničeno, za razliku od prozora prilika koje pruža dugotrajna usluga. Loša strana je što je forenzika teža. Jednom kad spremnik nestane, ne može se ispitati i ispitati kako bi se pronašao zlonamjerni softver. Te arhitekture također otežavaju napadaču instaliranje zlonamjernog softvera koji preživi nakon uništenja spremnika, kao što bi mogao učiniti na golom metalu instaliranjem upravljačkog programa koji se učitava u boot-u. Spremnici se obično učitavaju iz pouzdanog spremišta samo za čitanje, a mogu se dodatno osigurati kriptografskim provjerama.

Sada razmotrimo što se događa tijekom kršenja.

Zaštita od kršenja

Napadači obično imaju jedan ili dva cilja u prodiranju u poslužiteljski sustav. Žele dobiti podatke ili napraviti štetu.

Ako traže podatke, žele se infiltrirati u što veći broj sustava, s najvećim mogućim privilegijama, i zadržati taj pristup što je dulje moguće. Postizanjem toga daju im vremena da pronađu podatke koji bi već mogli biti - na primjer slabo osigurana baza podataka - ili bi mogli zahtijevati polagano prikupljanje tijekom vremena dok se slijevaju, kao što je prikupljanje transakcija kada korisnici dolaze. Održavanje pristupa dulje vrijeme zahtijeva nevidljivost. Napad također zahtijeva način izvlačenja podataka.

Ako napadač pokušava jednostavno nanijeti štetu, cilj je opet pristupiti što većem broju sustava i privilegija. No postoji čin uravnoteženja: Vjerojatno će se primijetiti nakon što šteta započne, ali što duže napadač čeka da počne (dok se zlonamjerni softver filtrira od sustava do sustava), veća je šansa da će biti otkriven. Iznošenje podataka manje je važno od koordinirane kontrole zlonamjernog softvera. Ideja je zaraziti što više sustava, a zatim ih oštetiti na sinkroniziranoj točki, bilo unaprijed dogovoreno ili na zapovijed.

Kršenja uključuju brojne elemente. Pogledajmo svaku i provjerimo mogu li VM-ovi i kontejnerizirane arhitekture utjecati na površinu napada za svaku.