Falco известен как инструмент для Kubernetes, и почти все руководства по нему написаны для кластеров. Между тем к кластерам он не привязан: это наблюдение за системными вызовами, и на обычном сервере с сайтом оно работает точно так же. Просто про этот сценарий мало кто пишет.

Полезен он там, где остальные инструменты молчат. Веб-шелл на сайте не нарушает прав доступа, не создаёт неудачных входов и не срабатывает по сигнатуре, если написан вручную. Но у него есть поведение, которое для веб-сервера ненормально: процесс PHP-FPM запускает оболочку. Falco видит именно это.

Что он замечает

Типичные события на обычном сервере:

  • оболочка, порождённая процессом веб-сервера или PHP — практически однозначный признак веб-шелла;
  • запуск программы из /tmp, /dev/shm или /var/tmp;
  • чтение чувствительных файлов (/etc/shadow, приватные ключи) процессом, которому это не положено;
  • изменение системных двоичных файлов;
  • исходящее соединение от процесса, который сетью пользоваться не должен.

Установка

Ключевой выбор делается при установке — каким способом Falco получает системные вызовы. Современный вариант основан на eBPF и не требует ни сборки модуля ядра, ни заголовков:

sudo falcoctl driver config --type modern_ebpf
sudo systemctl restart falco

Классический модуль ядра требует заголовков и пересобирается после каждого обновления ядра — на сервере, где обновления ставятся автоматически, это регулярный источник неработающей службы. Если ядро достаточно свежее (5.8 и выше), выбирайте eBPF и забудьте про эту проблему.

Проверка, что события действительно поступают:

sudo systemctl status falco
sudo journalctl -u falco -n 50

Шум и как его убрать

Это основная работа. Стандартный набор правил рассчитан на контейнерную среду, и на обычном сервере значительная его часть либо неприменима, либо срабатывает постоянно.

Правила из поставки (/etc/falco/falco_rules.yaml) не редактируют — файл заменяется при обновлении. Свои изменения кладутся в /etc/falco/falco_rules.local.yaml, и там же отключаются лишние:

- rule: Terminal shell in container
  enabled: false

Что обычно приходится править на сервере без контейнеров:

  • все правила про контейнеры — если контейнеров нет, они лишь занимают место в отчёте;
  • «Write below etc» — срабатывает при каждой установке пакета и при любой вашей правке конфигурации. Нужно исключение для apt, dpkg и unattended-upgrades, иначе события пойдут потоком;
  • «Read sensitive file untrusted» — срабатывает на агентах мониторинга, резервного копирования и на инструментах аудита вроде Lynis;
  • запуск из временных каталогов — законные исключения бывают: сборка приложения, автоматизированный браузер, который распаковывает драйвер во временный каталог. Такие срабатывания выглядят тревожно, но объясняются, и исключение для конкретного пути стоит завести сразу, чтобы не разбираться каждый раз заново.

Разумный порядок тот же, что и с любым другим инструментом обнаружения: первую неделю только смотреть и заводить исключения, и лишь потом относиться к появившемуся событию как к сигналу. Правило простое — если в отчёте регулярно есть события, которые вы не читаете, толку от него нет.

Куда девать события

В /etc/falco/falco.yaml настраивается вывод: файл, системный журнал или передача внешней программе. Для одного сервера достаточно файла с последующей ротацией — не забудьте про неё, файл событий растёт так же, как любой лог, и по умолчанию за ним никто не следит.

Приоритеты (priority) стоит использовать для разделения: критические события — туда, где вы их увидите сразу, остальное — в общий журнал для разбора.

Falco и auditd: не одно и то же

Оба следят за системными вызовами, но с разными целями. auditd записывает происходящее, чтобы потом можно было восстановить картину: он ничего не оценивает и не сообщает, он ведёт журнал. Falco применяет правила в момент события и говорит «вот это подозрительно» — то есть даёт сигнал, а не запись.

Держать оба разумно: журнал для разбора и сигналы для реакции. Если выбирать один, то на сервере, где важнее восстановить последовательность событий после происшествия, полезнее auditd; там, где нужен ранний сигнал о запущенном майнере или веб-шелле, — Falco.

Стоит ли он места на маленьком сервере

Честный ответ: не всегда. Falco обрабатывает системные вызовы и на нагруженной машине заметен по процессору. Если сервер держит один сайт, а из инструментов пока нет ни контроля целостности, ни нормальных автообновлений, начинать надо не с него.

Его момент наступает позже — когда базовые вещи уже сделаны, и остаётся вопрос: что происходит на сервере такого, чего не видно в логах. Один класс событий он закрывает лучше всех остальных вместе взятых — оболочка, запущенная процессом веб-сервера. Как выглядят события с разбивкой по приоритетам и правилам — на странице демо ниже.