Falco je známé jako nástroj pro Kubernetes a téměř všechny návody k němu jsou psané pro clustery. Na clustery přitom vázané není: jde o sledování systémových volání a na běžném serveru s webem funguje úplně stejně. Jen o tomto scénáři píše málokdo.

Užitečné je tam, kde ostatní nástroje mlčí. Webshell na webu neporušuje přístupová práva, nevytváří neúspěšná přihlášení a nespustí signaturu, je-li napsaný ručně. Má však chování, které je pro webový server nenormální: proces PHP-FPM spouští shell. Právě to Falco vidí.

Co zachytí

Typické události na běžném serveru:

  • shell zrozený procesem webového serveru nebo PHP — prakticky jednoznačná známka webshellu;
  • spuštění programu z /tmp, /dev/shm nebo /var/tmp;
  • čtení citlivých souborů (/etc/shadow, privátní klíče) procesem, kterému to nepřísluší;
  • změna systémových binárních souborů;
  • odchozí spojení od procesu, který síť používat nemá.

Instalace

Klíčová volba padá při instalaci — jakým způsobem Falco získává systémová volání. Současná varianta stojí na eBPF a nevyžaduje ani sestavení modulu jádra, ani hlavičkové soubory:

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

Klasický modul jádra vyžaduje hlavičkové soubory a po každé aktualizaci jádra se znovu sestavuje — na serveru, kde se aktualizace instalují automaticky, je to pravidelný zdroj nefunkční služby. Je-li jádro dostatečně čerstvé (5.8 a vyšší), zvolte eBPF a na tento problém zapomeňte.

Kontrola, že události skutečně přicházejí:

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

Šum a jak se ho zbavit

To je hlavní práce. Standardní sada pravidel počítá s kontejnerovým prostředím a na běžném serveru je její značná část buď nepoužitelná, nebo se spouští neustále.

Pravidla z dodávky (/etc/falco/falco_rules.yaml) se neupravují — soubor se při aktualizaci nahrazuje. Vlastní změny se ukládají do /etc/falco/falco_rules.local.yaml a tamtéž se vypínají zbytečná:

- rule: Terminal shell in container
  enabled: false

Co obvykle bývá třeba upravit na serveru bez kontejnerů:

  • všechna pravidla o kontejnerech — pokud kontejnery nejsou, jen zabírají místo ve zprávě;
  • „Write below etc“ — spouští se při každé instalaci balíčku a při jakékoli vaší úpravě konfigurace. Je potřeba výjimka pro apt, dpkg a unattended-upgrades, jinak půjdou události proudem;
  • „Read sensitive file untrusted“ — spouští se na monitorovacích a zálohovacích agentech a na auditních nástrojích typu Lynis;
  • spouštění z dočasných adresářů — legitimní výjimky existují: sestavení aplikace, automatizovaný prohlížeč, který rozbaluje ovladač do dočasného adresáře. Taková spuštění vypadají znepokojivě, ale dají se vysvětlit, a výjimku pro konkrétní cestu je vhodné založit rovnou, aby se to nemuselo pokaždé řešit znovu.

Rozumné pořadí je stejné jako u kteréhokoli jiného detekčního nástroje: první týden jen sledovat a zakládat výjimky a teprve potom brát nově vzniklou událost jako signál. Pravidlo je jednoduché — jsou-li ve zprávě pravidelně události, které nečtete, není z ní užitek.

Kam s událostmi

V /etc/falco/falco.yaml se nastavuje výstup: soubor, systémový žurnál nebo předání externímu programu. Pro jeden server stačí soubor s následnou rotací — nezapomeňte na ni, soubor událostí roste jako každý log a ve výchozím stavu ho nikdo nehlídá.

Priority (priority) stojí za to použít k rozdělení: kritické události tam, kde je uvidíte hned, ostatní do obecného logu k rozboru.

Falco a auditd nejsou totéž

Oba sledují systémová volání, ale s odlišnými cíli. auditd zaznamenává dění, aby bylo možné později obraz zrekonstruovat: nic nehodnotí a neupozorňuje, vede deník. Falco aplikuje pravidla v okamžiku události a říká „tohle je podezřelé“ — dává tedy signál, ne záznam.

Držet oba je rozumné: deník k rozboru a signály k reakci. Je-li třeba vybrat jeden, pak na serveru, kde je důležitější zrekonstruovat sled událostí po incidentu, je užitečnější auditd; tam, kde je potřeba včasný signál o spuštěném těžaři nebo webshellu, je to Falco.

Stojí za místo na malém serveru

Poctivá odpověď: ne vždy. Falco zpracovává systémová volání a na zatíženém stroji je znát na procesoru. Pokud server drží jeden web a z nástrojů zatím není ani kontrola integrity, ani pořádné automatické aktualizace, začínat je třeba jinde.

Jeho chvíle přijde později — až jsou základní věci hotové a zbývá otázka: co se na serveru děje takového, co v logách vidět není. Jednu třídu událostí pokrývá lépe než všechny ostatní dohromady — shell spuštěný procesem webového serveru. Jak vypadají události s rozdělením podle priorit a pravidel, ukazuje ukázková stránka níže.