Detekce a prevence útoků typu únik z kontejneru

Home » PYTHON » Detekce a prevence útoků typu únik z kontejneru

Únik kontejnerů se stal jedním z témat, která nenechávají cloudové a platformní týmy spát v noci. protože jeden špatně nakonfigurovaný pod nebo zastaralé jádro může proměnit izolovanou pracovní zátěž v přímý most k podkladovému hostiteli. Když k tomu dojde, útočník již není omezen na jeden kontejner: může se pohybovat mezi uzly, přistupovat k datům z jiných klientů nebo dokonce převzít kontrolu nad celým clusterem.

Pochopení toho, jak escape kódy kontejnerů skutečně fungují – od interních funkcí Linuxu až po běhové signály a detekci EDR – je rozdílem mezi děsivým módním slovem a rizikem, které můžete skutečně zvládat.V této příručce si projdeme, co je kontejner na úrovni operačního systému, jak v praxi dochází k únikům dat, hlavní techniky zneužití, které se v praxi používají, a jak je detekovat a předcházet jim pomocí monitorování schopností, pravidel Falco, platforem CNAPP a starého dobrého hardeningu a segmentace.

Co je to únik kontejneru a proč je důležitý?

K úniku kontejneru dochází, když se útočníkovi podaří prolomit logickou izolaci, která by měla oddělovat kontejner od hostitele a od ostatních kontejnerů.Místo omezení na vlastní jmenné prostory a cgroupy získává útočník možnost spouštět kód s kontextem na úrovni hostitele – často s vysokými nebo plnými oprávněními.

Kontejnery se od virtuálních počítačů liší zásadním způsobem: všechny sdílejí stejné hostitelské jádro.Technologie jako jmenné prostory Linuxu (PID, mount, network atd.), cgroups a funkce rozdělují jádro na mnoho izolovaných pohledů, ale pokud zranitelnost nebo špatná konfigurace umožní útočníkovi překročit tyto hranice, může se kompromitace rozšířit daleko za hranice původně napadeného kontejneru.

Z obchodního hlediska je právě poloměr výbuchu při úspěšném úniku to, co ho činí tak nebezpečným.Jeden zranitelný kontejner s přístupem k internetu může vést ke krádeži citlivých dat, hromadnému nasazení kryptoměnových těžařů, narušení kritických služeb a závažným problémům s dodržováním předpisů v prostředí s více klienty nebo v regulovaných prostředích.

Útočníci obvykle používají únik kontejneru jako jeden krok v širším řetězci útoků.: přistanou v kontejneru s nízkými oprávněními (kvůli chybám aplikace, slabým přihlašovacím údajům nebo problémům s dodavatelským řetězcem), zvýší oprávnění uvnitř kontejneru a poté se probojují k hostiteli, aby se laterálně otočili, získali přihlašovací údaje nebo vytvořili trvalou perzistenci, jako je rootkit na úrovni jádra.

Jak kontejnery fungují pod kapotou

Abyste skutečně pochopili techniky úniku, potřebujete nejprve mentální model toho, jak linuxové kontejnery izolují procesy.Kontejner je v podstatě strom procesů, jehož atributy (jmenné prostory, schopnosti, kontrolní skupiny, profil seccomp atd.) byly upraveny běhovým prostředím kontejneru, jako je containerd, Docker nebo CRI-O a širší. kontejnerizační technologie.

Když je kontejner spuštěn, běhové prostředí spustí proces a promění ho v „inicializační“ proces vlastního malého vesmíru.: získá svůj vlastní jmenný prostor PID, jmenný prostor připojení, jmenný prostor sítě a další, vše vynucené jádrem. Tento proces poté provede jakýkoli příkaz definovaný v konfiguraci obrazu (např. ENTRYPOINT/CMD souboru Dockerfile).

Možnosti jsou způsob, jakým Linux rozděluje tradiční všemocný root na menší části s oprávněními.Místo „root může dělat všechno“ jádro definuje příznaky jako například CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG a desítky dalších. Každé vlákno nese sady schopností (povolených, efektivních, dědičných), které definují, které privilegované operace může provádět.

Jmenné prostory odpovídají na otázku „kde může proces uplatnit své pravomoci?“Například jmenný prostor PID odděluje PID 1 uvnitř kontejneru od PID 1 na hostiteli a jmenný prostor mount dává kontejneru vlastní zobrazení souborového systému. I když má proces funkci jako CAP_KILL, v omezeném jmenném prostoru PID může ukončit pouze procesy, které v tomto jmenném prostoru existují.

Cgroups doplňují tuto izolaci tím, že řídí, kolik zdrojů může kontejner spálit. – Sdílení CPU, limity paměti, I/O a další. V kombinaci s filtry seccomp (seznamy povolených/zakázaných systémových volání) a LSM, jako je AppArmor nebo SELinux, získáte vrstvenou izolaci, na které závisí moderní zabezpečení kontejnerů.

Proč se útočníci snaží uniknout z kontejnerů

Jakmile protivník naruší kontejner, rychle zjistí, že život uvnitř je poměrně omezený.omezený souborový systém, omezený síťový přístup, možná bez oprávnění root a obvykle žádný přímý přístup k jiným úlohám.

Útěk k hostiteli odstraňuje tyto zábranyPokud mohou spouštět příkazy v počátečních jmenných prostorech hostitele, mohou vidět všechny procesy, připojit jakýkoli souborový systém, shromažďovat přihlašovací údaje z míst jako /root/.ssh nebo agenty cloudových metadat a převádějí se do jiných kontejnerů nebo virtuálních počítačů.

Úniky také umožňují těžko vymýtitelnou perzistenciMísto umístění backdooru pouze v přechodném kontejneru by útočník mohl nainstalovat modul jádra, manipulovat s běhovými prostředími kontejneru, jako je runc nebo containerd, nebo nasadit démonset, který zajistí, že backdoorovaný pod běží na každém uzlu v clusteru Kubernetes.

Z hlediska detekce se mnoho signálů o úniku kontejneru překrývá s klasickým chováním eskalace privilegií a laterálního pohybu. – načítání modulů jádra, podezřelé mount/unshare/setns použití, přímý přístup k běhovým soketům, zneužití SUID a abnormální přístupy k souborům na cestách hostitele vystavených uvnitř kontejnerů.

Hlavní cesty k úniku z kontejneru: zranitelnosti, oprávnění a špatné konfigurace

Většina reálných scénářů úniku z kontejnerů se dělí do tří širokých kategoriízneužívání zranitelností (jádra nebo běhového prostředí), zneužívání kontejnerů s příliš vysokými privilegiemi nebo zneužívání chybných konfigurací, jako jsou nebezpečné připojení a odhalené sockety.

Zranitelnosti běhového prostředí jádra a kontejnerů

Protože každý kontejner sdílí hostitelské jádro, může jediná chyba jádra nabídnout přímou cestu k úniku.Známé problémy jako Dirty COW (CVE‑2016‑5195) a Dirty Pipe (CVE‑2022‑0847) jsou lokální chyby eskalace oprávnění, které útočníkům umožňují zapisovat do mapování pouze pro čtení a libovolných souborů, což jim často umožňuje manipulovat s binárními soubory hostitele nebo konfigurací z kontejneru.

Jednou obzvláště kritickou chybou specifickou pro kontejner byla chyba CVE-2019-5736 v runc.Umožňoval procesu v kontejneru přepsat binární soubor runc na hostiteli při spuštění nebo provedení tohoto kontejneru, což útočníkovi umožnilo spuštění kódu na úrovni hostitele. Vzhledem k tomu, že runc je základem Dockeru, Kubernetes a dalších platforem, měl široký dopad.

V nedávné době odhalení jako „Leaky Vessels“ (např. CVE‑2024‑21626) ukázala, že systémy sestavení a startupové strategie jsou také úrodnou půdou.Zranitelnosti v logice inicializace BuildKitu nebo runcu umožňují útočníkům proniknout do systému během sestavování image nebo raného spouštění kontejneru, než mohou být plně použity ostatní obranné mechanismy.

Démony běhového prostředí kontejnerů, jako například container, Docker Engine nebo CRI-O, měly svůj vlastní podíl chyb.Například chyba CVE‑2022‑23648 v pluginu CRI od containerdu umožňovala útočníkům, kteří mohli vytvářet kontejnery, připojovat citlivé cesty k hostitelům (jako /root/.ssh) do kontejneru a číst data, která by nikdy neměli vidět, což poskytuje odrazový můstek k úplnému úniku.

Významné CVE způsobené únikem kontejnerů a jak je zmírnit

• CVE‑2019‑5736 (běh): povoleno přepsání binárního souboru runc hostitele z kontejneru, což má dopad na Docker, Kubernetes a další stacky založené na runc. Mezi opatření k posílení ochrany patří agresivní záplatování, skenování obrazů s cílem najít nástroje pro zneužití a monitorování binárních modifikací runc za běhu.

• CVE‑2016‑5195 (Špinavá kráva): soubojový stav v kopírování při zápisu, který umožňuje neprivilegovaným procesům získat přístup k mapování pouze pro čtení pro zápisZ kontejneru by mohl být zneužit ke změně hostitelských souborů, pokud by byly zpřístupněny prostřednictvím připojení.

• CVE‑2022‑0847 (Znečištěné potrubí): další chyba jádra umožňující neoprávněný zápis do souborů, včetně těch, které jsou připojeny pouze pro čtení do kontejnerůNeposkytuje automaticky escape, ale pěkně se propojuje s privilegovanými připojeními nebo chybnými konfiguracemi za běhu.

• CVE‑2024‑21626 a související problémy s „netěsnými nádobami“: Chyby v BuildKitu a runcu, které zpřístupňovaly hostitelské zdroje během sestavování obrazu nebo spouštění kontejneru., což dokazuje, že samotný proces sestavení může být součástí útočné plochy.

Zmírnění celé této třídy problémů se točí kolem hygieny záplat a architektonických voleb.: udržovat hostitelská jádra aktualizovaná, používat minimální nebo nedistribuované základní obrazy pro zmenšení plochy pro útok, upřednostňovat sandboxové nebo virtuální běhové prostředí pro vysoce citlivé úlohy a průběžně sledovat podezřelá systémová volání a zápisy do souborů, které vypadají jako pokusy o zneužití jádra.

Nadměrné kapacity a privilegované kontejnery

Byly vynalezeny schopnosti, které by měly snížit sílu kořene, ale v praxi se „malé kousky“ často shlukují zpět dohromady.Vývojáři, kteří jsou pod tlakem, aby „to prostě fungovalo“, často udělují CAP_SYS_ADMIN nebo jednoduše spouštět kontejnery jako --privileged, čímž se uvnitř kontejneru efektivně obnovuje kořenová síla.

CAP_SYS_ADMIN je notoricky přemoženumožňuje připojování souborových systémů, vytváření nebo spojování jmenných prostorů (unshare, setns), úprava cgroups a další. Se správnou kombinací připojení a jmenných prostorů se útočník s touto schopností může dostat do původního jmenného prostoru hostitele a získat globální viditelnost.

CAP_NET_ADMIN je z hlediska sítě podobně širokýLze jej použít k překonfigurování rozhraní, manipulaci s pravidly iptables a povolení promiskuitního režimu. V escape chainu by mohl být zneužit k odposlechu provozu, obcházení síťových politik nebo tunelování kolem segmentace.

Spuštění kontejneru v plně privilegovaném režimu v podstatě říká „považujte to za součást hostitele“.Získává všechny funkce, může přistupovat k hostitelským zařízením a často obchází profily seccomp. Pro mnoho útočných řetězců je nejtěžším krokem jednoduše najít jeden takový špatně nakonfigurovaný kontejner a poté ho použít jako odpalovací můstek.

Moderní nástroje, jako je Falco, začaly zpřístupňovat detekční funkce na úrovni vláken.Nyní můžete kontrolovat pole jako například thread.cap_effective, thread.cap_permitted a thread.cap_inheritable za běhu a spouštět upozornění vždy, když proces s rizikovými schopnostmi provede podezřelé akce.

Špatné konfigurace: připojení, sockety a triky s protokolováním

Překvapivě velký podíl úniků kontejnerů se nespoléhá na exotické 0-dny, ale na prosté chybné konfigurace.Když operátoři připojují citlivé cesty k hostitelům do kontejnerů nebo zpřístupňují interní unixové sockety, útočníci se často mohou dostat přímo skrz ně.

Klasickým příkladem jsou nebezpečné cesty hostitele nebo připojení svazků.Pokud kontejner získá přístup pro čtení i zápis do adresářů, jako je /etc, /proc, /sys or /var/run od hostitele se model izolace do značné míry hroutí. Zápis do /proc/sys nebo sysfs může měnit parametry jádra; přístup ke konfiguračním souborům hostitele, jako je /etc/shadow může dojít k úniku přihlašovacích údajů.

Docker socket (/var/run/docker.sock) a další běhové sockety představují další bolestivou chybnou konfiguraciMontáží tohoto uvnitř kontejneru získáte od toho, kdo kontejner ovládá, téměř plnou kontrolu nad démonem Dockeru. Prostřednictvím simple curl --unix-socket volání, útočník může vypsat kontejnery, vytvořit nový privilegovaný kontejner, který připojí kořenový adresář hostitele, a opustit tento pomocný kontejner.

V Kubernetes byla také zneužívána manipulace s protokoly v Kubeletu a připojování protokolů hostitele.Pokud má pod hostitele /var/log Pokud je připojen bind-mounted a útočník může manipulovat se symbolickými odkazy protokolů a číst protokoly prostřednictvím API, může být schopen odkazovat na libovolné hostitelské soubory a obelstít Kubelet, aby vrátil například /etc/shadow Obsah.

I zdánlivě jednoduché chování SUID může hrát roliV prostředích, kde kontejner sdílí jmenný prostor uživatelů s hostitelem, může nastavení bitu SUID u binárního souboru ve sdíleném adresáři z kontejneru později použít uživatel hostitele s nízkými oprávněními ke spuštění daného programu s oprávněními root na hostiteli.

Techniky úniku z betonových kontejnerů pozorované ve volné přírodě

Přiblížení z kategorií na konkrétní techniky vám pomůže rozpoznat vzorce v telemetrii a hlášeních o hrozbách.Několik skupin metod bylo opakovaně demonstrováno výzkumníky a použito v penetračních testech nebo reálných útocích.

Pomocníci uživatelského režimu a release_agent trik

Linuxové jádro zpřístupňuje funkci, call_usermodehelper, spouštět programy v uživatelském prostředí se zvýšenými oprávněními v reakci na události v kernelovém prostoruZa správných podmínek mohou uživatelem ovládané soubory ovlivnit, který program se spustí, a proměnit tak legitimní mechanismus v únikový vektor.

Cgroups v1 release_agent je nejznámějším příkladem tohoto vzoruKdyž se kontrolní skupina vyprázdní a notify_on_release je povoleno, jádro spustí binární soubor, na který odkazuje release_agent soubor. Pokud útočník uvnitř kontejneru může připojit a manipulovat se souborovým systémem cgroup s dostatečnými oprávněními, může ukázat release_agent na libovolném spustitelném souboru na hostiteli.

Typická sekvence exploitu vypadá zhruba takto: vytvořit a připojit adresář cgroup, povolit notify_on_release, nastavit release_agent do cesty škodlivého skriptu v jmenném prostoru hostitele a poté vyprázdní seznam procesů kontrolní skupiny. Jádro ochotně spustí útočníkův skript s oprávněními root na hostiteli.

Detekce vyžaduje jak sémantické pochopení pomocných cest uživatelského režimu, tak kontext, odkud změny pocházejí.Robustní přístup mapuje všechny call_usermodehelper volání webů, identifikuje ty, které mohou být ovlivněny soubory uživatelského režimu, a poté monitoruje zápisy do těchto souborů, když pocházejí z kontejnerů, a signalizuje podezřelé úpravy.

Eskalace oprávnění k hostiteli pomocí bitů SUID

Technika SUID není „čistým“ únikem z kontejneru, protože předpokládá, že útočník již má nějaký přístup k hostiteli., ale často je zřetězen s přístupem ke kontejneru, aby se dalo přeskočit z omezených uživatelů hostitele na root.

Trik spočívá ve sdílených adresářích mezi hostitelem a kontejnerem a sdíleném uživatelském jmenném prostoru.Z kontejneru spuštěného jako root útočník vloží spustitelný soubor do adresáře viditelného na obou stranách (například sdílený svazek) a nastaví bit SUID na chmod u+s.

Později uživatel bez oprávnění root na hostiteli spustí tento binární soubor a získá root oprávnění na hostiteli., protože bit SUID je interpretován v kontextu hostitele. Kontejner se používá jako vhodné místo pro přípravu dat SUID bez omezení, která by mohla existovat pro daného hostitelského uživatele.

Viditelnost zneužívání SUID se zaměřuje na tři momentyVytvoření spustitelného souboru ve sdílené cestě, nastavení bitů SUID/SGID z kontejneru a spuštění tohoto souboru na hostiteli nerootovým účtem. Nástroje EDR a běhové zabezpečení mohou tyto kroky propojit a vyvolat tak vysoce přesná upozornění.

Zneužívání běhového socketu: Docker a containerd

Kontejnerová prostředí se často spoléhají na architekturu klient/server, kde nástroje CLI nebo orchestratory komunikují s démony prostřednictvím unixových socketů.. Příklady zahrnují /var/run/docker.sock pro Docker nebo /run/containerd/containerd.sock pro kontejnery.

Pokud jsou tyto socketové soubory připojeny uvnitř kontejneru, může tento kontejner efektivně fungovat jako administrátorský klient.Útočník, který kontejner kompromituje, může odesílat požadavky API přímo do běhového prostředí, vypisovat kontejnery, spouštět a zastavovat úlohy nebo vytvářet zcela nový privilegovaný kontejner s připojeními hostitele.

Použití obecného nástroje, jako je curl, je triviální spustit vzdálené API Dockeru přes Unixový socketdotaz /containers/json vyjmenovat kontejnery, odeslat na /containers/create s definicí JSON pro vytvoření privilegovaného pomocníka a poté zavolejte /containers/{id}/start spustit ho. Tento pomocný kontejner může připojit kořenový souborový systém hostitele a poskytnout útočníkovi interaktivní přístup.

Obránci to mohou hledat různými způsoby.monitorování přístupu k běhovým unixovým socketům z kontejnerizovaných procesů, detekce podezřelých curl --unix-socket nebo volání CLI za běhu cílící na tyto sockety a upozorňující na neobvyklé vzorce vytváření kontejnerů (např. hostPath se připojuje k /, --privileged ve specifikacích Kubernetes).

Triky specifické pro Kubernetes: připojení logů a úniky podů

V Kubernetes se některé útoky zaměřují na chování Kubeletu a abstrakce Kubernetes spíše než na surové koncepty Dockeru.Pody, které připojují hostitelské adresáře, jako například /var/log or /var/lib/docker jsou obzvláště zajímavé pro protivníky.

Jedna demonstrovaná metoda zneužívá způsob, jakým Kubelet řeší symbolické odkazy při vracení logů.Každý pod dostane soubor protokolu pod /var/log který symbolicky odkazuje do adresáře kontejneru pod /var/lib/docker/containersPokud útočník může vytvořit nebo upravit symbolické odkazy v /var/log prostřednictvím připojení hostPath mohou přesměrovat „log“ tak, aby ukazoval na libovolný soubor (například /etc/shadow).

Když uživatelský nebo servisní účet s oprávněním ke čtení protokolů volá kubectl logs nebo odpovídající API, kubelet sleduje symbolický odkaz a vrací obsah daného cíleS trochou kreativity může útočník odhalit velké části hostitelského souborového systému prostřednictvím série takových symbolicky odkazovaných „logů“.

Detekce zde kombinují síťové a souborové systémymonitorovat HTTP požadavky na čtení protokolů Kubernetes, zda neobsahují abnormální vzory cest, a současně sledovat vytváření nebo úpravy symbolických odkazů v adresáři hostitele /var/log které pocházejí z kontejnerizovaných procesů.

Citlivé připojení hostitelů a přímá krádež dat

Někdy escape spočívá pouze v načtení nebo úpravě dat hostitele z kontejneru bez nutnosti spuštění kódu na úrovni hostitele.Špatně nakonfigurované připojení, která zpřístupňují citlivé adresáře, stačí k dosažení vážného dopadu.

Například kontejner může mít úchyt jako /host_etc ukazující na hostitele /etc adresářÚtočník, který na tuto cestu narazí, může jednoduše otevřít /host_etc/passwd or /host_etc/shadow a efektivně čtou soubory pro ověřování hostitele přímo z kontejneru.

Odhalení zneužití takových připojení je složité, protože mnoho přístupových vzorů vypadá podobně jako běžné operace se soubory.Nemůžeš se jen dívat /etc/shadow uvnitř kontejnerů, protože se to obvykle vztahuje k vlastnímu souboru kontejneru, nikoli k souboru hostitele. Potřebujete mapovací vrstvu, která pro každé připojení převede „cestu kontejneru“ na „cestu podkladového hostitele“.

Pokročilé nástroje EDR a CNAPP to řeší rozpoznáváním bodů připojení a sledováním přístupů na základě cesty na straně hostitele.Tímto způsobem lze v reálném čase označit jakékoli čtení nebo zápis, které se nakonec dotkne souboru citlivého na hostitele – a to i prostřednictvím neškodně vypadající cesty uvnitř kontejneru.

Detekce pokusů o únik z kontejneru za běhu

Preventivní otužování je nezbytné, ale také potřebujete mít dobrý přehled o tom, co se děje během provozu kontejnerů.Moderní útoky často řetězí více kroků a robustní monitorování za běhu vám dává šanci zachytit řetězec dříve, než dorazí k hostiteli.

Nejmodernější detekce obvykle kombinuje nízkoúrovňovou telemetrii (např. trasování systémových volání založené na eBPF) s behaviorální analýzou a cloudovým kontextem.Nezpracované signály pocházejí ze systémových volání, operací se soubory, stromů procesů a aktivity socketů; analytická vrstva je koreluje s identitami, expozicí v síti a cloudovými prostředky, aby oddělila neškodné administrátorské akce od skutečných pokusů o únik.

Klíčové indikátory na úrovni systémových volání

Některá systémová volání jsou silně spojena s aktivitou narušující hranice a měly by být podrobeny zvláštní kontrole, pokud jsou vyvolány kontejnery:

• mount, umount, pivot_root – manipulace s připojením souborového systému nebo otáčení kořenových adresářů, často používané k propojení cest hostitele s kontejnerem nebo k úniku z chrootů.

• setns, unshare – připojení k novým jmenným prostorům nebo jejich vytvoření, což je klíčový krok v technikách, které přecházejí do původního jmenného prostoru hostitele.

• ptrace – ladění nebo vkládání do jiných procesů; podezřelé při překračování hranic kontejneru nebo cílení na systémové démony.

• capset – modifikace funkcí za běhu, potenciálně použitelná k získání nových výkonných příznaků během provádění.

• init_module, finit_module – načítání modulů jádra z kontejneru je vysoce rizikové chování, které je u legitimních úloh zřídka potřeba.

Pravidla jako Falco umožňují vyjádřit logiku detekce nad těmito systémovými voláními způsobem s ohledem na kontejnery.Například můžete upozornit vždy, když kontejnerizovaný proces s CAP_SYS_ADMIN otevře soubor s názvem release_agent pro psaní, což je extrémně silný indikátor pokusu o únik z uživatelského režimu pomocí pomocníka.

Podezřelé vzorce přístupu k souborům

Monitorování integrity souborů a přístupu doplňuje systémová volání tím, že přesně ukazuje, kterých cest se útočník dotýká.Při pohledu optikou mapování kontejneru/hostitele se z toho stává silný detektor úniku.

• Píše komu /proc/sys or /sys z kontejnerového signálu se pokouší změnit parametry jádra nebo nastavení zařízení.

• Přístup k běhovým soketům kontejneru, jako například /var/run/docker.sock or /run/containerd/containerd.sock je varovným signálem, pokud pochází z kontejnerů pro obecné aplikace.

• Změny na /etc/passwd, /etc/shadow or /etc/sudoers na hostiteli prostřednictvím cest viditelných pro kontejner vypadají jako kroky eskalace oprávnění a perzistence.

• Čte z /proc/*/environ or /proc/*/cmdline napříč jmennými prostory může indikovat výčet procesů a sběr pověření mimo vlastní strom procesů kontejneru.

Nejspolehlivější upozornění kombinují více faktorů – cestu, systémové volání, možnosti a metadata kontejneru.. Například: mount systémové volání pocházející z kontejneru aplikace bez administrace, přístupného internetu, s CAP_SYS_ADMIN a cílení /proc/sys je mnohem alarmující než stejná operace ze známé privilegované údržbářské práce.

Signály na úrovni procesů a chování

Kromě nezpracovaných systémových volání a událostí souborů vykresluje chování procesů vyšší úrovně příběh o tom, co se děje.Některé aktivity jsou v běžných mikroslužbách extrémně neobvyklé, ale běžné ve fázích po exploataci.

• Interaktivní shell vytvořené z neinteraktivních kontejnerů (např, /bin/bash zobrazující se v rámci procesu webového serveru) naznačují praktickou aktivitu na klávesnici.

• Použití nástrojů pro eskalaci oprávnění, jako například sudo, su or newgrp uvnitř kontejnerů, zejména ty, které nejsou určeny pro interaktivní použití, je velmi podezřelé.

• Skenování sítě, nástroje pro laterální pohyb a neobvyklá odchozí připojení z kontejnerů, které by měly komunikovat pouze s malou sadou služeb, naznačují pokusy o průzkum nebo šíření.

• Podpisy kryptoměnových těžařů, neočekávané dlouhodobé procesy vázané na CPU nebo špičky ve využití GPU může odhalit, že útočník již využil svůj přístup na úrovni hostitele k monetizaci zdrojů.

Zde vynikají platformy EDR a CNAPP, které udržují „kauzální řetězec“ (strom procesů s předky a prostředím).Umožňují analytikům vysledovat podezřelé operace zpět k původnímu obrazu kontejneru, úlohě Kubernetes, cloudovému účtu nebo kanálu CI/CD, což zefektivňuje analýzu hlavních příčin a dlouhodobá řešení.

Prevence úniků z kontejnerů: hloubková ochrana

Žádná samostatná kontrola vám nezaručí, že se nikdy nesetkáte s pokusem o únik z kontejneru, takže potřebujete vícevrstvou ochranu od kódu až po cloud.To zahrnuje hygienu obrazu, minimální oprávnění, zesílené konfigurace, síťové kontroly a silnou ochranu za běhu.

Spouštět kontejnery s nejmenšími oprávněními

Začněte tím, že kontejnerům bezohledně odstraníte nepotřebná oprávnění.Vyhněte se privilegovanému režimu s výjimkou velmi vzácných, silně kontrolovaných případů a preferujte kontejnery bez oprávnění root nebo jmenné prostory uživatelů, aby se „root inside“ mapoval na neprivilegovaného uživatele na hostiteli.

V Kubernetes chytře využívejte nastavení securityContext. jako runAsNonRoot, runAsUser, allowPrivilegeEscalation: false a readOnlyRootFilesystem: trueTato omezení omezují, co může útočník udělat, i když plně ohrozí běhové prostředí aplikace.

Schopnosti by měly být úzce vymezené: ve výchozím nastavení vše zrušit a přidat pouze minimální sadu potřebnou pro danou úlohu. Pokud kontejner skutečně potřebuje CAP_SYS_ADMIN or CAP_NET_ADMIN, zacházejte s ním jako s vysoce rizikovým aktivem a obklopte ho dodatečným monitorováním a izolací sítě.

Pravidla detekce využívající pole schopností Falca mohou fungovat jako záchranná síť pro případ, že by se mohly vytratit nesprávné konfigurace.Například pravidlo se může spustit vždy, když kontejnerizované vlákno s CAP_SYS_ADMIN a CAP_DAC_OVERRIDE zapisuje do souboru s názvem release_agent, zachycení velkého množství únikových útoků s velmi nízkým šumem.

Zabezpečení dodavatelského řetězce kontejnerů

Většina kompromitací začíná před během systému, a to ve formě zranitelných nebo pozměněných obrazů.Robustní zabezpečení obrazu útočníkům v první řadě ztěžuje získání spolehlivého oporu.

Používejte zesílené, minimální základní obrazy z důvěryhodných registrů a udržujte je aktualizované.Menší obrazy s menším počtem balíčků znamenají méně knihoven, které by mohly obsahovat zneužitelné CVE, a dodavatelé jako Wiz nebo správci distribucí nyní poskytují „bezdistrolní“ základy pouze s tím, co je nezbytně nutné.

Integrace skenování zranitelností a softwarových kusovníků (SBOM) do CI/CDKaždé sestavení by mělo být před odesláním do registru naskenováno a obrazy s neopravenými vysoce závažnými nebo kriticky závažnými chybami, které souvisejí s jejich vystavením a oprávněními, by měly být z nasazení blokovány.

Zásady důvěryhodnosti obrázků uzavírají cyklusPodepisujte obrazy kryptograficky, konfigurujte řadiče přístupu tak, aby odmítaly nepodepsané nebo nedůvěryhodné obrazy, a udržujte přehled o tom, které obrazy jsou v průběhu času skutečně spuštěny v klastrech, abyste mohli rizikové artefakty včas vyřadit.

A konečně, upřednostňujte nápravu na základě skutečného rizika, nikoli hrubého počtu CVE.Kritická zranitelnost v nečinné, nesíťové dávkové úloze spuštěné bez dalších funkcí je méně naléhavá než „střední“ chyba v internetově připojeném, privilegovaném podu, který zpracovává citlivá data.

Segmentace sítě a ochrana za běhu

I když útočník zasáhne pouze jeden kontejner, chytrý návrh sítě mu může zabránit v tom, aby z toho udělal úplné narušení clusteru.Podrobné síťové zásady, firewally a servisní sítě pomáhají omezit laterální pohyb.

Implementujte síťové zásady ve stylu seznamu povolených v Kubernetes, takže pody mohou komunikovat pouze se službami, které skutečně potřebují. To omezuje schopnost útočníka skenovat cluster nebo volat interní API pro správu, jako je Docker socket nebo server Kubernetes API.

Systémy ochrany za provozu přidávají brzdy v reálném časeKdyž detekují chování odpovídající úniku kontejneru (například podezřelé nsenter použití, hostPath se připojuje k / nebo manipulace se socketem kontejneru), mohou blokovat nebo ukončovat procesy, izolovat kontejnery nebo automaticky otevírat incidenty s plnou forenzní stopou.

Platformy jako Wiz CNAPP kombinují tyto detekce za běhu s cloudovým kontextem a bezpečnostním grafem.Mapováním vztahů mezi kontejnery, hostiteli, identitami a úložišti dat ukazují nejen to, že dochází k úniku, ale také to, jaké citlivé prostředky se nacházejí v dosahu výbuchu, aby týmy mohly stanovit priority reakce.

Nepřetržité monitorování a připravenost na incidenty

Kontejnery mají krátkou životnost, což ztěžuje klasickou forenzní analýzu a analýzu protokolů.Pokud si to předem neplánujete, důkazy potřebné k pochopení útěku mohou zmizet, jakmile bude pod přeplánován.

Zavést centralizované protokolování a sběr metrik pro běhová prostředí kontejnerů, orchestrátory a hostiteleNástroje jako ELK, Prometheus a cloudové logovací služby zajišťují, že aktivita procesů, bezpečnostní události a změny konfigurace jsou zaznamenávány i u dočasných úloh.

Vytvořte herní plány speciálně pro scénáře úniku z kontejnerůTy by měly definovat, jak rychle uzly ohraničit, pořizovat snímky disků, shromažďovat metadata kontejnerů a koordinovat činnost s poskytovateli cloudových služeb nebo týmy pro reakci na incidenty, když máte podezření na únik nebo kompromitaci na úrovni hostitele.

Dodavatelé jako Palo Alto Networks (Cortex XDR, Prisma Cloud) a další vytvořili rozsáhlý detekční obsah zaměřený na zde popsané techniky., od zneužívání pomocných funkcí v uživatelském režimu až po zneužívání socketů za běhu a citlivý přístup k připojení, což obráncům poskytuje akční, kontextová upozornění namísto obecného šumu „podezřelé aktivity“.

Spojením všech těchto prvků dohromady – solidních základů izolace Linuxu, přísných oprávnění, zesílených obrazů, síťových kontrol a hlubokého přehledu o běhovém prostředí – se únik kontejneru z existenční hrozby stává zvládnutelným rizikem, které váš tým dokáže včas odhalit, efektivně omezit a poučit se z něj, aby v průběhu času dále posiloval vaše cloudové zabezpečení..