Контейнерные среды меняются быстро: новые образы разворачиваются автоматически, конфигурации обновляются в CI/CD-пайплайнах. Без непрерывной инвентаризации вы не знаете, что именно запущено прямо сейчас: какой образ, с каким дайджестом, из какого реестра, с какими привилегиями.
На практике это означает, что небезопасная конфигурация или неподконтрольный образ могут месяцами работать незамеченными в вашей инфраструктуре. И позднее, когда возникнет инцидент или аудит, придется выяснять вручную, какие контейнеры были запущены и соответствуют ли они вообще требованиям безопасности.
Автоматическая инвентаризация позволяет превратить эту информацию в события мониторинга и получать уведомления сразу же после появления, например, «рискованных» конфигураций.
На связи Андрей, руководитель направления безопасности облака в Selectel . Ранее я рассказывал про сам инструмент Wazuh и его функциональность , а в этой статье покажу пример использования механизма wodle command на практической задаче.
Wodle (сокращение от Wazuh module) — это модуль, который расширяет возможности агента. Он предназначен для выполнения целого ряда задач от сбора данных из внешних источников до запуска сканеров безопасности или выполнения пользовательских сценариев. Проще говоря, это легковесный «плагин» к агенту Wazuh. Он работает в фоновом режиме, выполняет свою задачу, а результаты в виде логов отправляет менеджеру для дальнейшего анализа
Wodle (сокращение от Wazuh module) — это модуль, который расширяет возможности агента. Он предназначен для выполнения целого ряда задач от сбора данных из внешних источников до запуска сканеров безопасности или выполнения пользовательских сценариев.
Проще говоря, это легковесный «плагин» к агенту Wazuh. Он работает в фоновом режиме, выполняет свою задачу, а результаты в виде логов отправляет менеджеру для дальнейшего анализа
Вкратце об архитектуре решения
Схема потока данных выглядит так: скрипт запускается агентом Wazuh по расписанию, обращается к Docker CLI и выводит JSON в stdout. Wazuh перехватывает вывод и отправляет его менеджеру в виде отдельных событий.
Рассказываем о лучших практиках и средствах ИБ, требованиях и изменениях в законодательстве.
Шаг 1. Скрипт инвентаризации
Перейдем к самому скрипту. Он совместим с любым окружением Linux. Сохраните его по пути /var/ossec/custom-scripts/container_ inventory.sh и выдайте права на исполнение.
Установка прав:
Шаг 2. Конфигурация Wazuh-агента (wodle command)
На узле, где установлен Wazuh-агент, откройте файл /var/ossec/etc/ossec.conf и добавьте в секцию <ossec_config> следующий блок конфигурации:
Здесь механизм wodle command запускает произвольные команды по расписанию и перехватывает их вывод как события Wazuh.
После изменения конфигурации перезапустите Wazuh-агента:
Структура событий
Прежде чем приступить к настройке правил алертинга важно отметить, что строка вывода скрипта — это отдельное JSON-событие. Рассмотрим пример такого события:
Ниже для удобства привожу «шпаргалку» с описанием полей и их типами.
Интерес для ИБ
name
string
Имя контейнера
Позволяет быстро определить, какой сервис связан с событием безопасности. Упрощает расследование подозрительной сетевой активности и анализ инцидентов.
repo
string
Имя образа без тега
Используется для контроля происхождения образов и инвентаризации контейнерной среды. Появление образов из неутвержденных репозиториев может указывать на нарушение процессов поставки ПО.
tag
string
Тег образа. latest, если не задан
Помогает отслеживать версии приложений и сопоставлять их с известными уязвимостями. Использование latest усложняет аудит и воспроизводимость развертываний.
registry
string
Источник образа (docker.io, local, свой реестр)
Позволяет контролировать использование доверенных реестров. Образы из внешних или неавторизованных источников требуют дополнительной проверки.
privileged
bool
Признак запуска в привилегированном режиме
Один из наиболее важных признаков риска. Привилегированный контейнер получает расширенный доступ к ресурсам хоста и существенно увеличивает последствия возможной компрометации.
user
string
Пользователь внутри контейнера
Помогает проверить соблюдение принципа минимальных привилегий. Запуск процессов от root повышает риск развития атаки после получения доступа к контейнеру.
c ap_add
array
Добавленные Linux-привилегии (capabilities)
Позволяет выявить контейнеры с расширенными системными возможностями. Особое внимание стоит уделять CAP_SYS_ADMIN , CAP_SYS_PTRACE и другим привилегированным capabilities.
cap_drop
array
Отозванные capabilities
Показывает, какие возможности были дополнительно ограничены. Наличие ALL обычно свидетельствует о более строгой конфигурации безопасности контейнера.
digest
string
SHA256-дайджест манифеста. N/A — для локальных образов
Позволяет однозначно идентифицировать конкретную версию образа. Полезен для контроля целостности и выявления неподписанных или неучтенных артефактов.
Шаг 3. Настройка правил алертинга в Wazuh
Добавьте правила в /var/ossec/etc/rules/local_rules.xml на менеджере. Wazuh декодирует JSON-поля автоматически через динамический декодер.
В примере ниже используются несколько простых правил, которые позволяют выявлять наиболее распространенные проблемы: запуск привилегированных контейнеров, использование тега latest, работу от root и применение локальных образов без подтвержденного источника.
Шаг 4. Поиск событий в Wazuh Dashboards
После настройки правил полезно проверить, какие данные поступают в индекс и как они выглядят в поиске. Проще всего сделать это через Discover в Wazuh Dashboards. Ниже привожу несколько запросов, которые помогают быстро выявить потенциально рискованные контейнеры и проверить качество инвентаризации.
Например, запрос по привилегированным контейнерам позволяет быстро выявить сервисы с повышенными правами на хосте. Поиск образов не из корпоративного реестра помогает контролировать происхождение контейнеров и обнаруживать отклонения от вашей принятой политики.
Рекомендации по безопасности
На основе данных инвентаризации вы можете сразу улучшить конфигурацию контейнеров. Рассмотрим снова на примере небольшой «шпаргалки».
privileged: true
Контейнер имеет полный доступ к хосту
Убрать --privileged , заменить на конкретные capabilities
user: root
Эскалация при побеге из контейнера
Добавить USER в Dockerfile или --user при запуске
tag: latest
Непредсказуемые обновления, нет проверки целостности
Использовать фиксированные теги или digest-ссылки
registry: local
Образ создан вручную, нет аудит-следа
Пушить все образы в корпоративный реестр со сканированием
cap_add: [NET_ADMIN]
Возможность изменить сетевые настройки хоста
Добавить cap_drop: ALL + только необходимые capabilities
Эти проверки не заменяют анализ образов на этапе CI/CD, но позволяют быстро выявить отклонения в уже работающей инфраструктуре. На практике наиболее полезными обычно оказываются контроль привилегированных контейнеров, запуска от root и использования неподконтрольных образов.
Расширение скрипта
Базовый вариант собирает только сведения об образе и привилегиях контейнера. При необходимости вы можете дополнить его данными о сетевых настройках, точках монтирования и окружении процесса. Предлагайте в комментариях, какие пути расширения видите — будет интересно обсудить.
Порты и сетевые настройки
Информация о проброшенных портах и сетевом режиме помогает выявлять сервисы с неожиданной сетевой доступностью или использованием host-сети.
Смонтированные volumes
Данные о монтированиях полезны для поиска контейнеров с доступом к чувствительным каталогам хоста.
Переменные среды (с маскированием секретов)
Переменные окружения могут содержать секреты и параметры подключения к внешним системам, поэтому их сбор требует дополнительной осторожности.
Внимание! Не логируйте переменные среды без маскирования — они часто содержат токены, пароли и ключи API, которые могут попасть в индекс Wazuh и стать видимыми в дашборде.
Внимание! Не логируйте переменные среды без маскирования — они часто содержат токены, пароли и ключи API, которые могут попасть в индекс Wazuh и стать видимыми в дашборде.
Таймаут на большом количестве контейнеров
При 50+ контейнерах вызовы docker inspect могут занять больше 60 секунд. Увеличьте значение <timeout> в конфиге или оптимизируйте скрипт, объединив несколько inspect-вызовов в один.
Что в итоге
С помощью wodle command можно быстро расширить возможности Wazuh и собирать данные, которые отсутствуют в стандартной поставке агента. В рассмотренном примере мы настроили инвентаризацию контейнеров и превратили сведения об образах, привилегиях и настройках безопасности в события мониторинга и алерты.
Такой подход не заменяет проверку образов на этапе CI/CD и сканирование уязвимостей до развертывания, но помогает контролировать фактическое состояние контейнерной среды. Это особенно полезно в динамичной инфраструктуре, где контейнеры регулярно пересоздаются, обновляются или запускаются из разных пайплайнов.
При необходимости аналогичный механизм можно адаптировать для Podman, CRI-O или других контейнерных рантаймов, а сам скрипт дополнить сбором сетевых настроек, томов и других параметров, важных для вашей модели угроз. Если вы используете Wazuh для мониторинга контейнеров или собираете похожую инвентаризацию другими способами — расскажите в комментариях, какие проверки оказались наиболее полезными в вашей инфраструктуре.
Снижаем цены на выделенные серверы в реальном времени
Успейте арендовать со скидкой до 35%, пока лот не ушел другому.