A konténerizáció terjedése jelentős előrelépést hozott az alkalmazásfejlesztési és üzemeltetési metódusok világában. A gyorsan skálázható konténerek azonban új biztonsági kihívások elé helyezik a szervezeteket. Mivel az alkalmazások nem monolit szerveren futnak, hanem több konténerből adódnak össze, a klasszikus biztonsági eszközök, amilyenek például a végpontvédelmi megoldások vagy klasszikus tűzfalak, nem biztosítanak megfelelő védelmet.
Az egyik gyakran alkalmazott új módszer a konténerek védelmére az eBPF (extended Berkeley Packet Filter). A Linux kernelre épülő technológia lehetővé teszi, hogy közvetlenül a kernelben futtassunk kódrészeket, biztonságosan, nagy teljesítménnyel. Lényegében kernel szintű megfigyelést alkalmazhatunk anélkül, hogy módosítanánk a forráskódot. Az eBPF monitorozza a konténerek által végrehajtott rendszerhívásokat, a hálózati forgalmat és az egyéb tevékenységeket. Itt fontos megemlíteni, hogy míg az agentless megoldások API-kapcsolataik segítségével figyelik a konténerkörnyezetet, ezzel megkönnyítve a telepítést és implementációt, addig az eBPF alapú megoldások konfigurációja több időt igényel.
Futtatás közben is figyel
A kernelszintű megfigyelés másik hatalmas előnye, hogy észleli azokat a fejlett támadási módszereket is, melyek célja kifejezetten a klasszikus biztonsági rétegek megkerülése – ezeket kernel bypass technikáknak nevezzük. Ilyen például, amikor a támadó közvetlenül hív meg rendszerhívásokat (például syscall segítségével), megkerülve a magasabb szintű API-kat. Egy másik jellemző példa a ptrace használata folyamatok beszúrása (process injection) céljából, vagy a /proc fájlrendszer manipulálása érzékeny adatok eltulajdonítására. A névterek manipulációja (unshare, setns, clone) szintén tipikus eszköze a konténereket célzó támadásoknak.
Az ilyen próbálkozások az agentless megoldások számára láthatatlanok maradhatnak, hiszen nem történik API-hívás vagy klasszikus logolható esemény. Az eBPF viszont közvetlenül a kernelben figyeli ezeket a hívásokat és mintázatokat, így képes nemcsak detektálni, de meg is akadályozza ezek végrehajtását, mielőtt kárt okoznának a rendszerben.
Ezzel szemben az agentless megoldások – mint például a Wiz –, bár megfelelő vizibilitást biztosítanak az infrastruktúra és konfigurációs állapotok szintjén, a runtime környezetről csak korlátozott adatot képesek szolgáltatni. A megoldás architektúrájából fakadóan nem avatkozik be a konténerek runtime működésébe, tehát nem detektálja valós időben a gyanús viselkedéseket, így a rosszindulatú tevékenységek megakadályozására is csak korlátozottan alkalmas. Ez tudatos döntés: a Wiz úgy lett tervezve, hogy könnyen integrálható legyen, agent nélkül, cserébe viszont nem biztosít aktív beavatkozást a runtime szinten.
Ha kiszabadul a támadó a konténerből

De erre is van megoldás. A Prisma Cloud Defender (a Prisma Cloud agentje) a CI/CD image szkennelése során blokkolhatja ezt a deploymentet. Ennek feltétele, hogy a magas vagy kritikus CVE-ket tartalmazó image-ek futását megakadályozó szabály aktiválva legyen. Az agentek azt is felismerik, ha a támadó ptrace parancsot futtat vagy a /proc fájlrendszer érzékeny részeit próbálja elérni.
Ilyenkor a következő forgatókönyv lép érvénybe:
- a rendszer riasztást hoz létre, ez a konfigurációtól függően lehet email, vagy az integrációs szint függvényében keletkezhet a SIEM rendszerben is, de a konzolon mindenképpen látjuk;
- naplózza az eseményt;
- megfelelő konfiguráció esetében leállítja az adott konténert.
Ha a támadó valahogy mégis kijut a konténerből, a további hálózati szkennelést is megakadályozza a rendszer, mivel csak az előre definiált hálózati kapcsolatok engedélyezettek.
Az MI is segít
Egy másik gyártó, a SentinelOne konténervédelmi megoldása más megközelítéssel, de hasonló eredményekkel akadályozza meg az ilyen jellegű támadásokat. A Prisma Cloud agentje szabályrendszer alapján cselekszik, a SentinelOne agentje viszont MI-alapú viselkedéselemző megoldással biztosítja a konténert.

Itt is nézzünk meg egy elképzelt, de konkrét esetet! A támadó namespace exploit segítségével próbál kitörni a konténerből. Mi történik ilyenkor? A hacker megpróbálja manipulálni a namespace beállításokat. Mivel az agent figyeli a rendszerhívásokat, észreveszi, ha valaki setns, unshare, clone vagy hasonló rendszerhívásokat próbál végrehajtani. Ezek a rendszerhívások normális működés esetén is előfordulhatnak, de a SentinelOne agentje képes felismerni a szokásos működéstől eltérő mintázatokat. Mire is kell gondolni? Ha egy konténeren belül futó, nem privilegizált folyamat hirtelen root jogosultságokat kap, az gyanús. Még gyanúsabb, ha utána setns rendszerhívást indít. Ilyenkor az agent azonnal megszakítja a hívást, izolálja a konténert, riasztást küld a konzolba, ahol minden részletet látunk:
- Honnan indult a támadás? (container ID, image név)
- Milyen rendszerhívást hajtottak végre?
- Milyen egyéb anomáliák társultak a folyamathoz? (privilege escalation, hálózati forgalom)
Ezt követően a rendszer összeköti a támadási láncot, így azonnal megszakítja a támadási útvonalat.
Agentekkel sokkal biztonságosabb
Ilyen szintű védelmet egyetlen agentless alapú megoldás sem biztosít, mivel nem képes aktívan beavatkozni a runtime környezetbe. Minden esetben ajánlatos agent-alapú konténerbiztonsági megoldásban gondolkodni, függetlenül attól, hogy milyen környezetben futtatjuk a konténereinket. Nagyon fontos, hogy tisztában legyünk azzal, hogy az agent-alapú, kernelszintű védelemmel és automatizált hálózati szegmentációval (amit például a Prisma Cloud biztosít) nagyot emelhetünk környezetünk biztonsági szintjén. A kernel szintű védelem további előnye, hogy a támadó nem képes megkerülni az agentet.
A SentinelOne Singularity Cloud Security és a Palo Alto Prisma Cloud konténervédelmi megoldásai nem csak piacvezetők, hanem valóban emelnek a biztonsági szinten. Nem csak vizibilitást nyújtanak, hanem aktív közbelépést is lehetővé tesznek, kiemelve őket a többi konténervédelmi megoldás közül.
Werner Obring
Konténerbiztonsági megoldások összehasonlítása
| Szempont | Wiz | Prisma Cloud | SentinelOne |
| Telepítés / agent szükséges | Agentless | Agent-based (Defender) | Agent-based (S1 Agent) |
| Runtime védelem | Korlátozott | Teljes | Teljes |
| Kernel szintű megfigyelés (eBPF) | Nem támogatott | Igen | Igen |
| Viselkedésalapú detekció | Nem | Korlátozott | Igen (MI-alapú) |
| CI/CD pipeline integráció | Igen | Igen | Igen |
| Aktív beavatkozás támadás esetén | Nem | Igen | Igen |
| Hálózati szegmentáció | Nem | Igen | Korlátozott |
| Vizibilitás | Nagyfokú | Nagyfokú | Nagyfokú |
Forrás: Clico







