Виявлення та запобігання атакам типу «втеча з контейнерів»

Головна » Python » Виявлення та запобігання атакам типу «втеча з контейнерів»

Втеча контейнерів стала однією з тих тем, яка не дає хмарним та платформним командам спати вночі. оскільки один неправильно налаштований pod або застаріле ядро ​​можуть перетворити ізольоване робоче навантаження на прямий міст до базового хоста. Коли це трапляється, зловмисник більше не обмежений одним контейнером: він може переміщатися між вузлами, отримувати доступ до даних інших орендарів або навіть захоплювати весь кластер.

Розуміння того, як насправді працюють escape-переходи контейнерів – від внутрішніх механізмів Linux до сигналів середовища виконання та виявлення EDR – це різниця між страшним модним словом та ризиком, яким ви насправді можете керувати.У цьому посібнику ми розглянемо, що таке контейнер на рівні ОС, як на практиці відбуваються випадки втечі, основні методи експлойтів, що зустрічаються в реальних умовах, а також як їх виявляти та запобігати за допомогою моніторингу можливостей, правил Falco, платформ CNAPP та старомодного посилення захисту та сегментації.

Що таке випадок виходу контейнера та чому це важливо?

Вихід контейнера відбувається, коли зловмиснику вдається порушити логічну ізоляцію, яка повинна відокремлювати контейнер від хоста та від інших контейнерів.Замість того, щоб бути обмеженим власними просторами імен та контрольними групами, зловмисник отримує можливість запускати код з контекстом рівня хоста – часто з високими або повними привілеями.

Контейнери відрізняються від віртуальних машин суттєво: всі вони використовують одне й те саме ядро ​​хоста.Такі технології, як простори імен Linux (PID, монтування, мережа тощо), контрольні групи та можливості, розбивають ядро ​​на безліч ізольованих представлень, але якщо вразливість або неправильна конфігурація дозволяє зловмиснику перетнути ці межі, компрометація може поширитися далеко за межі спочатку зламаного контейнера.

З точки зору бізнесу, радіус вибуху в разі успішної втечі робить її такою небезпечною.Один вразливий контейнер, вихід на Інтернет, може призвести до крадіжки конфіденційних даних, масштабного розгортання криптомайнерів, порушення роботи критично важливих сервісів та серйозних проблем із дотриманням вимог у багатокористувацьких або регульованих середовищах.

Зловмисники зазвичай використовують вихід контейнера як один із кроків у ширшому ланцюжку атак.: вони потрапляють у контейнер з низькими привілеями (через помилки програми, слабкі облікові дані або проблеми з ланцюжком поставок), підвищують привілеї всередині контейнера, а потім виходять на хост для горизонтальної зміни, збору облікових даних або встановлення стійкої персистенції, такої як руткіт на рівні ядра.

Як контейнери працюють під капотом

Щоб по-справжньому зрозуміти методи виходу з гри, вам спочатку потрібна ментальна модель того, як контейнери Linux ізолюють процеси.Контейнер — це, по суті, дерево процесів, атрибути якого (простори імен, можливості, контрольні групи, профіль seccomp тощо) були налаштовані середовищем виконання контейнера, таким як containerds, Docker або CRI-O, і ширше. технології контейнеризації.

Коли контейнер запускається, середовище виконання породжує процес і перетворює його на процес ініціалізації власного маленького всесвіту.: він отримує власний простір імен PID, простір імен монтування, простір імен мережі та багато іншого, все це забезпечується ядром. Потім цей процес виконує будь-яку команду, визначену в конфігурації образу (наприклад, ENTRYPOINT/CMD Dockerfile).

Можливості — це спосіб Linux розрізати традиційний всемогутній root-доступ на менші частини дозволів.Замість того, щоб «root може робити все», ядро ​​визначає такі прапорці, як CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_SYSLOG і десятки інших. Кожен потік містить набори можливостей (дозволених, ефективних, успадковуваних), що визначають, які привілейовані операції він може виконувати.

Простори імен відповідають на питання «де процес може реалізувати свої можливості?»Наприклад, простір імен PID робить PID 1 всередині контейнера не пов'язаним з PID 1 на хості, а простір імен монтування надає контейнеру власний вигляд файлової системи. Навіть якщо процес має таку можливість, як CAP_KILL, у обмеженому просторі імен PID він може завершувати лише процеси, що існують у цьому просторі імен.

C-групи доповнюють цю ізоляцію, контролюючи, скільки ресурсів може спалювати контейнер. – Спільний доступ до процесора, обмеження пам’яті, операції вводу/виводу тощо. У поєднанні з фільтрами seccomp (списками дозволених/заборонених системних викликів) та LSM, такими як AppArmor або SELinux, ви отримуєте багаторівневу ізоляцію, від якої залежить сучасна безпека контейнерів.

Чому зловмисники намагаються втекти з контейнерів

Як тільки зловмисник скомпрометує контейнер, він швидко виявляє, що життя всередині досить обмежене.обмежена файлова система, обмежений перегляд мережі, можливо, без root-прав і зазвичай без прямого доступу до інших робочих навантажень.

Втеча до господаря знімає ці захисні бар'єриЯкщо вони можуть виконувати команди в початкових просторах імен хоста, вони можуть бачити всі процеси, монтувати будь-яку файлову систему, збирати облікові дані з таких місць, як /root/.ssh або агенти хмарних метаданих та переміщуються в інші контейнери чи віртуальні машини.

Втечі також сприяють важковикорінній стійкостіЗамість того, щоб розміщувати бекдор лише в тимчасовому контейнері, зловмисник може встановити модуль ядра, втрутитися у середовище виконання контейнера, таке як runc або containerd, або розгорнути демонічний набір, який гарантує запуск поду з бекдором на кожному вузлі кластера Kubernetes.

З точки зору виявлення, багато контрольних сигналів про втечу контейнера перетинаються з класичними сигналами ескалації привілеїв та поведінкою горизонтального переміщення. – завантаження модуля ядра, підозріле mount/unshare/setns використання, прямий доступ до сокетів середовища виконання, експлуатація SUID та аномальний доступ до файлів до шляхів хоста, що знаходяться всередині контейнерів.

Основні шляхи витоку з контейнера: вразливості, привілеї та неправильні конфігурації

Більшість реальних сценаріїв втечі з контейнерів поділяються на три широкі категорії: використання вразливостей (ядра або середовища виконання), зловживання надмірно привілейованими контейнерами або використання неправильних конфігурацій, таких як небезпечні монтування та відкриті сокети.

Вразливості виконання ядра та контейнера

Оскільки кожен контейнер використовує одне й те саме ядро ​​хоста, одна помилка ядра може запропонувати прямий шлях до втечі.Відомі проблеми, такі як Dirty COW (CVE‑2016‑5195) та Dirty Pipe (CVE‑2022‑0847), — це локальні помилки підвищення привілеїв, які дозволяють зловмисникам записувати дані в зіставлення лише для читання та довільні файли, що часто дає їм змогу втручатися у бінарні файли хоста або конфігурацію зсередини контейнера.

Однією особливо критичною помилкою, пов'язаною з контейнером, була CVE‑2019‑5736 у runc.Це дозволяло процесу в контейнері перезаписувати бінарний файл runc на хості під час запуску або виконання цього контейнера, надаючи зловмиснику можливість виконання коду на рівні хоста. Оскільки runc лежить в основі Docker, Kubernetes та інших платформ, вплив був широкомасштабним.

Зовсім недавно такі розкриття, як «Дірявий посуд» (наприклад, CVE‑2024‑21626), показали, що системи збірки та шляхи стартапів також є благодатним ґрунтом.Вразливості в логіці ініціалізації BuildKit або runc дозволяють зловмисникам здійснити вразливість під час збірки образу або раннього запуску контейнера, перш ніж інші засоби захисту можуть бути повністю застосовані.

Демони виконання контейнерів, такі як containerds, Docker Engine або CRI-O, мали свою частку помилок.Наприклад, CVE‑2022‑23648 у плагіні CRI containerd дозволяв зловмисникам, які могли створювати контейнери, монтувати конфіденційні шляхи хостів (наприклад /root/.ssh) у контейнер та зчитують дані, які вони ніколи не повинні бачити, забезпечуючи трамплін до повного виходу.

Помітні CVE, пов'язані з виходом контейнера, та способи їх усунення

• CVE‑2019‑5736 (виконання): дозволено перезаписувати бінарний файл runc хоста з контейнера, що впливає на Docker, Kubernetes та інші стеки на основі runc. Заходи захисту включають агресивне встановлення патчів, сканування образів на наявність інструментів експлойтів та моніторинг модифікацій бінарних файлів runc під час виконання.

• CVE‑2016‑5195 (Брудна корова): умова змагання в копіюванні під час запису, яка дозволяє непривілейованим процесам отримувати доступ на запис до зіставлень лише для читанняЗсередини контейнера його можна було б зловживати для зміни файлів хоста, якщо вони були доступні через монтування.

• CVE‑2022‑0847 (Брудна труба): ще одна помилка ядра, що дозволяє несанкціонований запис у файли, включаючи ті, що змонтовані в контейнери лише для читанняВін не надає автоматичного виходу, але добре поєднується з привілейованими монтуваннями або неправильними конфігураціями під час виконання.

• CVE‑2024‑21626 та пов’язані з цим проблеми «Дірявих посудин»: недоліки в BuildKit та runc, які розкривали ресурси хоста під час збірки образу або запуску контейнера., що доводить, що сам конвеєр збірки може бути частиною поверхні атаки.

Заходи щодо зменшення наслідків для всього цього класу проблем зосереджені на гігієні патчів та архітектурних рішеннях.: оновлюйте ядра хоста, використовуйте мінімальні або бездистрибутивні базові образи для зменшення поверхні атаки, надавайте перевагу середовищам виконання з ізольованим програмним середовищем або середовищам виконання на віртуальній машині для високочутливих робочих навантажень та постійно відстежуйте підозрілі системні виклики та записи файлів, які виглядають як спроби експлойту ядра.

Надмірні можливості та привілейовані контейнери

Можливості були винайдені для зменшення сили кореня, але на практиці «дрібні шматочки» часто знову збираються разом.Розробники, які перебувають під тиском «просто змусити це працювати», часто надають CAP_SYS_ADMIN або просто запускайте контейнери як --privileged, ефективно відновлюючи коренеподібну силу всередині контейнера.

CAP_SYS_ADMIN відомо своєю надмірною силою: дозволяє монтувати файлові системи, створювати або приєднуватися до просторів імен (unshare, setns), налаштування контрольних груп та багато іншого. Завдяки правильній комбінації монтувань та просторів імен, зловмисник з такою можливістю може перейти до початкового простору імен хоста та отримати глобальну видимість.

CAP_NET_ADMIN є аналогічно широким з точки зору мережіЙого можна використовувати для переналаштування інтерфейсів, маніпулювання правилами iptables та ввімкнення незв'язного режиму. У ланцюжку виведення його можна зловживати для перехоплення трафіку, обходу мережевих політик або тунелювання сегментації.

Запуск контейнера в повністю привілейованому режимі, по суті, означає «трактувати це як частину хоста».Він отримує всі можливості, може отримувати доступ до хост-пристроїв і часто обходить профілі seccomp. Для багатьох ланцюжків атак найскладнішим кроком є ​​просто знайти один такий неправильно налаштований контейнер і використовувати його як стартовий майданчик.

Сучасні інструменти, такі як Falco, почали надавати можливості для виявлення на рівні потоків.Тепер ви можете перевіряти такі поля, як thread.cap_effective, thread.cap_permitted та thread.cap_inheritable під час виконання та запускати сповіщення щоразу, коли процес із ризикованими можливостями виконує підозрілі дії.

Неправильні конфігурації: монтування, сокети та трюки з журналами

Напрочуд велика частка контейнерних виходів не залежить від екзотичних 0-денних значень, а від простих неправильних конфігурацій.Коли оператори монтують конфіденційні шляхи до хостів у контейнери або розкривають внутрішні сокети Unix, зловмисники часто можуть пройти крізь них.

Небезпечні шляхи до хоста або монтування томів є класичним прикладомЯкщо контейнер отримує доступ для читання та запису до каталогів, таких як /etc, /proc, /sys or /var/run від хоста, модель ізоляції значною мірою руйнується. Запис до /proc/sys або sysfs може змінювати параметри ядра; доступ до файлів конфігурації хоста, таких як /etc/shadow може розголошувати облікові дані.

Сокет Docker (/var/run/docker.sock) та інші сокети виконання є ще однією болючою помилкою конфігураціїМонтування цього всередині контейнера надає тому, хто керує контейнером, майже повний контроль над демоном Docker. Через простий спосіб curl --unix-socket виклики, зловмисник може отримати список контейнерів, створити новий привілейований контейнер, який монтує корінь хоста, та вийти з цього допоміжного контейнера.

У Kubernetes також зловживали обробкою журналів kubelet та монтуванням журналів хоста.Якщо под має хоста /var/log Якщо змонтовано bind, і зловмисник може маніпулювати символічними посиланнями журналів, а також читати журнали через API, він може вказати символічне посилання журналу на довільні файли хоста та обманом змусити kubelet повернути, скажімо, /etc/shadow зміст.

Навіть, здавалося б, проста поведінка SUID може відігравати певну роль.У середовищах, де контейнер використовує спільний простір імен користувача з хостом, встановлення біта SUID у двійковому файлі у спільному каталозі зсередини контейнера пізніше може бути використано користувачем хоста з низькими привілеями для виконання цієї програми з привілеями root на хості.

Техніки втечі з бетонних контейнерів, що спостерігаються в дикій природі

Збільшення масштабу від категорій до конкретних методів допомагає розпізнавати закономірності у телеметрії та звітах про загрозиКілька сімейств методів неодноразово демонструвалися дослідниками та використовувалися в тестах на проникнення або реальних атаках.

Помічники режиму користувача та release_agent трюк

Ядро Linux надає функцію, call_usermodehelper, для запуску програм користувацького простору з підвищеними привілеями у відповідь на події в просторі ядраЗа певних умов файли, контрольовані користувачем, можуть впливати на виконання програми, перетворюючи легітимний механізм на вектор втечі.

Cgroups версії 1 release_agent є найвідомішим прикладом цієї закономірностіКоли контрольна група стає порожньою та notify_on_release увімкнено, ядро ​​запускає бінарний файл, на який вказує release_agent файл. Якщо зловмисник всередині контейнера може монтувати та маніпулювати файловою системою cgroup з достатніми привілеями, він може вказати release_agent на довільному виконуваному файлі на хості.

Типова послідовність експлойтів виглядає приблизно такстворити та змонтувати каталог cgroup, увімкнути notify_on_release, набір release_agent до шляху шкідливого скрипта в просторі імен хоста, а потім очистити список процесів контрольної групи. Ядро обережно запускає скрипт атакуючого з привілеями root на хості.

Виявлення вимагає як семантичного розуміння допоміжних шляхів користувацького режиму, так і контексту щодо того, звідки походять зміни.Надійний підхід відображає всі call_usermodehelper виклик сайтів, визначає, на які можуть впливати файли режиму користувача, а потім відстежує записи в ці файли, коли вони походять з контейнерів, позначаючи підозрілі зміни.

Ескалація привілеїв до хоста через біти SUID

Техніка SUID не є «чистим» виходом з контейнера, оскільки вона припускає, що зловмисник вже має певний доступ до хоста., але часто він пов'язаний з доступом до контейнера для переходу від обмежених користувачів хоста до root.

Хитрощі залежать від спільних каталогів між хостом і контейнером, а також спільного простору імен користувачів.З контейнера, що працює від імені root, зловмисник розміщує виконуваний файл у каталог, видимий з обох сторін (наприклад, спільний том), та встановлює біт SUID за допомогою chmod u+s.

Пізніше користувач без прав root на хості виконує цей бінарний файл і отримує права root на хості., оскільки біт SUID інтерпретується в контексті хоста. Контейнер використовується як зручне місце для підготовки корисного навантаження SUID без обмежень, які можуть існувати для цього користувача хоста.

Прозорість випадків зловживання SUID зосереджена на трьох моментах: створення виконуваного файлу у спільному шляху, встановлення бітів SUID/SGID з контейнера та виконання цього файлу на хості обліковим записом, який не є root. Інструменти EDR та захисту середовища виконання можуть співвідносити ці кроки для генерації високоточних сповіщень.

Зловживання сокетами під час виконання: Docker та containerd

Контейнерні середовища часто покладаються на архітектуру клієнт/сервер, де інструменти CLI або оркестратори взаємодіють з демонами через сокети Unix.. Приклади включають /var/run/docker.sock для Docker або /run/containerd/containerd.sock для контейнерів.

Якщо ці сокетні файли змонтовані всередині контейнера, цей контейнер може ефективно діяти як клієнт адміністратора.Зловмисник, який скомпрометує контейнер, може надсилати API-запити безпосередньо до середовища виконання, перераховуючи контейнери, запускаючи та зупиняючи робочі навантаження або створюючи абсолютно новий привілейований контейнер із монтуванням хоста.

Використання універсального інструменту, такого як curl, легко отримати доступ до віддаленого API Docker через Unix-сокетзапит /containers/json перерахувати контейнери, надіслати до /containers/create з визначенням JSON для створення привілейованого помічника, а потім викликати /containers/{id}/start щоб запустити його. Цей допоміжний контейнер може змонтувати кореневу файлову систему хоста та надати зловмиснику інтерактивний доступ.

Захисники можуть полювати на це різними способами: моніторинг доступу до Unix-сокетів середовища виконання з контейнеризованих процесів, виявлення підозрілих curl --unix-socket або виклики командного рядка під час виконання, спрямовані на ці сокети, та сповіщення про незвичайні шаблони створення контейнерів (наприклад, hostPath монтується до /, --privileged у специфікаціях Kubernetes).

Специфічні для Kubernetes хитрощі: монтування журналів та вихідні дані для pod-ів

У Kubernetes деякі атаки спрямовані на поведінку Kubelet та абстракції Kubernetes, а не на необроблені концепції Docker.Поди, що монтують каталоги хостів, такі як /var/log or /var/lib/docker особливо цікаві для супротивників.

Один продемонстрований метод зловживає тим, як kubelet розв'язує символічні посилання під час повернення журналів.Кожен pod отримує файл журналу під /var/log що створює символічне посилання на каталог контейнера під /var/lib/docker/containersЯкщо зловмисник може створювати або змінювати символічні посилання в /var/log через монтування hostPath вони можуть перенаправити «журнал» на довільний файл (наприклад, /etc/shadow).

Коли обліковий запис користувача або служби з правами на читання журналів викликає kubectl logs або відповідний API, kubelet слідує за символічним посиланням і повертає вміст цієї ціліЗа допомогою певної креативності зловмисник може розкрити великі частини файлової системи хоста через серію таких символічних посилань «логів».

Виявлення тут поєднують мережеві та файлові системимоніторити HTTP-запити зчитування журналів Kubernetes на наявність аномальних шаблонів шляхів та одночасно стежити за створенням або модифікацією символічних посилань у хості /var/log що походять з контейнерних процесів.

Конфіденційне монтування хостів та пряма крадіжка даних

Іноді escape полягає лише у зчитуванні або зміні даних хоста зсередини контейнера без виконання коду на рівні хоста.Неправильно налаштованих монтувань, які розкривають конфіденційні каталоги, достатньо для досягнення серйозного впливу.

Наприклад, контейнер може мати монтування, таке як /host_etc вказуючи на господаря /etc каталогЗловмисник, який натрапить на цей шлях, може просто відкрити /host_etc/passwd or /host_etc/shadow і вони фактично зчитують файли автентифікації хоста з контейнера.

Виявлення неправильного використання таких монтувань є складним завданням, оскільки багато шаблонів доступу схожі на звичайні операції з файлами.Ви не можете просто спостерігати за /etc/shadow всередині контейнерів, оскільки це зазвичай стосується власного файлу контейнера, а не файлу хоста. Вам потрібен шар зіставлення, який перетворює «шлях контейнера» на «шлях базового хоста» для кожного монтування.

Розширені інструменти EDR та CNAPP вирішують цю проблему, визначаючи точки монтування та відстежуючи доступ на основі шляху на стороні хоста.Таким чином, будь-яке читання або запис, яке зрештою стосується файлу, чутливого до хоста, – навіть через нешкідливий шлях усередині контейнера – може бути позначено в режимі реального часу.

Виявлення спроб виходу з контейнера під час виконання

Профілактичне загартування є важливим, але вам також потрібно добре стежити за тим, що відбувається під час роботи контейнерів.Сучасні атаки часто об'єднують кілька кроків у ланцюжок, а надійний моніторинг виконання дає вам можливість перехопити ланцюжок, перш ніж він досягне хоста.

Найсучасніші методи виявлення зазвичай поєднують низькорівневу телеметрію (наприклад, трасування системних викликів на основі eBPF) з поведінковою аналітикою та хмарним контекстом.Необроблені сигнали надходять від системних викликів, файлових операцій, дерев процесів та активності сокетів; аналітичний рівень співвідносить їх з ідентифікаторами, мережевим ризиком та хмарними ресурсами, щоб відокремити нешкідливі дії адміністратора від справжніх спроб втечі.

Ключові індикатори рівня системних викликів

Певні системні виклики тісно пов'язані з активністю порушення меж і повинні піддаватися додатковій перевірці при виклику контейнерами:

• mount, umount, pivot_root – маніпулювання монтуванням файлової системи або зміною кореневих каталогів, часто використовується для приєднання шляхів хоста до контейнера або екранування chroot-текстів.

• setns, unshare – приєднання до просторів імен або створення нових, що є ключовим кроком у методах, що передбачають перехід до початкового простору імен хоста.

• ptrace – налагодження або впровадження в інші процеси; підозріло при перетині меж контейнера або націлюванні на системні демони.

• capset – модифікація можливостей під час виконання, потенційно використовувана для отримання нових потужних прапорців під час виконання.

• init_module, finit_module – завантаження модулів ядра з контейнера є високоризикованою поведінкою, яка рідко потрібна в легітимних робочих навантаженнях.

Механізми правил, такі як Falco, дозволяють виражати логіку виявлення через ці системні виклики контейнерно-залежним способом.Наприклад, ви можете сповіщати щоразу, коли контейнеризований процес за допомогою CAP_SYS_ADMIN відкриває файл з назвою release_agent для письма, що є надзвичайно вагомим показником спроби виходу з допоміжного режиму користувача.

Підозрілі шаблони доступу до файлів

Моніторинг цілісності файлів та доступу до них доповнює системні виклики, показуючи точно, яких шляхів торкається зловмисник.Якщо розглядати це крізь призму картування контейнера/господаря, це стає потужним детектором втечі.

• Пише до /proc/sys or /sys з контейнерного сигналу, що намагається змінити параметри ядра або налаштування пристрою.

• Доступ до сокетів середовища виконання контейнерів, таких як /var/run/docker.sock or /run/containerd/containerd.sock є червоним прапорцем, коли походить із контейнерів загального застосування.

• Зміни до /etc/passwd, /etc/shadow or /etc/sudoers на хості через видимі для контейнера шляхи виглядають як кроки ескалації привілеїв та забезпечення персистенції.

• Читає з /proc/*/environ or /proc/*/cmdline у різних просторах імен може вказувати на перерахування процесів та збір облікових даних поза межами власного дерева процесів контейнера.

Найнадійніші сповіщення поєднують кілька факторів – шлях, системний виклик, можливості та метадані контейнера.. Наприклад, a mount системний виклик, що походить з контейнера програми, що не належить адміністратору та доступна через Інтернет, з CAP_SYS_ADMIN та націлювання /proc/sys набагато тривожніша, ніж та сама операція, виконана відомою привілейованою роботою з технічного обслуговування.

Сигнали на рівні процесу та поведінкові сигнали

Окрім необроблених системних викликів та подій файлів, поведінка процесів вищого рівня відображає те, що відбувається.Певні дії є надзвичайно рідкісними у звичайних мікросервісах, але поширеними на етапах після експлуатації.

• Інтерактивні оболонки, що створюються з неінтерактивних контейнерів (наприклад, /bin/bash (що з’являються під час процесу веб-сервера) свідчать про практичну активність клавіатури.

• Використання інструментів підвищення привілеїв, таких як sudo, su or newgrp всередині контейнерів, особливо ті, що не призначені для інтерактивного використання, є дуже підозрілим.

• Сканування мережі, інструменти для латерального руху та незвичайні вихідні з'єднання з контейнерів, які повинні взаємодіяти лише з невеликим набором сервісів, вказують на спроби розвідки або поширення.

• Сигнатури криптомайнерів, неочікувані тривалі процеси, що потребують багато ресурсів процесора, або піки використання графічного процесора може виявити, що зловмисник вже використав свій доступ на рівні хоста для монетизації ресурсів.

Тут сяють платформи EDR та CNAPP, які підтримують «ланцюг причинно-наслідкових зв'язків» (дерево процесів з походженням та середовищем).Вони дозволяють аналітикам відстежувати підозрілі операції аж до початкового образу контейнера, робочого навантаження Kubernetes, хмарного облікового запису або конвеєра CI/CD, що робить аналіз першопричин та довгострокові виправлення ефективнішими.

Запобігання витокам з контейнерів: глибоко ешелонований захист

Жоден окремий контроль не може гарантувати, що ви ніколи не зіткнетеся зі спробою витоку з контейнера, тому вам потрібен багаторівневий захист від коду до хмари.Це включає гігієну зображень, мінімальні привілеї, посилені конфігурації, мережевий контроль та надійний захист під час виконання.

Запускати контейнери з найменшими привілеями

Почніть з безжального позбавлення контейнерів непотрібних привілеївУникайте привілейованого режиму, окрім дуже рідкісних випадків, з жорстким контролем, та надавайте перевагу безкореневим контейнерам або просторам імен користувачів, щоб «root inside» відповідав непривілейованому користувачеві на хості.

У Kubernetes розумно використовуйте налаштування securityContext як runAsNonRoot, runAsUser, allowPrivilegeEscalation: false та readOnlyRootFilesystem: trueЦі обмеження обмежують дії зловмисника, навіть якщо вони повністю скомпрометують середовище виконання програми.

Можливості повинні бути чітко визначені: за замовчуванням відкинути все та додати лише мінімальний набір, необхідний для робочого навантаження. Якщо контейнеру дійсно потрібно CAP_SYS_ADMIN or CAP_NET_ADMIN, ставтеся до нього як до активу високого ризику та оточуйте його додатковим моніторингом та мережевою ізоляцією.

Правила виявлення, що використовують поля можливостей Falco, можуть виступати запобіжником для помилок у конфігураціях, які прослизають.Наприклад, правило може спрацьовувати щоразу, коли контейнеризований потік із CAP_SYS_ADMIN та CAP_DAC_OVERRIDE записує у файл з назвою release_agent, виявляючи великий клас експлойтів для втечі з дуже низьким рівнем шуму.

Забезпечте ланцюжок поставок контейнерів

Більшість компрометацій починаються ще до запуску, у вигляді вразливих або підроблених образівНадійний захист зображень ускладнює для зловмисників отримання надійної опори.

Використовуйте захищені, мінімальні базові образи з перевірених реєстрів та регулярно їх оновлюйте.Менші образи з меншою кількістю пакетів означають менше бібліотек, які можуть містити шкідливі CVE, а постачальники, такі як Wiz або розробники дистрибутивів, тепер надають бази «без дистрибутивів», що містять лише те, що вкрай необхідно.

Інтегруйте сканування вразливостей та специфікації матеріалів програмного забезпечення (SBOM) у CI/CDКожну збірку слід сканувати перед завантаженням до реєстру, а образи з невиправленими помилками високого або критичного рівня серйозності, що стосуються їхнього впливу та привілеїв, слід блокувати від розгортання.

Політики довіри до зображень замикають циклПідписуйте образи криптографічно, налаштовуйте контролери доступу для відхилення непідписаних або ненадійних образів та підтримуйте видимість того, які образи фактично працюють у кластерах з часом, щоб ви могли швидко видаляти ризиковані артефакти.

Зрештою, пріоритет усунення наслідків має бути на основі реального ризику, а не сирих показників CVE.Критична вразливість у неактивному пакетному завданні, що не підключене до мережі та виконується без додаткових можливостей, є менш терміновою, ніж «середня» помилка в привілейованому піді, що має доступ до Інтернету та обробляє конфіденційні дані.

Сегментація мережі та захист під час виконання

Навіть якщо зловмисник потрапляє в один контейнер, розумне проектування мережі може запобігти перетворенню цього на повноцінне порушення кластера.Деталізовані мережеві політики, брандмауери та сервісні мережі допомагають обмежити горизонтальне переміщення.

Впроваджуйте мережеві політики у стилі білого списку у Kubernetes, щоб pod-системи могли взаємодіяти лише з тими сервісами, які їм дійсно потрібні. Це обмежує можливості зловмисника сканувати кластер або викликати внутрішні API керування, такі як сокет Docker або сервер Kubernetes API.

Системи захисту під час виконання додають гальма в режимі реального часуКоли вони виявляють поведінку, що відповідає виходу з контейнера (наприклад, підозрілу nsenter використання, hostPath монтується до / або втручання в сокет контейнерів), вони можуть блокувати або завершувати процеси, ізолювати контейнери або автоматично відкривати інциденти з повним судово-медичним слідом.

Такі платформи, як Wiz CNAPP, поєднують ці виявлення під час виконання з хмарним контекстом та графом безпеки.Відображаючи зв'язки між контейнерами, хостами, ідентифікаторами та сховищами даних, вони показують не лише те, що відбувається втеча, але й які конфіденційні ресурси знаходяться в радіусі вибуху, щоб команди могли визначити пріоритети реагування.

Безперервний моніторинг та готовність до інцидентів

Контейнери недовговічні, що ускладнює класичну криміналістичну експертизу та аналіз журналів.Якщо ви не сплануєте це заздалегідь, докази, необхідні для розуміння втечі, можуть зникнути, коли капсулу буде перенесено.

Налаштуйте централізоване ведення журналу та збір метрик для середовища виконання контейнерів, оркестраторів та хостівТакі інструменти, як ELK, Prometheus та хмарні служби журналів, гарантують, що активність процесів, події безпеки та зміни конфігурації фіксуються навіть для тимчасових робочих навантажень.

Створіть ігрові посібники спеціально для сценаріїв втечі з контейнераВони мають визначати, як швидко ізолювати вузли, робити знімки дисків, збирати метадані контейнерів та координувати дії з постачальниками хмарних послуг або командами реагування на інциденти, коли ви підозрюєте втечу або компрометацію на рівні хоста.

Такі постачальники, як Palo Alto Networks (Cortex XDR, Prisma Cloud) та інші, створили великий контент для виявлення на основі описаних тут методів., від зловживання допоміжними функціями користувацького режиму до експлуатації сокетів під час виконання та чутливого доступу до монтування, надаючи захисникам дієві, висококонтекстні сповіщення, а не загальний шум «підозрілої активності».

Поєднання всіх цих складових – надійних основ ізоляції Linux, жорстких привілеїв, захищених образів, мережевого контролю та глибокої видимості середовища виконання – перетворює витік контейнера з екзистенційної загрози на керований ризик, який ваша команда може виявити на ранній стадії, ефективно стримувати та вчитися на ньому, щоб з часом ще більше зміцнити вашу хмарну безпеку..