Безопасность контейнерного рантайма: обнаружение аномалий, ограничение привилегий и реагирование

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

Данные проверки, несомненно, важны, но они направлены на защиту и проверку системы только до запуска в эксплуатацию (будь то тестовый контур или прод).

Реальные атаки на приложение происходят позже, когда контейнер уже запущен, приложение работает, и уязвимость может быть эксплуатирована. Здесь единственным барьером между атакующим и инфраструктурой становится безопасность среды выполнения. В классическом подходе, который позволяет автоматизировать путь кода от написания до запуска в прод (CI/CD) команды направляют свое внимание на поиск уязвимостей до развертывания проекта на сервере (подход «Shift Left»), а обеспечение безопасности среды выполнения («Runtime Security») реализует защиту от атак в реальном времени (подход «Shield Right»).

Поговорим о том, как строится защита на данном этапе. Нам помогут следующие методы:

• ограничение привилегий;
• обнаружение аномалий;
• реагирование на инциденты.

Почему вообще необходимы данные меры защиты? От чего не спасает проверка на ранних этапах?

Даже если образ прошёл все проверки, он все еще может быть подвержен удалённому выполнению произвольного кода в приложении (RCE-уязвимостям), иметь «пробелы» в безопасности из-за ошибок в конфигурациях, использовать зависимости, которые были скомпрометированы после доставки и развертывания кода.

Если одна из описанных выше проблем дала о себе знать, то злоумышленник может получить доступ к контейнеру, после чего происходит атака.

Возможные сценарии данной атаки можно описать на основании реальных кейсов, а также на основании найденных уязвимостей в контейнерных окружениях:

• Несанкционированный запуск оболочки (bash, sh). Злоумышленник заставляет приложение выполнить команду через системную оболочку. Получив доступ к shell, атакующий может просматривать файлы, проверять переменные окружения и права пользователя.
• Использование утилит (curl, wget). Стандартные утилиты часто присутствуют в образах для тестов, но в среде выполнения они превращаются в оружие для доставки полезной нагрузки. С помощью команды wget злоумышленник скачивает и запускает вредоносный код, это позволяет обойти ограничения образа и доставить в систему криптомайнеры, сканеры сети или эксплойты для повышения привилегий.
• Установление reverse shell. Скомпрометированный контейнер сам инициирует соединение с компьютером злоумышленника. Атакующий выступает стороной, принимающей соединение. Контейнеризированное приложение передает управление вводом-выводом оболочки удаленному серверу. При этом обратные соединения часто обходят стандартные правила сетевых экранов, которые блокируют входящий трафик, но разрешают исходящий.
• Побег из контейнера: доступ к /proc, /sys или Docker Socket. Если контейнер настроен неправильно злоумышленник может попытаться получить доступ на хостовую машину. Монтирование /var/run/docker.sock внутрь контейнера позволяет атакующему отправлять команды Docker-демону и запускать новые контейнеры с полным доступом к файловой системе хоста. Через директории /proc и /sys можно получить доступ к переменным ядра, устройствам или памяти других процессов хоста. Данный сценарий ведет к полной компрометации физического сервера или ноды кластера.
• Сканирование сети и движение по кластеру. Оказавшись внутри одного контейнера, злоумышленник может попытаться развить атаку на весь кластер. Используются инструменты для сетевого сканирования, например, nmap, или простые скрипты на bash для поиска других сервисов в той же подсети. Атакующий ищет базы данных со слабыми паролями или другие уязвимые микросервисы. При этом возникает «Эффект домино» ‑ взлом одного малозначимого сервиса ведет к краже данных или компрометации других ресурсов.

Данные сценарии развития атаки показывают: защиты исключительно «на этапе сборки» уже недостаточно. В среде выполнения атака может быть остановлена, либо может быть развита злоумышленником.

Контейнер не является полноценно изолированной песочницей, это важно понимать, подходя к вопросу обеспечения безопасности рантайма.

В отличие от виртуальных машин, контейнеры:

• используют общее пространство ядра;
• изолируются за счёт namespaces и cgroups;

Контекст эксплуатации и настройки контейнера и дает ту самую границу между безопасной и уязвимой средой выполнения.

Ограничение привилегий — основа безопасности

Первым и главным этапом защиты является

• процесс повышения безопасности системы путём удаления или ограничения потенциальных уязвимостей контейнера,
• процесс уменьшения поверхности атаки за счет удаления лишних утилит,
• минимизации прав доступа процессов и настройки строгих политик изоляции от хостовой системы.

Каков «Базовый минимум» в контексте настроек и ограничения прав контейнера в среде выполнения?

• Запрет запуска от суперпользователя снижает последствия компрометации, уменьшает риск «побега» из контейнера.
• Минимизация привилегий (capabilities), отключение расширенных прав процесса в ядре (права работы с сетью или файловыми системами), которые не требуются контейнеру для выполнения его узкой задачи, хорошей практикой является начинать с полного запрета и добавлять только нужные возможности.
• Seccomp-профили — механизм фильтрации на уровне ядра Linux, который запрещает контейнеру выполнять любые системные вызовы, кроме явно разрешенных, тем самым блокируя потенциальному злоумышленнику доступ к критическим функциям операционной системы
• AppArmor / SELinux — модули безопасности ядра Linux, которые принудительно ограничивают действия контейнера (доступ к файлам, сети или железу) на основе заранее заданных политик, даже для процессов с правами root.
• Корневая файловая система — в режиме «только для чтения». Такая конфигурация позволяет блокировать возможность изменять код приложения, внедрять вредоносные скрипты или сохранять файлы эксплойтов.
• Запрет «привилегированного режима» (privileged mode). Эта мера безопасности лишает контейнер прямых прав доступа к устройствам и ядру хостовой машины, предотвращая возможность полного захвата физического сервера в случае взлома приложения.

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

Обнаружение аномалий: что если превентивных мер недостаточно

Даже при строгом ограничении привилегий остаётся риск компрометации.

Поэтому необходим второй слой защиты- runtime detection.

Что можно считать аномалией? Поведение, которое не соответствует нормальной работе приложения.

Подходы к обнаружению аномалий в среде выполнения:

• Сигнатурный (Rules-based) анализ. Он основан на сравнении текущих событий в системе с заранее заданным набором правил, описывающих известное вредоносное поведение или запрещенные действия (запуск curl, попытка записи в /etc/shadow, открытие нестандартного порта и так далее). Данный подход дает минимальное количество ложных срабатываний на известные угрозы, и позволяет детектировать атаки в реальном времени. Однако он бессилен против новых, неизвестных атак (нулевого дня).
• Поведенческий (baseline) — метод обнаружения аномалий, при котором система сначала изучает «нормальную» активность приложения (при этом создается эталонный профиль приложения), после обучения блокируются все действия, не подходящие под эталон. Система изучает нормальное поведение и реагирует на отклонения. Данный подход эффективен против неизвестных ранее атак. Эталон приложения в зависимости от инструмента часто строится автоматически в процессе обучения. Сложностью является необходимость частой перенастройки в случаях обновлений или изменений внутренней логики, а также необходимое время на создание эталона.
• Мониторинг на уровне ядра (Extended Berkeley Packet Filter, eBPF) — самый современный и глубокий подход к безопасности среды выполнения позволяет отслеживать каждое действие приложения напрямую через ядро Linux, не внедряя агентов внутрь контейнеров. Подход дает глубокую видимость, видно не только то, что делает процесс, но и как он это делает. eBPF-программы выполняются внутри ядра крайне быстро, не создавая чрезмерной нагрузки на систему. Технология позволяет сопоставлять низкоуровневые системные вызовы с конкретными подами, неймспейсами и сервисами, обеспечивая глубокое понимание контекста.

Важно помнить, что невозможно предусмотреть все атаки на этапах проектирования и разработки, но можно обнаружить аномальное поведение в среде выполнения и пресечь его.

Реагирование, что делать при обнаружении атаки?

Многие системы останавливаются на выявлении атаки, ограничиваясь сообщениями об обнаружении (алертами).

Это серьёзная ошибка, ведь алерт о событии сам по себе не останавливает атаку. Регистрация факта атаки, без реагирования системы — просто запись о компрометации.

Выделим возможные сценарии реагирования на инциденты:

• Уведомление (alerting), минимальный уровень, дает сигнал команде о наличии аномального поведения.
• Автоматическое реагирование, сценарий для предотвращения дальнейших действий потенциального злоумышленника (остановка контейнера, блокировка процесса, удаление pod). Обеспечение изоляции контейнера (ограничение сетевого доступа, помещение узла в карантин). Форензика (сохранение состояния контейнера и сбор артефактов для анализа).

Реагирование на аномалии поведения важно автоматизировать, и вот почему это важно. Атаки развиваются быстро и человек часто не успевает отреагировать вовремя.

Поэтому реакция должна быть автоматизированной, встроенной в механизмы оркестратора (kubernetes) через контроллеры и политики. По возможности интегрирована с SIEM/SOAR инструментами.

Подведение итогов

Безопасность контейнеров не заканчивается на этапе сборки образа.

Атаки происходят в среде выполнения — и именно там решается, будет ли инцидент локализован или приведёт к компрометации всей системы.

Эффективная защита строится на трёх элементах:

• ограничение привилегий;
• обнаружение аномалий;
• реагирование.

Отсутствие любого из них делает защиту неполной.

В современных инфраструктурах вопрос уже не в том, произойдёт ли атака, а в том, насколько быстро и эффективно система сможет на неё отреагировать. Именно поэтому защита среды выполнения является таким же важным этапом, как и другие проверки безопасности, встроенные в конвейер разработки.

Андрей Быстров, эксперт отдела безопасной разработки Angara Security.