Инструкции (tutorials) по теме Администрирование

Зачем это нужно Контейнерные среды меняются быстро: новые образы разворачиваются автоматически, конфигурации обновляются в CI/CD-пайплайнах. Без непрерывной инвентаризации вы не знаете, что именно запущено прямо сейчас: какой образ, с каким дайджестом, из какого реестра, с какими привилегиями. На практике это означает, что небезопасная конфигурация или неподконтрольный образ могут месяцами работать незамеченными в вашей инфраструктуре. И позднее, когда возникнет инцидент или аудит, придется выяснять вручную, какие контейнеры были запущены и соответствуют ли они вообще требованиям безопасности. Автоматическая инвентаризация позволяет превратить эту информацию в события мониторинга и получать уведомления сразу же после появления, например, «рискованных» конфигураций. На связи Андрей, руководитель направления безопасности облака в Selectel. Ранее я рассказывал про сам инструмент Wazuh и его функциональность, а в этой статье покажу пример использования механизма wodle command на практической задаче. Вкратце об архитектуре решения Схема потока данных выглядит так: скрипт запускается агентом 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 и добавьте в секцию следующий блок конфигурации: Здесь механизм wodle command запускает произвольные команды по расписанию и перехватывает их вывод как события Wazuh. После изменения конфигурации перезапустите Wazuh-агента: Структура событий Прежде чем приступить к настройке правил алертинга важно отметить, что строка вывода скрипта — это отдельное JSON-событие. Рассмотрим пример такого события: Ниже для удобства привожу «шпаргалку» с описанием полей и их типами. ПолеТипОписаниеИнтерес для ИБnamestringИмя контейнераПозволяет быстро определить, какой сервис связан с событием безопасности. Упрощает расследование подозрительной сетевой активности и анализ инцидентов.repostringИмя образа без тегаИспользуется для контроля происхождения образов и инвентаризации контейнерной среды. Появление образов из неутвержденных репозиториев может указывать на нарушение процессов поставки ПО.tagstringТег образа. latest, если не заданПомогает отслеживать версии приложений и сопоставлять их с известными уязвимостями. Использование latest усложняет аудит и воспроизводимость развертываний.registrystringИсточник образа (docker.io, local, свой реестр)Позволяет контролировать использование доверенных реестров. Образы из внешних или неавторизованных источников требуют дополнительной проверки.privilegedboolПризнак запуска в привилегированном режимеОдин из наиболее важных признаков риска. Привилегированный контейнер получает расширенный доступ к ресурсам хоста и существенно увеличивает последствия возможной компрометации.userstringПользователь внутри контейнераПомогает проверить соблюдение принципа минимальных привилегий. Запуск процессов от root повышает риск развития атаки после получения доступа к контейнеру.cap_addarrayДобавленные Linux-привилегии (capabilities) Позволяет выявить контейнеры с расширенными системными возможностями. Особое внимание стоит уделять CAP_SYS_ADMIN, CAP_SYS_PTRACE и другим привилегированным capabilities.cap_droparrayОтозванные capabilitiesПоказывает, какие возможности были дополнительно ограничены. Наличие ALL обычно свидетельствует о более строгой конфигурации безопасности контейнера.digeststringSHA256-дайджест манифеста. N/A — для локальных образовПозволяет однозначно идентифицировать конкретную версию образа. Полезен для контроля целостности и выявления неподписанных или неучтенных артефактов. Шаг 3. Настройка правил алертинга в Wazuh Добавьте правила в /var/ossec/etc/rules/local_rules.xml на менеджере. Wazuh декодирует JSON-поля автоматически через динамический декодер. В примере ниже используются несколько простых правил, которые позволяют выявлять наиболее распространенные проблемы: запуск привилегированных контейнеров, использование тега latest, работу от root и применение локальных образов без подтвержденного источника. Шаг 4. Поиск событий в Wazuh Dashboards После настройки правил полезно проверить, какие данные поступают в индекс и как они выглядят в поиске. Проще всего сделать это через Discover в Wazuh Dashboards. Ниже привожу несколько запросов, которые помогают быстро выявить потенциально рискованные контейнеры и проверить качество инвентаризации. Например, запрос по привилегированным контейнерам позволяет быстро выявить сервисы с повышенными правами на хосте. Поиск образов не из корпоративного реестра помогает контролировать происхождение контейнеров и обнаруживать отклонения от вашей принятой политики. Рекомендации по безопасности На основе данных инвентаризации вы можете сразу улучшить конфигурацию контейнеров. Рассмотрим снова на примере небольшой «шпаргалки». ПроблемаРискРекомендацияprivileged: trueКонтейнер имеет полный доступ к хостуУбрать --privileged, заменить на конкретные capabilitiesuser: rootЭскалация при побеге из контейнераДобавить USER в Dockerfile или --user при запускеtag: latestНепредсказуемые обновления, нет проверки целостностиИспользовать фиксированные теги или digest-ссылкиregistry: localОбраз создан вручную, нет аудит-следаПушить все образы в корпоративный реестр со сканированиемcap_add: Возможность изменить сетевые настройки хостаДобавить cap_drop: ALL + только необходимые capabilities Эти проверки не заменяют анализ образов на этапе CI/CD, но позволяют быстро выявить отклонения в уже работающей инфраструктуре. На практике наиболее полезными обычно оказываются контроль привилегированных контейнеров, запуска от root и использования неподконтрольных образов. Расширение скрипта Базовый вариант собирает только сведения об образе и привилегиях контейнера. При необходимости вы можете дополнить его данными о сетевых настройках, точках монтирования и окружении процесса. Порты и сетевые настройки Информация о проброшенных портах и сетевом режиме помогает выявлять сервисы с неожиданной сетевой доступностью или использованием host-сети. Смонтированные volumes Данные о монтированиях полезны для поиска контейнеров с доступом к чувствительным каталогам хоста. Переменные среды (с маскированием секретов) Переменные окружения могут содержать секреты и параметры подключения к внешним системам, поэтому их сбор требует дополнительной осторожности. Таймаут на большом количестве контейнеров При 50+ контейнерах вызовы docker inspect могут занять больше 60 секунд. Увеличьте значение в конфиге или оптимизируйте скрипт, объединив несколько inspect-вызовов в один. Что в итоге С помощью wodle command можно быстро расширить возможности Wazuh и собирать данные, которые отсутствуют в стандартной поставке агента. В рассмотренном примере мы настроили инвентаризацию контейнеров и превратили сведения об образах, привилегиях и настройках безопасности в события мониторинга и алерты. Такой подход не заменяет проверку образов на этапе CI/CD и сканирование уязвимостей до развертывания, но помогает контролировать фактическое состояние контейнерной среды. Это особенно полезно в динамичной инфраструктуре, где контейнеры регулярно пересоздаются, обновляются или запускаются из разных пайплайнов. При необходимости аналогичный механизм можно адаптировать для Podman, CRI-O или других контейнерных рантаймов, а сам скрипт дополнить сбором сетевых настроек, томов и других параметров, важных для вашей модели угроз.