Falco: мониторинг контейнеров в реальном времени

Trivy и syft проверяют образ до запуска. Falco — для другой задачи: он наблюдает за реально работающими контейнерами через системные вызовы ядра и поднимает тревогу на подозрительное поведение в момент, когда оно происходит, а не при следующем сканировании.

Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена Falco (официальный образ) на тестовом хосте, после неё контейнеры удалены.

Что должно получиться

Уровень	Что это значит на практике
2. Гигиенический	Подозрительное поведение внутри работающих контейнеров (чтение чувствительных файлов, неожиданный интерактивный доступ) обнаруживается в момент события, а не постфактум по журналам приложения

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Как это работает

Falco перехватывает системные вызовы на уровне ядра (через eBPF) и сверяет их с набором готовых правил — у него их несколько сотен «из коробки», написанных сообществом под типовые подозрительные действия: чтение /etc/shadow, запуск интерактивного шелла внутри контейнера, запись в системные каталоги, попытки повышения привилегий. В отличие от журналов самого приложения, Falco видит действие независимо от того, пишет ли само приложение об этом в свой журнал.

Запуск

docker run -d --name falco --privileged \
  -v /var/run/docker.sock:/host/var/run/docker.sock \
  -v /proc:/host/proc:ro \
  -v /sys/kernel/btf:/sys/kernel/btf:ro \
  -v /boot:/host/boot:ro \
  -v /lib/modules:/host/lib/modules:ro \
  -v /usr:/host/usr:ro \
  -v /etc:/host/etc:ro \
  falcosecurity/falco:latest

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

Результат проверки

На тестовом контейнере Alpine без специальных прав (--cap-drop=ALL) выполнены два действия, каждое проверяет своё готовое правило:

Действие	Сработавшее правило	Поля события
`cat /etc/shadow` внутри контейнера	Read sensitive file untrusted	`file=/etc/shadow`, `process=cat`, `container_name=` имя тестового контейнера

Запись события включает имя контейнера, процесс, полный путь к файлу и дерево родительских процессов — достаточно, чтобы сразу понять, что произошло и в каком контейнере, без дополнительного разбора. Это тот же класс события, что в статье про проверку auditd тестом Atomic Red Team T1003.008 — там обнаружение происходит на уровне хоста через auditd, здесь — на уровне контейнерного движка через Falco; оба способа дополняют друг друга, а не заменяют.

Порядок внедрения

Предупредите команду перед первым запуском на общем хосте — Falco увидит все контейнеры, не только целевые.
Начните со встроенных правил, не пишите свои с первого дня — готовый набор уже покрывает частые случаи.
Настройте вывод в вашу систему журналирования (Falco умеет отправлять события по HTTP, в Kafka, в файл) — не оставляйте события только в консольном выводе контейнера.
Разберите первую неделю находок и добавьте исключения для легитимных действий, которые ложно совпадают с правилами (например, сервисный процесс, которому действительно нужно читать файл, помеченный как чувствительный).
Добавляйте собственные правила только после того, как освоились со встроенными — язык правил Falco позволяет описывать специфичные для вашей инфраструктуры сценарии.

Диагностика

Симптом	Причина и что делать
В журнале много предупреждений о сторонних сервисах	Falco по умолчанию видит весь хост. Это ожидаемо; фильтруйте вывод по контейнеру, который действительно проверяете
Предупреждения `failed to create tracepoint` в журнале запуска	Частичное ограничение механизма дополнительной защиты (TOCTOU) в вложенной или ограниченной среде выполнения. Само обнаружение продолжает работать, сообщение информационное
Ожидаемое действие не поймано правилом	Нет подходящего встроенного правила под конкретный случай. Проверьте список правил (`falco --list`) и, если нужно, напишите собственное
Слишком много срабатываний по легитимным действиям	Типичная настройка: добавьте исключение в конкретное правило для вашего легитимного процесса, не отключайте правило целиком

Ограничения

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

Где это в модели зрелости

Материал относится к направлению «Мониторинг кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует обнаружения значимых событий безопасности в момент, когда они происходят: для контейнерных нагрузок Falco закрывает эту задачу там, где обычные журналы приложения могут не фиксировать подозрительное действие вовсе.

Как проверить

Falco развёрнут и выводит события в общую систему журналирования, не только в консоль контейнера.
Тестовое действие (например, чтение файла с паролями) корректно обнаруживается встроенным правилом.
Команда предупреждена, что Falco видит весь хост, а не только целевые контейнеры.
Ложные срабатывания на легитимные процессы разобраны и закрыты точечными исключениями, а не отключением правил целиком.