Налаштування 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 для вашого кластера.