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: файл, системний журнал або передавання зовнішній програмі. Для одного сервера вистачить файла з подальшою ротацією — про ротацію не забудьте, файл подій росте, як і будь-який інший журнал, і типово за ним ніхто не стежить.

Пріоритети варто використовувати для розділення: критичні події йдуть туди, де ви побачите їх одразу, решта — у загальний журнал для подальшого розбору.

Falco і auditd — не те саме

Обидва стежать за системними викликами, але з різною метою. auditd записує те, що відбувається, щоб картину можна було відновити пізніше: він нічого не оцінює й ні про що не повідомляє, він веде журнал. Falco застосовує правила в момент події й каже «це має підозрілий вигляд» — тобто дає сигнал, а не запис.

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

Чи вартий він місця на невеликому сервері

Чесна відповідь: не завжди. Falco обробляє системні виклики й помітний на процесорі завантаженої машини. Якщо на сервері один сайт, а в вас досі немає ні контролю цілісності, ні пристойних автоматичних оновлень, починати треба не з нього.

Його час настає пізніше — коли базове зроблено й лишається питання, що на сервері відбувається такого, чого журнали не показують. Один клас подій він закриває краще, ніж усі інші разом: оболонку, запущену процесом вебсервера. Який вигляд мають події, розділені за пріоритетом і правилом, показує демосторінка нижче.