Programování

Linuxové kontejnery vs. virtuální počítače: Porovnání zabezpečení

Vývojáři milují kontejnery. Snadno se používají a rychle se spouští. Spoustu z nich můžete spustit i na jednoduchém hardwaru. Režie při spuštění vždy byla překážkou vývoje a testování a tato režie se zvyšuje pouze u architektur mikroslužeb. Pokud vývojář potřebuje půl tuctu služeb, mohl by snadno promarnit den nebo dva instalací - konfigurací hardwaru, spuštěním instalačních programů, bojem proti nekompatibilitě.

S kontejnery se to zhroutí na minuty nebo sekundy a lze je spustit na jedné vývojové pracovní stanici. Snadno dostupná úložiště užitečných obrazů kontejnerů znásobují produktivitu vývojářů podobně jako open source, ale bez problémů s vytvářením. Operační týmy přijímaly kontejnery pomaleji. Jedním z důvodů je, že mnoho aplikací, které musí podporovat, ještě není v kontejneru. Dalším důvodem je neochota vzdálit se od virtuálních počítačů.

U operátorů byl přechod z holého kovu na virtuální počítače přirozený. Jednotlivé virtuální počítače vypadají a lze je spravovat jako jednotlivé systémy pomocí stejných nástrojů a procesů. Rané obavy o zabezpečení virtuálních počítačů byly rozptýleny dlouhou produkční historií virtuálních počítačů ve světě sálových počítačů, schopností používat stejné ovládací prvky, jaké se používají pro systémy typu bare-metal, podporou virtualizace hardwaru a vyvíjející se vyspělostí nástrojů pro správu virtuálních počítačů.

Mnoho raných bezpečnostních starostí padlo na jednu otázku: Byly virtuální počítače stejně bezpečné jako holý kov? Nyní se kolem kontejnerů objevují podobné otázky. Jak bezpečné jsou kontejnery a jak se porovnávají s virtuálními počítači? Jistě, pokud porovnáme služby běžící v kontejnerech se stejnými službami běžícími jako samostatné procesy ve stejném systému, verze kontejneru je bezpečnější. Oddělení poskytované jmennými prostory a cgroups Linuxu poskytuje bariéry, které mezi prostými procesy neexistují. Srovnání s virtuálními počítači je méně jasné. Pojďme se podívat na virtuální počítače a kontejnery z hlediska zabezpečení.

V tomto článku vezmu dva různé přístupy k porovnání zabezpečení virtuálních počítačů a kontejnerů. První přístup bude strukturálnější nebo teoretičtější a bude se zabývat charakteristikami každého z hlediska bezpečnosti. Poté použiji praktičtější analýzu, když se podívám na to, co se stane při typickém porušení a jak to může být ovlivněno architekturou kontejnerů a virtuálních počítačů.

Strukturální pohled

Pro strukturální přístup porovnám útočnou plochu obou systémů. Útočná plocha představuje počet bodů, na které lze zaútočit na systém. Není přesně definován (například jako číslo), ale je užitečný pro srovnání. Zloděj má dům s 10 dveřmi větší útočnou plochu než dům s jedněmi dveřmi, i když jsou stejné. Jedny dveře mohou být odemčené; jeden zámek může být vadný; dveře na různých místech mohou vetřelci nabídnout více soukromí atd.

V počítačových systémech zahrnuje útočná plocha cokoli, kde se útočník (nebo software jednající jeho jménem) může „dotknout“ cílového systému. Síťová rozhraní, hardwarová připojení a sdílené prostředky jsou všechny možné body útoku. Upozorňujeme, že plocha útoku neznamená, že existuje skutečná chyba zabezpečení. Všech 10 dveří může být dokonale zabezpečených. Větší útočná plocha však znamená více chráněných míst a větší pravděpodobnost, že útočník najde slabost alespoň v jednom.

Celková útočná plocha závisí na počtu různých kontaktních bodů a složitosti každého z nich. Podívejme se na jednoduchý příklad. Představte si staromódní systém, který poskytuje nabídky na akciovém trhu. Má jediné rozhraní, jednoduchou sériovou linku. Protokol na tomto řádku je také jednoduchý: Na server je odeslán burzovní symbol pevné délky, řekněme pět znaků, který odpoví cenovou nabídkou pevné délky - řekněme 10 znaků. Neexistuje ethernet, TCP / IP, HTTP atd. (Vlastně jsem na takových systémech pracoval už dávno v galaxii daleko, daleko.)

Útočná plocha tohoto systému je velmi malá. Útočník může manipulovat s elektrickými charakteristikami sériové linky, odesílat nesprávné symboly, odesílat příliš mnoho dat nebo jinak měnit protokol. Ochrana systému by zahrnovala implementaci příslušných kontrol proti těmto útokům.

Nyní si představte stejnou službu, ale v moderní architektuře. Tato služba je k dispozici na internetu a zpřístupňuje rozhraní RESTful API. Elektrická stránka útoku je pryč - vše, co uděláte, je smažit vlastní router nebo přepínač útočníka. Ale protokol je nesmírně složitější. Má vrstvy pro IP, TCP, případně TLS a HTTP, přičemž každá nabízí možnost zneužití zranitelnosti. Moderní systém má mnohem větší útočnou plochu, i když na útočníka stále vypadá jako jediný bod rozhraní.

Útočná plocha z holého kovu

Pro útočníka, který není fyzicky přítomen v datovém centru, je počáteční útočnou plochou síť do serveru. To vedlo k „perimetrickému pohledu“ na bezpečnost: Chraňte vstupní body do datového centra a nic se dovnitř nedostane. Pokud se útočník nemůže dostat dovnitř, nezáleží na tom, co se děje mezi systémy uvnitř. Fungovalo to dobře, když byla obvodová rozhraní jednoduchá (myslím vytáčené připojení), ale podporovala slabosti vnitřních rozhraní. Útočníci, kteří našli díru v obvodu, často zjistili, že vnitřní útočná plocha serverové farmy byla mnohem větší než ta vnější a mohli by uvnitř způsobit značné škody.

Tato interní plocha útoku zahrnovala síťová připojení mezi servery, ale také interakce mezi procesy v rámci jednoho serveru. Horší je, že protože mnoho služeb běží se zvýšenými oprávněními (uživatel „root“), úspěšné vloupání do jedné by ve skutečnosti znamenalo neomezený přístup ke všemu jinému v tomto systému, aniž by bylo nutné hledat další chyby zabezpečení. Celé odvětví vyrostlo kolem ochrany serverů - brány firewall, antimalware, detekce narušení atd. - s méně než dokonalými výsledky.

Existují také zajímavé „postranní kanály“ útoky proti serverům. Vědci ukázali příklady využití spotřeby energie, šumu nebo elektromagnetického záření z počítačů k získávání informací, někdy velmi citlivých dat, jako jsou kryptografické klíče. Jiné útoky využily exponovaná rozhraní, jako jsou protokoly bezdrátové klávesnice. Obecně jsou však tyto útoky obtížnější - mohou například vyžadovat blízkost serveru - takže hlavní cesta „po drátě“ je častější.

Útočná plocha VM

Když se virtuální počítače používají stejným způsobem jako bare metal, bez jakéhokoli rozdílu v architektuře aplikace (jak často jsou), sdílejí většinu stejných bodů útoku. Jedním dalším povrchem útoku je potenciální selhání hypervizoru, operačního systému nebo hardwaru pro správnou izolaci prostředků mezi virtuálními počítači, což umožňuje virtuálnímu počítači nějak přečíst paměť jiného virtuálního počítače. Rozhraní mezi virtuálním počítačem a hypervisorem také představuje bod útoku. Pokud virtuální počítač dokáže prorazit a získat v hypervisoru spuštěný libovolný kód, může přistupovat k dalším virtuálním počítačům ve stejném systému. Samotný hypervisor představuje bod útoku, protože odhaluje rozhraní pro správu.

V závislosti na typu systému VM existují další útočné body. Systémy VM typu 2 používají hypervisor běžící jako proces na podkladovém hostitelském OS. Na tyto systémy lze zaútočit útokem na hostitelský operační systém. Pokud útočník dokáže spustit kód v hostitelském systému, může potenciálně ovlivnit hypervisor a virtuální počítače, zejména pokud může získat přístup jako privilegovaný uživatel. Přítomnost celého operačního systému, včetně nástrojů, nástrojů pro správu a případně dalších služeb a vstupních bodů (například SSH), poskytuje řadu možných bodů útoku. Systémy VM typu 1, kde hypervisor běží přímo na základním hardwaru, tyto vstupní body eliminují, a proto mají menší útočnou plochu.

Útočná plocha kontejneru

Stejně jako u virtuálních počítačů sdílejí kontejnery základní útočné body vstupu do sítě systémů s holým kovem. Kromě toho, stejně jako virtuální stroje typu 2, podléhají kontejnerové systémy, které používají „plně načtený“ hostitelský OS, všechny stejné útoky dostupné proti utilitám a službám daného hostitelského OS. Pokud útočník může získat přístup k tomuto hostiteli, může se pokusit získat přístup nebo jinak ovlivnit spuštěné kontejnery. Pokud získá privilegovaný („root“) přístup, útočník bude mít přístup nebo kontrolu nad jakýmkoli kontejnerem. „Minimalistický“ OS (jako je například KurmaOS od společnosti Apcera) může pomoci snížit tento povrch útoku, ale nemůže jej zcela eliminovat, protože pro správu kontejnerů je vyžadován určitý přístup k hostitelskému OS.

Základní mechanismy oddělení kontejnerů (jmenné prostory) také nabízejí potenciální útočné body. Navíc ne všechny aspekty procesů v systémech Linux mají jmenný prostor, takže některé položky jsou sdíleny napříč kontejnery. Toto jsou přirozené oblasti, které mohou útočníci zkoumat. Nakonec je rozhraní procesu k jádru (pro systémová volání) velké a vystavené v každém kontejneru, na rozdíl od mnohem menšího rozhraní mezi virtuálním počítačem a hypervisorem. Zranitelnosti v systémových voláních mohou nabídnout potenciální přístup k jádru. Jedním z příkladů je nedávno nahlášená chyba zabezpečení v linuxovém kroužku na klíče.

Architektonické úvahy

U virtuálních počítačů i kontejnerů může být velikost povrchu útoku ovlivněna architekturou aplikace a tím, jak se technologie používá.

Mnoho starších aplikací virtuálních počítačů zachází s virtuálními počítači jako s holým kovem. Jinými slovy, nepřizpůsobili své architektury konkrétně pro virtuální počítače nebo pro modely zabezpečení, které nejsou založeny na obvodovém zabezpečení. Mohou instalovat mnoho služeb na stejný virtuální počítač, spouštět služby s oprávněními uživatele root a mít mezi službami málo nebo žádné ovládací prvky zabezpečení. Rearchitekce těchto aplikací (nebo pravděpodobnější jejich nahrazení novějšími) může pomocí virtuálních počítačů zajistit oddělení zabezpečení mezi funkčními jednotkami, nikoli jen jako prostředek ke správě většího počtu strojů.

Kontejnery jsou vhodné pro architektury mikroslužeb, které „spojují dohromady“ velké množství (obvykle) malých služeb pomocí standardizovaných API. Takové služby mají často velmi krátkou životnost, kdy je kontejnerová služba spuštěna na vyžádání, reaguje na požadavek a je zničena, nebo když jsou služby rychle zvyšovány a snižovány na základě poptávky. Tento vzor použití závisí na rychlé instanci, kterou kontejnery podporují. Z hlediska bezpečnosti to má výhody i nevýhody.

Větší počet služeb znamená větší počet síťových rozhraní a tím i větší útočnou plochu. Umožňuje však také více ovládacích prvků na síťové vrstvě. Například na platformě Apcera musí být výslovně povolen veškerý provoz z kontejneru na kontejner. Darebácký kontejner se nemůže libovolně dostat k žádnému síťovému koncovému bodu.

Krátká životnost kontejneru znamená, že pokud se útočník dostane dovnitř, čas, který musí udělat, je omezený, na rozdíl od okna příležitosti, které nabízí dlouhotrvající služba. Nevýhodou je, že forenzní vědy jsou těžší. Jakmile je kontejner pryč, nelze jej zkoumat a zkoumat, aby se zjistil malware. Tyto architektury také útočníkovi ztěžují instalaci malwaru, který přežije po zničení kontejneru, protože by mohl na holém kovu nainstalovat ovladač, který se načte při spuštění. Kontejnery se obvykle načítají z důvěryhodného úložiště jen pro čtení a lze je dále zabezpečit kryptografickými kontrolami.

Nyní se podívejme, co se děje během porušení.

Ochrana proti porušení

Útočníci mají obvykle jeden nebo dva cíle v prolomení do systému serveru. Chtějí získat data nebo poškodit.

Pokud jde o data, chtějí infiltrovat co nejvíce systémů s nejvyššími možnými oprávněními a udržovat tento přístup co nejdéle. Dosažení tohoto cíle jim poskytne čas na vyhledání dat, která by tam již mohla být - například špatně zabezpečená databáze - nebo by mohla vyžadovat pomalý sběr v průběhu času, jak to bude probíhat, jako je shromažďování transakcí, jak přicházejí od uživatelů. Dlouhodobé udržování přístupu vyžaduje utajení. Útok také vyžaduje způsob, jak data dostat ven.

Pokud se útočník snaží jednoduše poškodit, cílem je znovu získat přístup k co největšímu počtu systémů a oprávnění. Existuje však vyrovnávací akt: Jakmile začne škoda, pravděpodobně si ji všimnete, ale čím déle útočník čeká na spuštění (zatímco malware filtruje ze systému na systém), tím větší je pravděpodobnost odhalení. Získání dat je méně důležité než koordinovaná kontrola malwaru. Myšlenkou je infikovat co nejvíce systémů, pak je poškodit v synchronizovaném bodě, buď předem připraveném, nebo na povel.

Porušení zahrnuje řadu prvků. Podívejme se na každý z nich a podívejme se, zda virtuální počítače a kontejnerové architektury mohou ovlivnit útočnou plochu pro každého.

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