Falco este cunoscut ca instrument pentru Kubernetes, iar aproape toate ghidurile despre el sunt scrise pentru clustere. Între timp, nu este legat de clustere: este vorba despre urmărirea apelurilor de sistem, iar pe un server obișnuit cu un site funcționează exact la fel. Doar că despre acest scenariu scriu puțini.

Este util acolo unde celelalte instrumente tac. Un webshell de pe site nu încalcă drepturi de acces, nu creează autentificări eșuate și nu se declanșează după semnătură dacă a fost scris manual. Are însă un comportament anormal pentru un server web: procesul PHP-FPM pornește un shell. Exact asta vede Falco.

Ce observă

Evenimente tipice pe un server obișnuit:

  • un shell generat de procesul serverului web sau de PHP — practic un semn fără echivoc de webshell;
  • pornirea unui program din /tmp, /dev/shm sau /var/tmp;
  • citirea fișierelor sensibile (/etc/shadow, chei private) de către un proces căruia nu i se cuvine;
  • modificarea fișierelor binare de sistem;
  • o conexiune ieșită de la un proces care nu ar trebui să folosească rețeaua.

Instalare

Alegerea-cheie se face la instalare — prin ce mod obține Falco apelurile de sistem. Varianta modernă se bazează pe eBPF și nu cere nici compilarea unui modul de nucleu, nici fișiere antet:

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

Modulul clasic de nucleu cere fișiere antet și se recompilează după fiecare actualizare de nucleu — pe un server unde actualizările se instalează automat, aceasta este o sursă regulată de serviciu nefuncțional. Dacă nucleul este suficient de recent (5.8 și mai nou), alege eBPF și uită de această problemă.

Verificarea că evenimentele sosesc cu adevărat:

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

Zgomotul și cum scapi de el

Aceasta este munca principală. Setul standard de reguli este gândit pentru medii cu containere, iar pe un server obișnuit o parte considerabilă din el fie nu se aplică, fie se declanșează permanent.

Regulile din pachet (/etc/falco/falco_rules.yaml) nu se editează — fișierul este înlocuit la actualizare. Modificările proprii se pun în /etc/falco/falco_rules.local.yaml, iar tot acolo se dezactivează cele de prisos:

- rule: Terminal shell in container
  enabled: false

Ce trebuie de obicei corectat pe un server fără containere:

  • toate regulile despre containere — dacă nu există containere, ele doar ocupă loc în raport;
  • „Write below etc” — se declanșează la fiecare instalare de pachet și la orice modificare de configurație făcută de tine. Este nevoie de o excepție pentru apt, dpkg și unattended-upgrades, altfel evenimentele vor curge în flux;
  • „Read sensitive file untrusted” — se declanșează la agenții de monitorizare și de copiere de rezervă și la instrumentele de audit precum Lynis;
  • pornirea din directoare temporare — excepții legitime există: compilarea unei aplicații, un browser automatizat care despachetează un driver într-un director temporar. Astfel de declanșări par îngrijorătoare, dar se explică, iar o excepție pentru calea concretă merită creată imediat, ca să nu reiei analiza de fiecare dată.

Ordinea rezonabilă este aceeași ca la orice alt instrument de detecție: prima săptămână doar urmărești și creezi excepții, și abia apoi tratezi un eveniment nou ca pe un semnal. Regula este simplă — dacă în raport apar regulat evenimente pe care nu le citești, nu ai niciun folos de la el.

Unde se trimit evenimentele

În /etc/falco/falco.yaml se configurează ieșirea: fișier, jurnal de sistem sau transmitere către un program extern. Pentru un singur server este suficient un fișier cu rotația aferentă — nu o uita, fișierul de evenimente crește ca orice jurnal, iar implicit nu îl supraveghează nimeni.

Prioritățile (priority) merită folosite pentru separare: evenimentele critice acolo unde le vei vedea imediat, restul într-un jurnal general pentru analiză.

Falco și auditd nu sunt același lucru

Amândouă urmăresc apeluri de sistem, dar cu scopuri diferite. auditd înregistrează ce se întâmplă, ca tabloul să poată fi reconstituit ulterior: nu evaluează nimic și nu anunță, ține un jurnal. Falco aplică reguli în momentul evenimentului și spune „asta este suspect” — adică dă un semnal, nu o înregistrare.

Este rezonabil să le ai pe amândouă: jurnalul pentru analiză și semnalele pentru reacție. Dacă trebuie ales unul, atunci pe un server unde este mai important să reconstitui succesiunea evenimentelor după un incident este mai util auditd; acolo unde este nevoie de un semnal timpuriu despre un miner pornit sau un webshell, este Falco.

Merită locul pe un server mic

Răspunsul onest: nu întotdeauna. Falco prelucrează apeluri de sistem și se simte pe procesor pe o mașină încărcată. Dacă serverul ține un singur site, iar dintre instrumente încă nu există nici control al integrității, nici actualizări automate ca lumea, nu cu el trebuie început.

Momentul lui vine mai târziu — când lucrurile de bază sunt deja făcute și rămâne întrebarea: ce se întâmplă pe server dintre cele care nu se văd în jurnale. O clasă de evenimente o acoperă mai bine decât toate celelalte la un loc — un shell pornit de procesul serverului web. Cum arată evenimentele împărțite pe priorități și reguli arată pagina demonstrativă de mai jos.