Detekcija i sprečavanje napada bježanja iz kontejnera

Početna » piton » Detekcija i sprečavanje napada bježanja iz kontejnera

Bijeg kontejnera postao je jedna od onih tema koje timove u oblaku i platformama drže budnima noću. jer jedan pogrešno konfiguriran pod ili zastarjeli kernel mogu pretvoriti izolirano radno opterećenje u direktan most prema osnovnom hostu. Kada se to dogodi, napadač više nije ograničen na jedan kontejner: može se kretati između čvorova, pristupati podacima drugih korisnika ili čak preuzeti cijeli klaster.

Razumijevanje kako escape-i kontejnera zaista funkcionišu – od Linux internih elemenata do signala za vrijeme izvođenja i EDR detekcija – je razlika između zastrašujuće popularne riječi i rizika kojim zapravo možete upravljati.U ovom vodiču ćemo objasniti šta je kontejner na nivou operativnog sistema, kako se escape-i dešavaju u praksi, glavne tehnike iskorištavanja koje se viđaju u praksi i kako ih otkriti i spriječiti pomoću praćenja mogućnosti, Falco pravila, CNAPP platformi i dobrog starog kaljenja i segmentacije.

Šta je izlaz iz kontejnera i zašto je važan?

Do izlaza iz kontejnera dolazi kada napadač uspije probiti logičku izolaciju koja bi trebala odvojiti kontejner od hosta i od drugih kontejnera.Umjesto da bude ograničen na vlastite imenske prostore i c-grupe, napadač dobija mogućnost pokretanja koda s kontekstom na nivou hosta – često s visokim ili punim privilegijama.

Kontejneri se razlikuju od virtuelnih mašina na ključan način: svi oni dijele isto jezgro hosta.Tehnologije poput Linux imenskih prostora (PID, montiranje, mreža, itd.), c-grupa i mogućnosti dijele taj kernel na mnogo izoliranih prikaza, ali ako ranjivost ili pogrešna konfiguracija omogući napadaču da prijeđe te granice, kompromitacija se može proširiti daleko izvan prvobitno hakiranog kontejnera.

Sa poslovne perspektive, radijus eksplozije uspješnog bijega je ono što ga čini tako opasnim.Jedan ranjivi kontejner povezan s internetom može dovesti do krađe osjetljivih podataka, implementacije kriptorudara u velikim razmjerima, poremećaja kritičnih usluga i većih problema s usklađenošću u okruženjima s više zakupaca ili reguliranim okruženjima.

Protivnici obično koriste izlaz iz kontejnera kao jedan korak u širem lancu napada.: slete u kontejner s niskim privilegijama (zbog grešaka u aplikaciji, slabih vjerodajnica ili problema s lancem opskrbe), eskaliraju privilegije unutar kontejnera, a zatim se probiju na host kako bi se lateralno prebacili, prikupili vjerodajnice ili uspostavili trajnu perzistenciju poput rootkita na razini kernela.

Kako kontejneri funkcionišu ispod haube

Da biste zaista shvatili tehnike izbjegavanja (escape), prvo vam je potreban mentalni model kako Linux kontejneri izoluju procese.Kontejner je u suštini stablo procesa čiji su atributi (imenski prostori, mogućnosti, cgrupe, seccomp profil itd.) prilagođeni od strane okruženja za izvršavanje kontejnera kao što su containerd, Docker ili CRI-O i šire. tehnologije kontejnerizacije.

Kada se kontejner pokrene, runtime pokreće proces i pretvara ga u "init" proces vlastitog malog univerzuma.: dobija svoj vlastiti PID imenski prostor, imenski prostor montiranja, imenski prostor mreže i još mnogo toga, a sve to nameće kernel. Taj proces zatim izvršava bilo koju naredbu definiranu u konfiguraciji slike (npr., ENTRYPOINT/CMD Dockerfile-a).

Mogućnosti su Linuxov način da tradicionalni svemoćni root režnje na manje dijelove dozvola.Umjesto "root može sve", kernel definira zastavice kao što su CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG i desetine drugih. Svaka nit nosi skupove mogućnosti (dozvoljenih, efektivnih, nasljednih) koje definiraju koje privilegovane operacije može izvršavati.

Imenski prostori odgovaraju na pitanje „gdje proces može ostvariti svoje ovlasti?“Na primjer, imenski prostor PID čini PID 1 unutar kontejnera nepovezanim sa PID 1 na hostu, a imenski prostor montiranja daje kontejneru vlastiti prikaz datotečnog sistema. Čak i ako proces ima mogućnost poput CAP_KILL, u ograničenom PID imenskom prostoru može ubiti samo procese koji postoje u tom imenskom prostoru.

C-grupe dopunjuju tu izolaciju kontrolisanjem koliko resursa kontejner može da sagori. – Dijeljenje CPU-a, ograničenja memorije, I/O i još mnogo toga. U kombinaciji sa seccomp filterima (liste dozvoljenih/zabranjenih sistemskih poziva) i LSM-ovima poput AppArmora ili SELinuxa, dobijate slojevitu izolaciju od koje zavisi moderna sigurnost kontejnera.

Zašto napadači pokušavaju pobjeći iz kontejnera

Kada protivnik ugrozi kontejner, brzo otkriva da je život unutra prilično ograničen.Ograničen datotečni sistem, ograničen mrežni prikaz, možda nekorijenski pristup i obično bez direktnog pristupa drugim radnim opterećenjima.

Bijeg do domaćina uklanja te zaštitne ogradeAko mogu izvršavati naredbe u početnim imenskim prostorima hosta, mogu vidjeti sve procese, montirati bilo koji datotečni sistem, prikupljati vjerodajnice s mjesta kao što su /root/.ssh ili agente za metapodatke u oblaku i premještaju se u druge kontejnere ili virtuelne mašine.

Bijegovi također omogućavaju teško iskorjenjivu perzistencijuUmjesto postavljanja backdoor-a samo u privremeni kontejner, napadač bi mogao instalirati kernel modul, mijenjati runtime kontejnera poput runc ili containerd, ili implementirati daemonset koji osigurava da se backdoor pod pokreće na svakom čvoru u Kubernetes klasteru.

Sa stanovišta detekcije, mnogi indikativni signali o bijegu kontejnera preklapaju se s klasičnim ponašanjem eskalacije privilegija i lateralnog kretanja. – učitavanje modula kernela, sumnjivo mount/unshare/setns korištenje, direktan pristup runtime socketima, iskorištavanje SUID-a i abnormalni pristupi datotekama host putanjama izloženim unutar kontejnera.

Glavni putevi ka izbjegavanju pristupa kontejneru: ranjivosti, privilegije i pogrešne konfiguracije

Većina scenarija bijega iz kontejnera u stvarnom svijetu spada u tri široke kategorijeiskorištavanje ranjivosti (kernela ili runtime-a), zloupotreba previše privilegovanih kontejnera ili iskorištavanje pogrešnih konfiguracija poput opasnih montiranja i izloženih socketa.

Ranjivosti u izvršavanju kernela i kontejnera

Budući da svaki kontejner dijeli glavni kernel, jedna greška u kernelu može ponuditi direktan put za bijeg.Poznati problemi poput Dirty COW (CVE‑2016‑5195) i Dirty Pipe (CVE‑2022‑0847) su lokalne greške u eskalaciji privilegija koje omogućavaju napadačima pisanje u mapiranja samo za čitanje i proizvoljne datoteke, što im često omogućava da mijenjaju binarne datoteke hosta ili konfiguraciju unutar kontejnera.

Jedan posebno kritičan bug specifičan za kontejner bio je CVE-2019-5736 u runc-u.Omogućio je procesu u kontejneru da prepiše binarni fajl runc na hostu kada se taj kontejner pokrene ili izvrši, dajući napadaču mogućnost izvršavanja koda na nivou hosta. Budući da runc podržava Docker, Kubernetes i druge platforme, uticaj je bio širok.

U novije vrijeme, otkrića poput „Leaky Vessels“ (npr. CVE‑2024‑21626) pokazala su da su sistemi izgradnje i startup putevi također plodno tlo.Ranjivosti u BuildKit-u ili logici inicijalizacije runc-a omogućavaju napadačima da probiju sistem tokom izgradnje slike ili ranog pokretanja kontejnera, prije nego što se druge odbrane mogu u potpunosti primijeniti.

Demoni za izvršavanje kontejnera kao što su containerd, Docker Engine ili CRI-O imali su svoj udio grešaka.Na primjer, CVE‑2022‑23648 u CRI dodatku kompanije containerds omogućio je protivnicima koji su mogli kreirati kontejnere da montiraju osjetljive putanje hosta (kao što /root/.ssh) u kontejner i čitaju podatke koje nikada ne bi trebali vidjeti, pružajući odskočnu dasku za potpuni bijeg.

Značajni CVE-ovi koji uzrokuju izbjegavanje kontejnera i kako ih ublažiti

• CVE‑2019‑5736 (runc): dozvoljeno prepisivanje runc binarne datoteke hosta iz kontejnera, što utiče na Docker, Kubernetes i druge runc-bazirane stekove. Mjere za jačanje sigurnosti uključuju agresivno krpljenje, skeniranje slika u potrazi za alatima za iskorištavanje i praćenje runtime modifikacija runc binarnih datoteka.

• CVE‑2016‑5195 (Prljava krava): Uslov utrke u kopiranju prilikom pisanja koji omogućava neprivilegovanim procesima da dobiju pristup pisanju u mapiranja samo za čitanjeIznutra kontejnera, moglo bi se zloupotrijebiti za izmjenu host datoteka ako su one bile izložene putem montiranja.

• CVE‑2022‑0847 (Prljava cijev): još jedna greška u kernelu koja omogućava neovlašteno pisanje u datoteke, uključujući i one montirane u kontejnere koji su samo za čitanjeNe dozvoljava automatski izlaz, ali se lijepo povezuje s privilegovanim montiranjima ili pogrešnim konfiguracijama tokom izvođenja.

• CVE‑2024‑21626 i povezani problemi sa „curenjem posuda“: Nedostaci u BuildKit-u i runc-u koji su otkrivali resurse hosta tokom izgradnje slike ili pokretanja kontejnera., što dokazuje da sam cjevovod izgradnje može biti dio površine napada.

Ublažavanja za cijelu ovu klasu problema vrte se oko higijene zakrpa i arhitektonskih izbora: održavajte kernele hosta ažuriranim, koristite minimalne ili osnovne slike bez distribucije kako biste smanjili površinu napada, preferirajte okruženja u sandboxu ili okruženja podržana virtuelnom mašinom za visokoosjetljiva opterećenja i kontinuirano pratite sumnjive sistemske pozive i pisanje datoteka koje izgledaju kao pokušaji iskorištavanja kernela.

Prekomjerne mogućnosti i privilegovani kontejneri

Mogućnosti su izmišljene kako bi se smanjila moć korijena, ali u praksi se "mali dijelovi" često ponovo skupe u jednu cjelinu.Programeri pod pritiskom da "samo natjeraju da radi" često odobravaju CAP_SYS_ADMIN ili jednostavno pokrenite kontejnere kao --privileged, efikasno vraćajući snagu sličnu korijenu unutar kontejnera.

CAP_SYS_ADMIN je notorno nadmoćan: omogućava montiranje datotečnih sistema, kreiranje ili pridruživanje imenskim prostorima (unshare, setns), podešavanje cgrupa i još mnogo toga. S pravom kombinacijom montiranja i imenskih prostora, napadač s ovom mogućnošću može se prebaciti u početni imenski prostor hosta i dobiti globalnu vidljivost.

CAP_NET_ADMIN je slično široko iz perspektive umrežavanjaMože se koristiti za rekonfiguraciju interfejsa, manipulisanje iptables pravilima i omogućavanje promiskuitetnog načina rada. U escape lancu, može se zloupotrebljavati za njuškanje prometa, zaobilaženje mrežnih politika ili tuneliranje oko segmentacije.

Pokretanje kontejnera u potpuno privilegovanom režimu u suštini znači "tretirajte ovo kao dio hosta".Dobija sve mogućnosti, može pristupiti host uređajima i često zaobilazi seccomp profile. Za mnoge lance napada, najteži korak je jednostavno pronaći jedan takav pogrešno konfiguriran kontejner, a zatim ga koristiti kao odskočnu dasku.

Moderni alati poput Falca počeli su pružati mogućnosti detekcije na nivou niti.Sada možete pregledati polja kao što su thread.cap_effective, thread.cap_permitted i thread.cap_inheritable za vrijeme izvođenja i aktiviraju upozorenja kad god proces s rizičnim mogućnostima izvrši sumnjive radnje.

Pogrešne konfiguracije: montiranja, utičnice i trikovi sa logovanjem

Iznenađujuće veliki udio izlaza iz kontejnera ne oslanja se na egzotične 0-dane, već na obične pogrešne konfiguracije.Kada operateri montiraju osjetljive putanje hosta u kontejnere ili otkriju interne Unix sockete, napadači često mogu proći kroz njih.

Opasni hostPath ili montiranja volumena su klasičan primjerAko kontejner dobije pristup za čitanje i pisanje direktorijima kao što su /etc, /proc, /sys or /var/run od domaćina, model izolacije se uglavnom urušava. Pisanje u /proc/sys ili sysfs može mijenjati parametre kernela; pristup konfiguracijskim datotekama hosta kao što su /etc/shadow može doći do curenja akreditivnih podataka.

Docker socket (/var/run/docker.sock) i drugi runtime socketi su još jedna bolna pogrešna konfiguracijaMontiranje ovoga unutar kontejnera daje onome ko kontroliše kontejner gotovo potpunu kontrolu nad Docker daemonom. Pomoću jednostavnog... curl --unix-socket pozivima, napadač može izlistati kontejnere, kreirati novi privilegovani kontejner koji montira korijen hosta i izaći iz tog pomoćnog kontejnera.

U Kubernetesu su također zloupotrebljavani Kubeletovo rukovanje logom i montiranje logova hosta.Ako pod ima hostov /var/log Ako je bind-mounted i napadač može manipulirati simboličkim vezama dnevnika i čitati dnevnike putem API-ja, možda će moći usmjeriti simboličku vezu dnevnika na proizvoljne datoteke hosta i prevariti Kubelet da vrati, recimo, /etc/shadow sadržaj.

Čak i naizgled jednostavno SUID ponašanje može igrati uloguU okruženjima gdje kontejner dijeli korisnički imenski prostor s hostom, postavljanje SUID bita na binarnu datoteku u dijeljenom direktoriju iznutra kontejnera kasnije može koristiti korisnik hosta s niskim privilegijama za izvršavanje tog programa s root privilegijama na hostu.

Tehnike bijega iz betonskih kontejnera viđene u divljini

Uvećavanje sa kategorija na specifične tehnike pomaže vam da prepoznate obrasce u telemetriji i izvještajima o prijetnjamaNekoliko porodica metoda su više puta demonstrirali istraživači i koristili u testovima penetracije ili stvarnim napadima.

Pomoćnici korisničkog načina rada i release_agent trik

Linux kernel otkriva funkciju, call_usermodehelper, za pokretanje programa korisničkog prostora s povećanim privilegijama kao odgovor na događaje u kernel prostoruPod pravim uslovima, datoteke koje kontroliše korisnik mogu uticati na to koji će se program izvršavati, pretvarajući legitimni mehanizam u vektor za bijeg.

C-grupe v1 release_agent je najpoznatiji primjer ovog obrascaKada cgrupa postane prazna i notify_on_release je omogućeno, kernel pokreće binarni fajl na koji ukazuje release_agent datoteku. Ako napadač unutar kontejnera može montirati i manipulirati cgroup datotečnim sistemom s dovoljnim privilegijama, može ukazati release_agent na proizvoljnoj izvršnoj datoteci na hostu.

Tipičan niz eksploatacijskih operacija otprilike izgleda ovako: kreiranje i montiranje cgroup direktorija, omogućavanje notify_on_releaseset release_agent do putanje zlonamjernog skripta u imenskom prostoru hosta, a zatim isprazni listu procesa cgrupe. Kernel uslužno pokreće napadačev skript s root privilegijama na hostu.

Detekcija zahtijeva i semantičko razumijevanje pomoćnih putanja korisničkog načina rada i kontekst o tome odakle promjene potičuRobustan pristup mapira sve call_usermodehelper poziva web-mjesta, identificira na koja mogu utjecati datoteke korisničkog načina rada, a zatim prati zapise u te datoteke kada potiču iz kontejnera, označavajući sumnjive izmjene.

Eskalacija privilegija na host putem SUID bitova

SUID tehnika nije "čisti" izlaz iz kontejnera jer pretpostavlja da napadač već ima pristup hostu., ali je često lančano povezan s pristupom kontejneru za prelazak s ograničenih korisnika hosta na root.

Trik se zasniva na zajedničkim direktorijima između hosta i kontejnera i zajedničkom korisničkom imenskom prostoru.Iz kontejnera koji se izvršava kao root, napadač smješta izvršnu datoteku u direktorij vidljiv s obje strane (na primjer, dijeljeni volumen) i postavlja SUID bit sa chmod u+s.

Kasnije, korisnik koji nije root na hostu izvršava tu binarnu datoteku i dobija root privilegije na hostu., jer se SUID bit interpretira u kontekstu hosta. Kontejner se koristi kao praktično mjesto za pripremu SUID sadržaja bez ograničenja koja mogu postojati za tog korisnika hosta.

Vidljivost zloupotrebe SUID-a fokusira se na tri momenta: kreiranje izvršne datoteke u dijeljenoj putanji, postavljanje SUID/SGID bitova iz kontejnera i izvršavanje te datoteke na hostu od strane ne-root računa. EDR i alati za sigurnost tokom izvođenja mogu povezati ove korake kako bi se podigla visokokvalitetna upozorenja.

Zloupotreba Runtime socketa: Docker i containerd

Kontejnerska okruženja se često oslanjaju na klijent/server arhitekturu, gdje CLI alati ili orkestratori komuniciraju s demonima putem Unix socketa.. Primjeri uključuju /var/run/docker.sock za Docker ili /run/containerd/containerd.sock za kontejnere.

Ako su ove socket datoteke montirane unutar kontejnera, taj kontejner može efektivno djelovati kao administratorski klijent.Napadač koji kompromituje kontejner može slati API zahtjeve direktno u runtime okruženje, navodeći kontejnere, pokrećući i zaustavljajući radna opterećenja ili kreirajući potpuno novi privilegovani kontejner s montiranjima hosta.

Korištenje generičkog alata kao što je curlTrivijalno je pristupiti Docker udaljenom API-ju preko Unix socketa.upit /containers/json nabrojati kontejnere, poslati na /containers/create s JSON definicijom za kreiranje privilegovanog pomoćnika, a zatim pozovite /containers/{id}/start da ga pokrene. Taj pomoćni kontejner može montirati korijenski datotečni sistem hosta i dati napadaču interaktivni pristup.

Branioci mogu ovo tražiti na više načinaPraćenje pristupa runtime Unix socketima iz kontejnerizovanih procesa, otkrivanje sumnjivih curl --unix-socket ili CLI invokacije za vrijeme izvođenja koje ciljaju te sockete i upozoravaju na neobične obrasce kreiranja kontejnera (npr. hostPath se montira na /, --privileged u specifikacijama Kubernetesa).

Trikovi specifični za Kubernetes: montiranje logova i izlazi iz podova

U Kubernetes-u, neki napadi ciljaju na ponašanje Kubeleta i Kubernetes apstrakcije, a ne na sirove Docker koncepte.Podovi koji montiraju direktorije hosta kao što su /var/log or /var/lib/docker posebno su zanimljivi protivnicima.

Jedna demonstrirana metoda zloupotrebljava način na koji Kubelet rješava simboličke veze prilikom vraćanja logova.Svaki pod dobija log datoteku pod /var/log koji simbolički povezuje na direktorij kontejnera ispod /var/lib/docker/containersAko napadač može kreirati ili mijenjati simboličke veze u /var/log putem hostPath montiranja, mogu preusmjeriti "log" da ukazuje na proizvoljnu datoteku (na primjer, /etc/shadow).

Kada korisnički ili servisni račun s dozvolama za čitanje dnevnika pozove kubectl logs ili odgovarajući API, kubelet prati simboličku vezu i vraća sadržaj tog ciljaUz malo kreativnosti, napadač može otkriti velike dijelove host datotečnog sistema putem niza takvih simbolički povezanih "logova".

Detekcija ovdje kombinuje mrežne i datotečne sistemske sočivaprati HTTP zahtjeve za čitanje zapisnika Kubernetes-a u potrazi za abnormalnim obrascima putanja i istovremeno prati kreiranje ili modifikaciju simboličkih veza u hostu /var/log koji potiču iz kontejnerizovanih procesa.

Osjetljivo montiranje hosta i direktna krađa podataka

Ponekad se escape sastoji isključivo od čitanja ili modifikovanja podataka hosta iznutra kontejnera bez ikakvog izvršavanja koda na nivou hosta.Pogrešno konfigurirana montiranja koja otkrivaju osjetljive direktorije dovoljna su da postignu ozbiljan utjecaj.

Na primjer, kontejner može imati nosač poput /host_etc pokazujući na domaćina /etc imenikNapadač koji naiđe na ovaj put može jednostavno otvoriti /host_etc/passwd or /host_etc/shadow i oni efektivno čitaju datoteke za autentifikaciju hosta iz kontejnera.

Otkrivanje zloupotrebe takvih montiranja je teško jer mnogi obrasci pristupa izgledaju slično normalnim operacijama s datotekama.Ne možeš samo gledati /etc/shadow unutar kontejnera, jer se to obično odnosi na datoteku samog kontejnera, a ne na datoteku hosta. Potreban vam je sloj mapiranja koji pretvara "putanju kontejnera" u "putanju temeljnog hosta" za svako montiranje.

Napredni EDR i CNAPP alati rješavaju ovaj problem razrješavanjem tačaka montiranja i praćenjem pristupa na osnovu putanje na strani hosta.Na taj način, svako čitanje ili pisanje koje na kraju dotakne datoteku osjetljivu na hosta – čak i putem naizgled bezopasne putanje unutar kontejnera – može biti označeno u stvarnom vremenu.

Detekcija pokušaja izlaza iz kontejnera tokom izvođenja

Preventivno kaljenje je neophodno, ali vam je također potreban dobar pogled na ono što se događa dok kontejneri rade.Moderni napadi često povezuju više koraka u lanac, a robusno praćenje tokom izvođenja napada daje vam priliku da uhvatite lanac prije nego što stigne do hosta.

Najsavremenija detekcija obično kombinuje telemetriju niskog nivoa (npr. tragove sistemskih poziva zasnovane na eBPF-u) sa analitikom ponašanja i kontekstom oblaka.Sirovi signali dolaze iz sistemskih poziva, operacija s datotekama, stabala procesa i aktivnosti socketa; analitički sloj ih povezuje s identitetima, izloženošću mreže i resursima u oblaku kako bi odvojio benigne administratorske akcije od stvarnih pokušaja bijega.

Ključni indikatori na nivou sistemskih poziva

Određeni sistemski pozivi su snažno povezani s aktivnostima koje probijaju granice i trebali bi biti podvrgnuti dodatnoj kontroli kada ih pozovu kontejneri:

• mount, umount, pivot_root – manipulisanje montiranjima datotečnog sistema ili pivotiranje korijenskih direktorijuma, često se koristi za spajanje putanja hosta u kontejner ili izbjegavanje chroot-ova.

• setns, unshare – pridruživanje ili kreiranje novih imenskih prostora, što je ključni korak u tehnikama koje prelaze u početni imenski prostor hosta.

• ptrace – otklanjanje grešaka ili ubrizgavanje u druge procese; sumnjivo pri prelasku granica kontejnera ili ciljanju sistemskih demona.

• capset – modifikacija mogućnosti tokom izvršavanja, potencijalno korištena za dobijanje novih moćnih zastavica tokom izvršavanja.

• init_module, finit_module – učitavanje kernel modula iz kontejnera je visokorizično ponašanje koje je rijetko potrebno u legitimnim radnim opterećenjima.

Mehanizmi za pravila poput Falca vam omogućavaju da izrazite logiku detekcije preko ovih sistemskih poziva na način koji je svjestan kontejnera.Na primjer, možete upozoriti svaki put kada kontejnerizirani proces sa CAP_SYS_ADMIN otvara datoteku pod nazivom release_agent za pisanje, što je izuzetno jak pokazatelj pokušaja izlaza zasnovanog na pomoćniku u korisničkom načinu rada.

Sumnjivi obrasci pristupa datotekama

Nadzor integriteta datoteka i pristupa nadopunjuje sistemske pozive tako što tačno prikazuje koje putanje napadač dodiruje.Kada se posmatra kroz prizmu mapiranja kontejnera/domaćina, ovo postaje moćan detektor bijega.

• Piše /proc/sys or /sys iz kontejnerskog signala koji pokušava promijeniti parametre kernela ili postavke uređaja.

• Pristup soketima za izvršavanje kontejnera kao što su /var/run/docker.sock or /run/containerd/containerd.sock je crvena zastavica kada dolazi iz kontejnera opće primjene.

• Promjene u /etc/passwd, /etc/shadow or /etc/sudoers na hostu putem putanja vidljivih kontejneru izgledaju kao koraci za eskalaciju privilegija i perzistenciju.

• Čita iz /proc/*/environ or /proc/*/cmdline preko imenskih prostora može ukazivati ​​na nabrajanje procesa i prikupljanje akreditiva izvan vlastitog stabla procesa kontejnera.

Najpouzdanija upozorenja kombinuju više faktora – putanju, sistemski poziv, mogućnosti i metapodatke kontejnera.. Na primjer, a mount sistemski poziv koji potiče iz kontejnera aplikacije koji nije administrator i koji je izložen internetu sa CAP_SYS_ADMIN i ciljanje /proc/sys je daleko alarmantnije od iste operacije iz poznatog privilegovanog posla održavanja.

Signali na nivou procesa i ponašanja

Pored neobrađenih sistemskih poziva i događaja datoteka, ponašanje procesa višeg nivoa slika priču o tome šta se dešavaOdređene aktivnosti su izuzetno neuobičajene u normalnim mikroservisima, ali uobičajene u fazama nakon eksploatacije.

• Interaktivne ljuske stvorene iz neinteraktivnih kontejnera (npr. /bin/bash pojavljuju se unutar procesa web servera) sugeriraju praktičnu aktivnost na tastaturi.

• Korištenje alata za eskalaciju privilegija kao što su sudo, su or newgrp unutar kontejnera, posebno oni koji nisu namijenjeni za interaktivnu upotrebu, vrlo sumnjivi.

• Skeniranje mreže, alati za lateralno kretanje i neobične odlazne veze iz kontejnera koji bi trebali komunicirati samo s malim skupom servisa ukazuju na pokušaje izviđanja ili širenja.

• Potpisi kriptorudara, neočekivani dugotrajni procesi vezani za CPU ili skokovi korištenja GPU-a može otkriti da je napadač već koristio svoj pristup na nivou hosta za monetizaciju resursa.

Ovdje se ističu EDR i CNAPP platforme koje održavaju „lanac uzročnosti“ (stablo procesa s porijeklom i okruženjem).Omogućavaju analitičarima da prate sumnjive operacije do izvorne slike kontejnera, Kubernetes opterećenja, cloud računa ili CI/CD cjevovoda, čineći analizu uzroka i dugoročna rješenja efikasnijim.

Sprečavanje izlaska iz kontejnera: dubinska odbrana

Nijedna pojedinačna kontrola ne može garantovati da se nikada nećete suočiti s pokušajem bijega iz kontejnera, tako da vam je potrebna slojevita zaštita od koda do oblaka.To uključuje higijenu slike, najmanje privilegije, ojačane konfiguracije, mrežne kontrole i snažnu zaštitu tokom izvođenja.

Pokreni kontejnere s najmanjim privilegijama

Počnite tako što ćete nemilosrdno uklanjati nepotrebne privilegije iz kontejnera.Izbjegavajte privilegovani način rada osim u vrlo rijetkim, strogo kontrolisanim slučajevima i preferirajte kontejnere bez roota ili korisničke imenske prostore tako da se "root inside" mapira na neprivilegovanog korisnika na hostu.

Na Kubernetes-u, pametno koristite postavke securityContext-a kao runAsNonRoot, runAsUser, allowPrivilegeEscalation: false i readOnlyRootFilesystem: trueOva ograničenja ograničavaju ono što napadač može učiniti čak i ako potpuno ugroze izvršavanje aplikacije.

Mogućnosti bi trebale biti usko ograničene: podrazumevano odbacite sve i dodajte samo minimalni skup potreban za radno opterećenje. Ako kontejneru zaista treba CAP_SYS_ADMIN or CAP_NET_ADMIN, tretirajte ga kao visokorizičnu imovinu i okružite ga dodatnim nadzorom i mrežnom izolacijom.

Pravila detekcije koja koriste Falco-ova polja sposobnosti mogu djelovati kao sigurnosna mreža za pogrešne konfiguracije koje promaknuNa primjer, pravilo se može aktivirati kad god se kontejnerizirana nit sa CAP_SYS_ADMIN i CAP_DAC_OVERRIDE piše u datoteku pod nazivom release_agent, hvatajući veliku klasu iskorištavanja pri bijegu uz vrlo nisku razinu šuma.

Osigurajte lanac snabdijevanja kontejnerima

Većina kompromitovanja počinje prije izvođenja programa, u obliku ranjivih ili izmijenjenih slikaRobusna sigurnost slika otežava napadačima da uopće dobiju pouzdano uporište.

Koristite ojačane, minimalne osnovne slike iz pouzdanih registara i redovno ih ažurirajte.Manje slike s manje paketa znače manje biblioteka koje bi mogle sadržavati CVE-ove koji se mogu iskoristiti, a dobavljači poput Wiza ili održavatelja distribucija sada pružaju baze "bez distribucije" samo s onim što je strogo potrebno.

Integrirajte skeniranje ranjivosti i softverske popise materijala (SBOM) u CI/CDSvaku verziju treba skenirati prije slanja u registar, a slike s neispravljenim greškama visokog ili kritičnog stepena ozbiljnosti relevantnim za njihovu izloženost i privilegije treba blokirati za implementaciju.

Politike pouzdanosti slika zatvaraju krugKriptografski potpišite slike, konfigurirajte kontrolere pristupa da odbace nepotpisane ili nepouzdane slike i održavajte uvid u to koje se slike zapravo izvršavaju u klasterima tokom vremena kako biste mogli brzo ukloniti rizične artefakte.

Konačno, dajte prioritet sanaciji na osnovu stvarnog rizika, a ne neobrađenih podataka o CVEKritična ranjivost u neaktivnom, neumreženom batch zadatku koji se izvršava bez dodatnih mogućnosti manje je hitna od "srednje" greške u privilegovanom podu koji je povezan s internetom i obrađuje osjetljive podatke.

Segmentacija mreže i zaštita za vrijeme izvođenja

Čak i ako napadač završi u jednom kontejneru, pametni dizajn mreže može ga spriječiti da to pretvori u potpuno kršenje klastera.Granularne mrežne politike, zaštitni zidovi i servisne mreže pomažu u ograničavanju lateralnog kretanja.

Implementirajte mrežne politike u stilu dozvoljene liste u Kubernetes-u tako da pod-ovi mogu komunicirati samo sa servisima koji su im zaista potrebni. Ovo ograničava mogućnost napadača da skenira klaster ili poziva interne API-je za upravljanje poput Docker socketa ili Kubernetes API servera.

Sistemi zaštite tokom rada dodaju kočnice u realnom vremenuKada otkriju ponašanje koje je u skladu sa izlazom iz kontejnera (na primjer, sumnjivo nsenter upotreba, hostPath se montira na / ili neovlašteno korištenje kontejnerskih soketa), mogu blokirati ili ubiti procese, izolirati kontejnere ili automatski otvoriti incidente s potpunom forenzičkom tragom.

Platforme poput Wiz CNAPP-a kombiniraju ove detekcije tokom izvođenja s kontekstom oblaka i sigurnosnim grafom.Mapiranjem odnosa između kontejnera, hostova, identiteta i skladišta podataka, oni pokazuju ne samo da se dešava bijeg, već i koja se osjetljiva sredstva nalaze u radijusu eksplozije kako bi timovi mogli odrediti prioritete odgovora.

Kontinuirano praćenje i spremnost za incidente

Kontejneri su kratkog vijeka trajanja, što otežava klasičnu forenziku i analizu logova.Ako ovo ne planirate unaprijed, dokazi koji su vam potrebni za razumijevanje bijega mogu nestati kada se grupa premjesti.

Uspostavite centralizirano evidentiranje i prikupljanje metrika za okruženja za izvršavanje kontejnera, orkestratore i hostoveAlati poput ELK-a, Prometheusa i cloud-native usluga evidentiranja osiguravaju da se aktivnost procesa, sigurnosni događaji i promjene konfiguracije bilježe čak i za kratkotrajna radna opterećenja.

Kreirajte priručnike posebno za scenarije bijega iz kontejneraOvo bi trebalo definirati kako brzo ograničiti čvorove, napraviti snimke diskova, prikupiti metapodatke kontejnera i koordinirati s pružateljima usluga u oblaku ili timovima za odgovor na incidente kada posumnjate na bijeg ili kompromitiranje na razini hosta.

Prodavci poput Palo Alto Networksa (Cortex XDR, Prisma Cloud) i drugih su izgradili opsežan sadržaj za detekciju oko tehnika opisanih ovdje., od zloupotrebe pomoćnika u korisničkom načinu rada do iskorištavanja socketa tokom izvođenja i osjetljivog pristupa montiranju, dajući braniteljima podnošljiva, visokokontekstualna upozorenja umjesto generičke buke „sumnjive aktivnosti“.

Spajanje svih ovih elemenata – čvrstih osnova izolacije Linuxa, strogih privilegija, ojačanih slika, mrežnih kontrola i duboke vidljivosti tokom izvođenja – pretvara bijeg kontejnera od egzistencijalne prijetnje u upravljiv rizik koji vaš tim može rano otkriti, efikasno obuzdati i učiti iz njega kako bi dodatno ojačao vašu sigurnosnu poziciju u oblaku tokom vremena..