Konteinerite põgenemisrünnakute avastamine ja ennetamine

Esileht » Python » Konteinerite põgenemisrünnakute avastamine ja ennetamine

Konteinerite põgenemisest on saanud üks neist teemadest, mis pilve- ja platvormimeeskondi öösel ärkvel hoiab sest üks valesti konfigureeritud pod või aegunud kernel võib muuta isoleeritud töökoormuse otseühenduseks alusarvutiga. Sellisel juhul ei ole ründaja enam ühte konteinerisse suletud: ta saab liikuda sõlmede vahel, pääseda juurde teiste rentnike andmetele või isegi kogu klastri üle võtta.

Konteineripõgenemiste toimimise mõistmine – alates Linuxi sisemusest kuni käitusaja signaalide ja EDR-tuvastusteni – on erinevus hirmutava moesõna ja riski vahel, mida saate tegelikult hallata.Selles juhendis vaatame, mis on konteiner operatsioonisüsteemi tasandil, kuidas põgenemised praktikas toimuvad, millised on peamised looduses esinevad rünnakutehnikad ning kuidas neid tuvastada ja ennetada võimete jälgimise, Falco reeglite, CNAPP platvormide ning hea vanaaegse karastamise ja segmenteerimise abil.

Mis on konteineripõgenemine ja miks see on oluline?

Konteineri põgenemine toimub siis, kui ründajal õnnestub murda loogiline isolatsioon, mis peaks konteineri hostist ja teistest konteineritest eraldama.Selle asemel, et olla piiratud oma nimeruumide ja cgroupidega, saab ründaja võimaluse käivitada koodi hosti tasemel kontekstis – sageli kõrgete või täielike õigustega.

Konteinerid erinevad virtuaalmasinatest olulisel moel: neil kõigil on sama hostkernel.Sellised tehnoloogiad nagu Linuxi nimeruumid (PID, mount, network jne), cgroups ja võimalused jagavad selle kerneli paljudeks isoleeritud vaadeteks, kuid kui haavatavus või vale konfiguratsioon laseb ründajal neid piire ületada, võib rünnak levida palju väljapoole algselt häkitud konteinerit.

Ärilisest vaatenurgast on eduka põgenemise ohtlikuks just plahvatusraadius.Üksainus haavatav internetiühendusega konteiner võib kaasa tuua tundlike andmete varguse, krüptokaevandajate ulatusliku kasutuselevõtu, kriitiliste teenuste katkemise ja tõsised vastavusprobleemid mitme üürnikuga või reguleeritud keskkondades.

Vastased kasutavad konteineripõgenemist tavaliselt ühe sammuna laiemas rünnakuahelas.: nad satuvad madala privileegiga konteinerisse (rakenduse vigade, nõrkade volituste või tarneahela probleemi tõttu), eskaleerivad konteineri sees privileege ja seejärel murravad hostile välja, et külgsuunas liikuda, volitusi koguda või luua püsiv püsivus, näiteks kerneli tasemel juurkomplekt.

Kuidas konteinerid kapoti all töötavad

Põgenemistehnikate tõeliseks mõistmiseks on vaja kõigepealt mentaalset mudelit sellest, kuidas Linuxi konteinerid protsesse isoleerivad.Konteiner on sisuliselt protsessipuu, mille atribuute (nimeruumid, võimalused, cgroupid, seccomp profiil jne) on konteineri käituskeskkonna, näiteks containerd, Docker või CRI-O ja laiemalt, poolt kohandatud. konteinerdamistehnoloogiad.

Konteineri käivitamisel loob käituskeskkond protsessi ja muudab selle oma väikese universumi „init” protsessiks.: see saab oma PID-nimeruumi, ühendusnimeruumi, võrgu nimeruumi ja palju muud, mida kõik kernel jõustab. Seejärel käivitab see protsess mis tahes käsu, mis on kuvandi konfiguratsioonis määratletud (nt Dockerfile'i ENTRYPOINT/CMD).

Võimalused on Linuxi viis jagada traditsiooniline kõikvõimas juurõigus väiksemateks õigusteks.Selle asemel, et öelda „juur saab kõike teha”, defineerib kernel lipud, näiteks CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG ja kümneid teisi. Igal lõimel on teatud võimete komplektid (lubatud, efektiivsed, päritavad), mis määravad, milliseid privilegeeritud toiminguid see võib teha.

Nimeruumid vastavad küsimusele „kus saab protsess oma volitusi rakendada?“.Näiteks PID-nimeruum muudab konteineri sees oleva PID 1-e hosti PID 1-ga seotuks ja mount-nimeruum annab konteinerile oma failisüsteemi vaate. Isegi kui protsessil on selline võimalus nagu CAP_KILLpiiratud PID-nimeruumis saab see tappa ainult selles nimeruumis eksisteerivaid protsesse.

C-rühmad täiendavad seda isolatsiooni, kontrollides, kui palju ressursse konteiner põletada saab – Protsessori jagamine, mälupiirangud, sisend/väljund ja palju muud. Koos seccomp-filtrite (syscall lubamis-/keelamisloendid) ja LSM-idega nagu AppArmor või SELinux saate kihilise isolatsiooni, millest tänapäevane konteineri turvalisus sõltub.

Miks ründajad üritavad konteineritest põgeneda

Kui vastane konteineri ohtu satub, avastavad nad kiiresti, et elu sees on üsna piiratud.piiratud failisüsteem, piiratud võrguvaade, võib-olla mitte-root ja tavaliselt puudub otsene juurdepääs teistele töökoormustele.

Peremehe juurde põgenemine eemaldab need piirdedKui nad saavad hosti algsetes nimeruumides käske käivitada, näevad nad kõiki protsesse, saavad paigaldada mis tahes failisüsteemi ja koguda volitusi sellistest kohtadest nagu /root/.ssh või pilve metaandmete agentide abil ja suunata need teistesse konteineritesse või virtuaalmasinatesse.

Põgenemised võimaldavad ka raskesti hävitatavat püsivustSelle asemel, et tagaukse paigutada ainult ajutisele konteinerile, võib ründaja installida kerneli mooduli, muuta konteineri käitusaegu (nt runc või containerd) või juurutada deemonkomplekti, mis tagab tagaukse abil podi töötamise igas Kubernetes klastri sõlmes.

Avastamise seisukohast kattuvad paljud konteineri põgenemise ilmingud klassikalise privileegide eskaleerimise ja külgliikumise käitumisega. – kerneli mooduli laadimine, kahtlane mount/unshare/setns kasutamine, otsene juurdepääs käitusaja soklitele, SUID-i ärakasutamine ja ebanormaalsed failidele juurdepääsud konteinerites paljastatud hostiteedele.

Konteineritest pääsemise peamised teed: haavatavused, privileegid ja valekonfiguratsioonid

Enamik reaalsetest konteineritest põgenemise stsenaariumidest jaguneb kolme laia kategooriassehaavatavuste (kerneli või käitusaja) ärakasutamine, liiga privilegeeritud konteinerite kuritarvitamine või valekonfiguratsioonide (nt ohtlike ühenduste ja paljastatud soklite) ärakasutamine.

Kerneli ja konteineri käitusaja haavatavused

Kuna iga konteiner jagab hostkerneli, võib üks kerneli viga pakkuda otsest pääseteedKuulsad probleemid nagu Dirty COW (CVE-2016-5195) ja Dirty Pipe (CVE-2022-0847) on lokaalsed õiguste eskaleerimise vead, mis võimaldavad ründajatel kirjutada kirjutuskaitstud kaardistustesse ja suvalistele failidele, võimaldades neil sageli konteineri seest hosti binaarfaile või konfiguratsiooni muuta.

Üks eriti kriitiline konteinerispetsiifiline viga oli CVE-2019-5736 runc-isSee võimaldas konteineris oleval protsessil konteineri käivitamisel või käivitamisel hostil runc-binaarfaili üle kirjutada, andes ründajale hosti tasemel koodi käivitamise võimaluse. Kuna runc on Dockeri, Kubernetesi ja teiste platvormide alus, oli mõju laiaulatuslik.

Hiljutisemad avalikustused nagu „Leaky Vessels” (nt CVE-2024-21626) näitasid, et ka ehitussüsteemid ja idufirmade teed on viljakas pinnasBuildKiti või runci initsialiseerimisloogika haavatavused võimaldavad ründajatel pääseda välja juba pildi loomise või konteineri käivitamise ajal, enne kui muud kaitsemeetmed saavad täielikult rakenduda.

Konteineri käitusaja deemonitel, näiteks containerd, Docker Engine või CRI-O, on olnud oma osa vigu.Näiteks CVE-2022-23648 containerd'i CRI pluginas lubas vastastel, kes said luua konteinereid, ühendada tundlikke hostiradasid (nt /root/.ssh) konteinerisse ja loevad andmeid, mida nad kunagi nägema ei peaks, pakkudes seega astmelauda täieliku pääsetee suunas.

Märkimisväärsed konteineripõgenemise CVE-d ja kuidas neid leevendada

• CVE‑2019‑5736 (runc): lubatud hosti runc binaarfaili konteinerist ümber kirjutada, mis mõjutab Dockerit, Kubernetesit ja teisi RunC-põhiseid pakette. Tugevdamise meetmete hulka kuuluvad agressiivne paranduste tegemine, piltide skannimine ärakasutamise tööriistade leidmiseks ja RunC binaarkoodide modifikatsioonide jälgimine käitusajal.

• CVE‑2016‑5195 (Räpane lehm): kopeerimisel-kirjutamisel võidujooksutingimus, mis võimaldab privilegeerimata protsessidel saada kirjutamisõiguse ainult lugemiseks mõeldud kaardistusteleKonteineri seest saab seda kuritarvitada hostfailide muutmiseks, kui need on ühenduste kaudu avalikustatud.

• CVE‑2022‑0847 (Määrdunud toru): veel üks kerneli viga, mis võimaldab failidesse, sealhulgas konteineritesse kirjutuskaitstud failidesse, volitamata kirjutamistSee ei anna automaatselt pääsepääsu, kuid seob end kenasti privilegeeritud ühenduste või käitusaja valekonfiguratsioonidega.

• CVE‑2024‑21626 ja sellega seotud „lekkivate anumate” probleemid: BuildKiti ja Runci vead, mis paljastasid hosti ressursse pildi loomise või konteineri käivitamise ajal, mis tõestab, et ehitustorustik ise võib olla osa rünnakupinnast.

Kogu selle probleemiklassi leevendavad meetmed keskenduvad plaastri hügieenile ja arhitektuurilistele valikutele.Hoidke host-kernelid paigatud, kasutage rünnakupinna vähendamiseks minimaalseid või distributsioonita baaskujutisi, eelistage tundlike töökoormuste jaoks liivakasti või virtuaalmasina toega käituskeskkondi ning jälgige pidevalt kahtlaseid süsteemikõnesid ja failikirjutamisi, mis näevad välja nagu kerneli rünnakukatsed.

Liigsed võimalused ja privilegeeritud konteinerid

Juurte jõu vähendamiseks leiutati küll võimed, aga praktikas pannakse "väikesed tükid" sageli uuesti kokku.Arendajad, kellele avaldatakse survet „lihtsalt asjad tööle panna“, annavad sageli loa CAP_SYS_ADMIN või lihtsalt käivitage konteinereid järgmiselt --privileged, taastades tõhusalt konteineris oleva juuretaimelise jõu.

CAP_SYS_ADMIN on kurikuulsalt ülevõimas: see võimaldab failisüsteemide paigaldamist, nimeruumide loomist või ühendamist (unshare, setns), cgroupide kohandamine ja palju muud. Õigete ühenduste ja nimeruumide kombinatsiooni abil saab selle võimekusega ründaja pöörduda hosti algse nimeruumi poole ja saavutada globaalse nähtavuse.

CAP_NET_ADMIN on võrgustiku vaatenurgast samamoodi laiSeda saab kasutada liideste ümberkonfigureerimiseks, iptables'i reeglite manipuleerimiseks ja valikulise režiimi lubamiseks. Päästeahelas võidakse seda kuritarvitada liikluse nuhkimiseks, võrgupoliitikate möödahiilimiseks või segmenteerimisest möödahiilimiseks.

Konteineri käitamine täisprivilegeeritud režiimis tähendab põhimõtteliselt "käsitle seda hosti osana".See saab kõik võimalused, pääseb ligi hostseadmetele ja möödub sageli turvakontrolli profiilidest. Paljude rünnakukettide puhul on kõige raskem samm lihtsalt leida üks selline valesti konfigureeritud konteiner ja seejärel kasutada seda stardiplatvormina.

Kaasaegsed tööriistad, näiteks Falco, on hakanud pakkuma tuvastamiseks võimalusi niidi tasandil.Nüüd saate kontrollida selliseid välju nagu thread.cap_effective, thread.cap_permitted ja thread.cap_inheritable käitusajal ja käivitada hoiatusi iga kord, kui riskantsete võimalustega protsess teeb kahtlaseid toiminguid.

Valed konfiguratsioonid: kinnitused, pistikupesad ja logi nipid

Üllatavalt suur osa konteineripõgenemistest ei põhine eksootilistel 0-päevadel, vaid lihtsalt valedel konfiguratsioonidel.Kui operaatorid ühendavad konteineritesse tundlikke hostiradasid või paljastavad sisemisi Unixi sokleid, saavad ründajad sageli otse läbi jalutada.

Klassikaline näide on ohtlik hostPath või mahuühendusedKui konteiner saab lugemis- ja kirjutamisõiguse sellistele kataloogidele nagu /etc, /proc, /sys or /var/run hostist, siis isolatsioonimudel suures osas kokku variseb. Kirjutamine /proc/sys või sysfs saavad muuta kerneli parameetreid; juurdepääs hosti konfiguratsioonifailidele, näiteks /etc/shadow võivad volitused lekkida.

Dockeri sokkel (/var/run/docker.sock) ja muud käitusaja soklid on veel üks valulik valekonfiguratsioonSelle konteinerisse paigutamine annab konteinerit haldavale isikule peaaegu täieliku kontrolli Dockeri deemoni üle. Lihtsate viiside abil curl --unix-socket kõnede abil saab ründaja loetleda konteinereid, luua uue privilegeeritud konteineri, mis ühendab hosti juurserveri, ja sellest abikonteinerist põgeneda.

Kuberneteses on kuritarvitatud ka kubeleti logide käitlemist ja hosti logide ühendamist.Kui podil on hosti oma /var/log bind-mounted ja ründaja saab manipuleerida logide sümboolsete linkidega ning lugeda logisid API kaudu, võivad nad olla võimelised suunama logi sümboolse lingi suvalistele hostfailidele ja petma Kubeletit tagastama näiteks /etc/shadow sisu.

Isegi pealtnäha lihtne SUID-käitumine võib mängida rolliKeskkondades, kus konteiner jagab kasutajanimeruumi hostiga, saab madalate õigustega hostikasutaja konteineri sees jagatud kataloogis asuvale binaarfailile SUID-biti määramist hiljem kasutada selle programmi käivitamiseks hostis juurõigustega.

Looduses nähtud betoonkonteinerite põgenemistehnikad

Kategooriatelt konkreetsetele tehnikatele suumimine aitab teil telemeetria- ja ohuaruannetes mustreid ära tundaTeadlased on korduvalt demonstreerinud ja kasutanud mitmeid meetodiperekondi penetratsioonitestides või reaalsetes rünnakutes.

Kasutajarežiimi abilised ja release_agent trikk

Linuxi kernel avaldab funktsiooni, call_usermodehelper, et käivitada kasutajakeskkonnas programme kõrgendatud õigustega vastuseks kerneli ruumi sündmusteleÕigete tingimuste korral saavad kasutaja kontrollitavad failid mõjutada, millist programmi käivitatakse, muutes legitiimse mehhanismi põgenemisvektoriks.

Cgroups v1-d release_agent on selle mustri tuntuim näideKui c-rühm tühjeneb ja notify_on_release kui see on lubatud, käivitab kernel binaarfaili, millele see osutab release_agent fail. Kui konteineri sees olev ründaja saab piisavate õigustega cgroup-failisüsteemi ühendada ja seda manipuleerida, saab ta osutada release_agent suvalise käivitatava faili juures hostil.

Tüüpiline ärakasutamise järjekord näeb välja umbes selline: loo ja paigalda cgroupi kataloog, luba notify_on_release, seatud release_agent pahatahtliku skripti teele hosti nimeruumis ja seejärel tühjenda cgroupi protsesside loend. Kernel käivitab ründaja skripti hostil vastutulelikult root-kasutaja õigustega.

Tuvastamine nõuab nii kasutajarežiimi abiteede semantilist mõistmist kui ka muudatuste päritolu konteksti.Tugev lähenemisviis kaardistab kõik call_usermodehelper kõnesaite, tuvastab need, mida kasutajarežiimi failid võivad mõjutada, ja seejärel jälgib nendesse failidesse kirjutamist, kui need pärinevad konteineritest, märkides ära kahtlased muudatused.

Privileegide eskaleerimine hostile SUID-bittide kaudu

SUID-tehnika ei ole „puhas” konteineripõgenemine, kuna see eeldab, et ründajal on juba mingisugune hosti ligipääs., kuid see on sageli aheldatud konteineri juurdepääsuga, et piiratud hostkasutajatelt root'i juurde hüpata.

Nipp seisneb hosti ja konteineri jagatud kataloogides ning jagatud kasutajanimeruumisJuurkasutajana töötava konteineri seest asetab ründaja käivitatava faili mõlemale poolele nähtavasse kataloogi (näiteks jagatud köitele) ja määrab SUID-biti väärtuseks chmod u+s.

Hiljem käivitab hosti mitte-juurkasutaja selle binaarfaili ja saab hostis juurõigused., kuna SUID-bitti tõlgendatakse hosti kontekstis. Konteinerit kasutatakse mugava kohana SUID-i kasuliku koormuse ettevalmistamiseks ilma piiranguteta, mis võivad sellele hosti kasutajale kehtida.

Nähtavus SUID-i kuritarvitamises keskendub kolmele hetkele: käivitatava faili loomine jagatud teele, SUID/SGID bittide määramine konteinerist ja selle faili käivitamine hostis mitte-juurkasutaja konto poolt. EDR ja käitusaja turbetööriistad saavad neid samme omavahel seostada, et käivitada kõrge täpsusega hoiatusi.

Käitusaja sokli kuritarvitamine: Docker ja konteinerd

Konteinerkeskkonnad tuginevad sageli kliendi/serveri arhitektuurile, kus CLI-tööriistad või orkestraatorid suhtlevad deemonitega Unixi soklite kaudu.. Näited hõlmavad järgmist /var/run/docker.sock Dockeri või /run/containerd/containerd.sock konteinerdatud.

Kui need soklifailid on konteinerisse paigaldatud, saab see konteiner toimida tõhusalt administraatori kliendina.Ründaja, kes konteineri ohtu seob, saab saata API-päringuid otse käituskeskkonnale, loetledes konteinereid, käivitades ja peatades töökoormusi või luues hostiühendustega täiesti uue privilegeeritud konteineri.

Kasutades üldist tööriista, näiteks curl, on Unixi sokli kaudu Dockeri kaug-API-le juurdepääs lihtnepäring /containers/json konteinerite loetlemiseks, postitamiseks /containers/create JSON-definitsiooniga privilegeeritud abistaja loomiseks ja seejärel kutsu /containers/{id}/start selle käivitamiseks. See abikonteiner saab paigaldada hosti juurfailisüsteemi ja anda ründajale interaktiivse juurdepääsu.

Kaitsjad saavad seda mitmel viisil otsida.: konteinerdatud protsesside juurdepääsu jälgimine Unixi käitusaja soklitele, kahtlaste protsesside tuvastamine curl --unix-socket või nendele soklitele suunatud käitusaja CLI-kutsed ja ebatavaliste konteineri loomise mustrite teavitamine (nt hostPath ühendatakse /, --privileged Kubernetes'i spetsifikatsioonides).

Kubernetes-spetsiifilised nipid: logide ühendamine ja pod-pääsud

Kuberneteses on mõned rünnakud suunatud pigem kubeleti käitumisele ja Kubernetesi abstraktsioonidele kui toores Dockeri kontseptsioonidele.Pod'id, mis ühendavad hostikatalooge, näiteks /var/log or /var/lib/docker on vastaste jaoks eriti huvitavad.

Üks demonstreeritud meetod kuritarvitab seda, kuidas Kubelet lahendab sümbolilinke logide tagastamiselIga pod saab logifaili alla. /var/log mis viitab konteineri kataloogile allolevas sümboolses lingis /var/lib/docker/containersKui ründaja saab luua või muuta sümbolilinke /var/log hostPathi ühenduse kaudu saavad nad suunata "logi" suvalisele failile osutama (näiteks /etc/shadow).

Kui logi lugemise õigustega kasutaja- või teenusekonto kutsub kubectl logs või vastava API puhul järgneb kubelet sümbolile ja tagastab selle sihtmärgi sisuMõningase loovuse abil saab ründaja selliste sümbollingitud „logide” seeria kaudu paljastada suuri osi hosti failisüsteemist.

Siinsed tuvastused ühendavad võrgu- ja failisüsteemi läätsesid: jälgib Kubernetes'i logide lugemise HTTP-päringuid ebanormaalsete teemustrite suhtes ja samal ajal jälgib hosti sümlinkide loomist või muutmist /var/log mis pärinevad konteinerdatud protsessidest.

Tundlike hostiühenduste ja otseste andmete vargus

Mõnikord seisneb põgenemiskäsk ainult hostiandmete lugemises või muutmises konteineri seest ilma hosti tasemel koodi käivitamata.Valesti konfigureeritud ühendused, mis paljastavad tundlikke katalooge, on piisavad tõsise mõju saavutamiseks.

Näiteks võib konteineril olla selline alus nagu /host_etc osutades peremehe poole /etc kataloogRündaja, kes sellele teele komistab, saab lihtsalt avada /host_etc/passwd or /host_etc/shadow ja nad loevad sisuliselt konteineri seest hosti autentimisfaile.

Selliste ühenduste väärkasutamise tuvastamine on keeruline, kuna paljud juurdepääsumustrid näevad välja sarnased tavaliste failitoimingutega.Sa ei saa lihtsalt vaadata /etc/shadow konteinerite sees, sest see viitab tavaliselt konteineri enda failile, mitte hosti omale. Teil on vaja kaardistuskihti, mis teisendab iga paigalduse jaoks „konteineri tee“ „alus hosti teeks“.

Täiustatud EDR- ja CNAPP-tööriistad lahendavad selle probleemi, lahendades ühenduspunkte ja jälgides juurdepääsu hostipoolse tee põhjal.Nii saab iga lugemis- või kirjutamistoimingu, mis lõpuks puudutab hostitundlikku faili – isegi konteineri sees oleva süütu välimusega tee kaudu – reaalajas märgistada.

Konteineri põgenemiskatsete tuvastamine käitusajal

Ennetav karastamine on oluline, aga konteinerite töötamise ajal on vaja ka head silma peal hoida.Kaasaegsed rünnakud aheldavad sageli mitut sammu ja tugev käitusaegne jälgimine annab teile võimaluse ahel tabada enne, kui see hostini jõuab.

Tipptasemel tuvastus ühendab tavaliselt madala taseme telemeetria (nt eBPF-põhised süsteemikõne jäljed) käitumusliku analüüsi ja pilvekontekstiga.Toorsignaalid pärinevad süsteemikõnedest, failitoimingutest, protsessipuudest ja soklitegevusest; analüütikakiht seostab neid identiteetide, võrgule avatud olemuse ja pilvevaradega, et eraldada healoomulised administratiivsed toimingud tegelikest põgenemiskatsetest.

Peamised süsteemikõne taseme näitajad

Teatud süsteemikõned on tugevalt seotud piiride murmise aktiivsusega ja konteinerite puhul tuleks neid eriti hoolikalt uurida:

• mount, umount, pivot_root – failisüsteemi ühenduste manipuleerimine või juurkataloogide pööramine, mida sageli kasutatakse hostiteede konteinerisse ühendamiseks või chrootide abil pääsemiseks.

• setns, unshare – uute nimeruumidega liitumine või loomine, mis on põhietapp tehnikates, mis hüppavad hosti algsesse nimeruumi.

• ptrace – silumine või teistesse protsessidesse süstimine; kahtlane konteineri piiride ületamisel või süsteemideemonite sihtimisel.

• capset – võimete muutmine käitusajal, mida potentsiaalselt kasutatakse uute võimsate lippude saamiseks täitmise ajal.

• init_module, finit_module – kerneli moodulite laadimine konteinerist on riskantne käitumine, mida legitiimsete töökoormuste puhul harva vaja läheb.

Reeglimootorid, näiteks Falco, võimaldavad teil nende süsteemikõnede kaudu konteineriteadlikult tuvastusloogikat väljendada.Näiteks saate hoiatada iga kord, kui konteinerdatud protsess koos CAP_SYS_ADMIN avab faili nimega release_agent kirjutamiseks, mis on äärmiselt tugev näitaja kasutajarežiimi abistajapõhisest põgenemiskatsest.

Kahtlased failidele juurdepääsu mustrid

Failide terviklikkuse ja juurdepääsu jälgimine täiendab süsteemikõnesid, näidates täpselt, milliseid teid ründaja puudutabKonteineri/peremehe kaardistamise läätse läbi vaadatuna muutub see võimsaks põgenemistestiks.

• Kirjutab aadressile /proc/sys or /sys konteineri signaalist püüab muuta kerneli parameetreid või seadme sätteid.

• Juurdepääs konteineri käitusaja soklitele, näiteks /var/run/docker.sock or /run/containerd/containerd.sock on üldise rakenduse konteineritest pärinev punane lipp.

• Muudatused /etc/passwd, /etc/shadow or /etc/sudoers hostis konteinerile nähtavate teede kaudu näevad välja nagu privileegide eskaleerimise ja püsivuse sammud.

• Loeb alates /proc/*/environ or /proc/*/cmdline nimeruumides võib viidata protsesside loendamisele ja volituste kogumisele väljaspool konteineri enda protsessipuud.

Kõige usaldusväärsemad hoiatused ühendavad mitu tegurit – tee, süsteemikõne, võimalused ja konteineri metaandmed.. Näiteks a mount süsteemikõne, mis pärineb mitte-administraatori, internetile avatud rakenduse konteinerist koos CAP_SYS_ADMIN ja sihtimise /proc/sys on palju murettekitavam kui sama toiming teadaolevalt privilegeeritud hooldustöö puhul.

Protsessitaseme ja käitumuslikud signaalid

Lisaks toormesüsteemikõnedele ja failisündmustele annab kõrgema taseme protsesside käitumine aimu toimuvast.Teatud tegevused on tavalistes mikroteenustes äärmiselt haruldased, kuid levinud pärast ärakasutamist.

• Interaktiivsed kestad, mis tekkisid mitteinteraktiivsetest konteineritest (nt /bin/bash veebiserveri protsessi all ilmuvad) viitavad praktilisele klaviatuuri kasutamisele.

• Privileegide eskaleerimise tööriistade kasutamine, näiteks sudo, su or newgrp konteinerite sees, eriti need, mis pole mõeldud interaktiivseks kasutamiseks, on väga kahtlased.

• Võrgu skaneerimine, külgliikumise tööriistad ja ebatavalised väljaminevad ühendused konteineritest, mis peaksid suhtlema ainult väikese hulga teenustega, viitavad luure- või levitamiskatsetele.

• Krüptokaevandajate signatuurid, ootamatud pikalt kestvad protsessoriga seotud protsessid või graafikakaardi kasutuse hüpped võib paljastada, et ründaja on juba kasutanud nende hostitaseme juurdepääsu ressursside rahaks tegemiseks.

Siin paistavad silma EDR ja CNAPP platvormid, mis säilitavad „põhjuslikkuse ahelat” (protsessipuu koos esivanemate ja keskkonnaga).Need võimaldavad analüütikutel kahtlaseid toiminguid jälgida algse konteineri kujutise, Kubernetes'i töökoormuse, pilvekonto või CI/CD torujuhtmeni, muutes algpõhjuste analüüsi ja pikaajalised lahendused tõhusamaks.

Konteinerite lekkimise vältimine: süvakaitse

Ükski kontroll ei saa garanteerida, et te ei satu kunagi konteinerist põgenemiskatsesse, seega vajate kihilist kaitset koodist pilveni.See hõlmab kujutise hügieeni, vähimate õiguste haldamist, tugevdatud konfiguratsioone, võrgukontrolli ja tugevat kaitset tööajal.

Käivita konteinerid minimaalsete õigustega

Alustage konteineritelt halastamatult ebavajalike privileegide eemaldamisegaVältige privilegeeritud režiimi, välja arvatud väga harvadel ja rangelt kontrollitud juhtudel, ning eelistage juurteta konteinereid või kasutajanimeruume, nii et „root sees“ viitab hostil privilegeerimata kasutajale.

Kuberneteses kasutage nutikalt securityContext seadeid nagu runAsNonRoot, runAsUser, allowPrivilegeEscalation: false ja readOnlyRootFilesystem: trueNeed piirangud piiravad ründaja tegevust isegi siis, kui ta rakenduse käituskeskkonna täielikult ohtu seab.

Võimekused peaksid olema kitsalt piiratud: eemaldage vaikimisi kõik ja lisage ainult töökoormuse jaoks vajalik minimaalne komplekt. Kui konteiner tõesti vajab CAP_SYS_ADMIN or CAP_NET_ADMIN, käsitle seda kõrge riskiga varana ning ümbritse seda täiendava jälgimise ja võrgu isoleerimisega.

Falco võimekusvälju kasutavad tuvastusreeglid võivad toimida turvavõrguna läbi lipsavate valekonfiguratsioonide korral.Näiteks võib reegel käivituda alati, kui konteinerdatud lõim koos CAP_SYS_ADMIN ja CAP_DAC_OVERRIDE kirjutab faili nimega release_agent, püüdes kinni suure hulga põgenemiskatseid väga madala müratasemega.

Kindlusta konteinerite tarneahel

Enamik ohtusid algab enne käitusaega haavatavate või muudetud kujutiste kujul.Tugev pilditurvalisus raskendab ründajatel esiteks usaldusväärse jalgealuse saamist.

Kasutage usaldusväärsetest registritest pärinevaid tugevdatud ja minimaalseid baaskujutisi ning hoidke neid ajakohasena.Väiksemad paketipõhised kujutised tähendavad vähem teeke, mis võivad sisaldada ärakasutatavaid CVE-sid, ning müüjad, nagu Wiz või distributsioonide hooldajad, pakuvad nüüd „distrovabasid” baase ainult sellega, mis on rangelt vajalik.

Integreerige haavatavuste skaneerimine ja tarkvara materjalide loetelud (SBOM) CI/CD-sseIga järku tuleks enne registrisse saatmist skannida ning nende kuvandite juurutamine, millel on parandamata kõrge või kriitilise tähtsusega vead, mis on seotud nende kokkupuute ja õigustega, tuleks blokeerida.

Kujutise usalduspoliitikad sulgevad tsükliKrüptograafiliselt allkirjastage kujutisi, konfigureerige juurdepääsu kontrollerid allkirjastamata või ebausaldusväärsete kujutiste tagasilükkamiseks ning säilitage nähtavus selle kohta, millised kujutisi klastrites aja jooksul tegelikult töötavad, et saaksite riskantsed artefaktid kiiresti kõrvaldada.

Lõpuks seadke parandusmeetmete prioriteediks tegeliku riski, mitte CVE-de algandmete põhjalKriitiline haavatavus uinunud, võrguühenduseta ja ilma lisavõimalusteta töötavas partiitöös on vähem pakiline kui keskmise suurusega viga internetiühendusega privilegeeritud podis, mis töötleb tundlikke andmeid.

Võrgu segmenteerimine ja tööaegne kaitse

Isegi kui ründaja maandub ühte konteinerisse, saab nutikas võrgukujundus takistada neil sellest täieliku klastri rikkumise teket.Granuleeritud võrgupoliitikad, tulemüürid ja teenindusvõrgud aitavad piirata külgmist liikumist.

Rakenda lubatud nimekirja stiilis võrgupoliitikaid Kuberneteses saavad podid suhelda ainult nende teenustega, mida nad tegelikult vajavad. See piirab ründaja võimet klastrit skannida või kutsuda sisemisi haldus-API-sid, näiteks Dockeri soklit või Kubernetesi API-serverit.

Käitusaja kaitsesüsteemid lisavad reaalajas piduridKui nad tuvastavad konteineri põgenemisega kooskõlas oleva käitumise (näiteks kahtlase nsenter kasutamine, hostPath ühendatakse / või konteinerdatud sokli rikkumise), saavad nad protsesse blokeerida või peatada, konteinereid isoleerida või intsidente automaatselt avada koos täieliku kohtuekspertiisi jäljega.

Platvormid nagu Wiz CNAPP ühendavad need käitusaja tuvastused pilvekonteksti ja turvagraafikuga.Konteinerite, hostide, identiteetide ja andmehoidlate vaheliste seoste kaardistamise abil näitavad nad mitte ainult seda, et põgenemine toimub, vaid ka seda, millised tundlikud varad plahvatusraadiuses asuvad, et meeskonnad saaksid reageerimist tähtsuse järjekorda seada.

Pidev jälgimine ja intsidentide valmisolek

Konteinerid on lühiajalised, mis muudab klassikalise kohtuekspertiisi ja logide analüüsi keerulisemaks.Kui sa seda ette ei planeeri, võivad põgenemise mõistmiseks vajalikud tõendid kaduda, kui kapsli plaan ümber planeeritakse.

Konteineri käituskeskkondade, orkestraatorite ja hostide jaoks tsentraliseeritud logimise ja mõõdikute kogumise loomineTööriistad nagu ELK, Prometheus ja pilvepõhised logiteenused tagavad, et protsessitegevus, turvasündmused ja konfiguratsioonimuudatused jäädvustatakse isegi ajutiste töökoormuste korral.

Looge konteineritest põgenemise stsenaariumide jaoks spetsiaalselt mänguplaaneNeed peaksid määratlema, kuidas kiiresti sõlmi piirata, kettaid hetktõmmistega salvestada, konteineri metaandmeid koguda ja pilveteenuse pakkujate või intsidentidele reageerimise meeskondadega koostööd teha, kui kahtlustate põgenemist või hosti tasemel ohtu sattumist.

Sellised müüjad nagu Palo Alto Networks (Cortex XDR, Prisma Cloud) ja teised on siin kirjeldatud tehnikate ümber loonud ulatusliku tuvastussisu.alates kasutajarežiimi abimeeste kuritarvitamisest kuni käitusaja sokli ärakasutamise ja tundliku ühendusjuurdepääsuni, andes kaitsjatele üldise „kahtlase tegevuse” müra asemel tegutsemist võimaldavaid ja kontekstipõhiseid hoiatusi.

Kõik need tükid – kindlad Linuxi isolatsiooni põhialused, piiratud õigused, tugevdatud kujutised, võrgukontroll ja sügav käitusaja nähtavus – muudavad konteinerite eksistentsiaalse ohu eest põgenemise hallatavaks riskiks, mida teie meeskond saab varakult tuvastada, tõhusalt ohjeldada ja millest õppida, et aja jooksul oma pilvepõhist turvapositsiooni veelgi tugevdada..