Настройка Runtime Security для контейнеров (Falco)

Runtime-безопасность контейнеров с Falco

Сканирование образов при сборке — необходимо, но недостаточно. Если атакующий получил shell внутри пода через уязвимость в приложении, статический скан это не остановит. Falco работает в рантайме: он мониторит системные вызовы на уровне ядра и сигнализирует, когда что-то идёт не так — например, когда nginx-процесс вдруг вызывает execve("/bin/bash"). По данным IBM Cost of a Data Breach Report, средняя стоимость утечки данных в облаке составляет $4.24 млн — и runtime-безопасность критична для предотвращения таких инцидентов. Время простоя критических приложений может стоить $5 000 в час.

Представьте: вы используете образ node:14-alpine, и через RCE в Express злоумышленник запускает reverse shell. Никакой статический анализатор не предупредит — только runtime-мониторинг. Мы настраиваем Falco под ключ за 1-3 дня, включая тюнинг правил под ваш стек. Клиенты отмечают снижение времени реагирования на инциденты (MTTR) на 40%, что даёт существенную экономию.

Как Falco обнаруживает аномалии на уровне ядра?

Falco перехватывает события через kernel module или eBPF-пробу. В Kubernetes-кластерах предпочтительный вариант — eBPF, потому что не требует загрузки kernel module (что часто запрещено на managed-нодах типа GKE, EKS). С Falco 0.35+ появился режим modern eBPF, работающий без отдельного probe-компилятора.

Развёртывание через Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/..." \
  --set falcosidekick.config.slack.minimumpriority=warning

Falco DaemonSet запускается на каждой ноде — это важно, т.к. eBPF-пробы привязаны к конкретному ядру.

Почему eBPF предпочтительнее kernel module?

Современный eBPF в 2 раза быстрее legacy eBPF по данным бенчмарков. Наша команда использует его в 90% проектов.

Типичные проблемы, которые решает Falco

• Запуск shell в production-контейнере — самый частый сценарий атаки после эксплуатации уязвимости. Falco детектирует вызов execve с bash/sh сразу.
• Изменение конфигурационных файлов — запись в /etc, /var/run/secrets и другие чувствительные директории. Правило Write below etc срабатывает, но требует тюнинга под легитимные init-контейнеры.
• Сетевая эксфильтрация — запуск curl/wget/nc внутри контейнера для отправки данных наружу. Кастомное правило ниже ловит такие действия.

Кастомное правило для обнаружения запуска curl/wget внутри production-контейнеров:

# /etc/falco/rules.d/custom-rules.yaml
- rule: Unexpected outbound HTTP from container
  desc: Detects curl/wget execution inside containers
  condition: >
    spawned_process and container and proc.name in (curl, wget, nc, ncat) and not proc.pname in (package-manager, apt-get, yum)
  output: >
    Outbound HTTP tool in container (user=%user.name command=%proc.cmdline container=%container.name image=%container.image.repository)
  priority: WARNING
  tags: [container, network, mitre_exfiltration]

Правила применяются без перезапуска Falco — через falco --list можно проверить активные.

Falcosidekick — маршрутизация алертов

Сам Falco пишет события в stdout/syslog. Для нормальной работы нужен Falcosidekick — он принимает события и роутит их в Slack, Telegram, PagerDuty, Elasticsearch, Loki, Kafka, webhook. Конфигурация через values.yaml:

falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/..."
      minimumpriority: "warning"
    elasticsearch:
      hostport: "http://elasticsearch:9200"
      index: "falco-events"
      minimumpriority: "notice"
    loki:
      hostport: "http://loki:3100"

На практике полезно дублировать Critical-события в Slack и в Elasticsearch/Loki — для оперативного реагирования и для построения графиков в Grafana по частоте инцидентов.

Что входит в настройку Falco

1. Аудит кластера — проверка совместимости ядер (kernel ≥ 5.8 для modern eBPF), анализ текущих политик безопасности.
2. Развёртывание Falco — установка DaemonSet через Helm с выбором оптимального драйвера (eBPF / modern eBPF).
3. Тюнинг правил — подавление ложных срабатываний под ваш стек (имена образов, namespace, init-контейнеры).
4. Кастомные правила — написание детектов под специфику приложений (например, запрещённые утилиты, необычная сетевая активность).
5. Интеграция с алертингом — подключение Falcosidekick к Slack/PagerDuty/Loki с настройкой приоритетов.
6. Документация и обучение — инструкция по эксплуатации, runbook для реагирования на инциденты, чек-лист проверки.

Почему выбирают нас

Мы занимаемся безопасностью контейнеров более 10 лет, выполнили 50+ проектов по внедрению Falco в production. Инженеры — сертифицированные специалисты (CKS, CKAD). Предоставляем гарантию на настройку: бесплатная доработка правил в течение месяца после внедрения. Свяжитесь с нами, чтобы получить консультацию и оценить проект.

Снижение ложных срабатываний

Высокая частота ложных срабатываний — главная причина отказа от Falco в production. Стандартные правила дают до 90% false positives: например, Write below etc срабатывает на init-контейнеры, а spawned_process — на sidecar. Решение — кастомные исключения. Мы создаём правила с учётом ваших образов и namespace, оставляя только действительно опасные события. После тюнинга уровень ложных срабатываний снижается до 5-10%.

Заключение

Runtime-безопасность — обязательный слой защиты для production-кластеров. Falco с eBPF даёт видимость на уровне ядра без overhead. Закажите настройку Falco под ключ, и ваши контейнеры будут под защитой. Получите консультацию по настройке Falco для вашего кластера.