Falco staat bekend als hulpmiddel voor Kubernetes, en vrijwel alle handleidingen erover zijn voor clusters geschreven. Toch is het niet aan clusters gebonden: het volgt systeemaanroepen, en op een gewone server met een site werkt dat precies zo. Alleen schrijft vrijwel niemand over dat geval.

Nuttig is het daar waar de andere hulpmiddelen zwijgen. Een webshell op een site schendt geen enkel recht, veroorzaakt geen mislukte aanmeldingen en komt met geen enkele handtekening overeen als hij met de hand is geschreven. Maar hij vertoont gedrag dat voor een webserver abnormaal is: het PHP-FPM-proces start een shell. Dat is wat Falco ziet.

Wat het opmerkt

Typische gebeurtenissen op een gewone server:

  • een shell voortgebracht door het proces van de webserver of van PHP — vrijwel een ondubbelzinnig teken van een webshell;
  • een programma gestart vanuit /tmp, /dev/shm of /var/tmp;
  • gevoelige bestanden (/etc/shadow, privésleutels) gelezen door een proces dat daar niets mee te maken heeft;
  • wijziging van systeembinaries;
  • een uitgaande verbinding vanuit een proces dat het netwerk niet zou moeten gebruiken.

Installatie

De beslissende keuze valt bij de installatie: hoe Falco aan de systeemaanroepen komt. De moderne variant berust op eBPF en vergt noch het bouwen van een kernelmodule noch kernelheaders:

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

De klassieke kernelmodule heeft headers nodig en wordt na elke kernelupdate opnieuw gebouwd — op een server waar updates zichzelf installeren is dat een terugkerende bron van een dode dienst. Is de kernel recent genoeg (5.8 en hoger), kies dan eBPF en vergeet het probleem.

Ter controle dat er werkelijk gebeurtenissen binnenkomen:

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

De ruis en hoe u die wegneemt

Dat is het eigenlijke werk. De meegeleverde regelset mikt op containeromgevingen, en op een gewone server is een aanzienlijk deel daarvan óf niet van toepassing óf gaat het voortdurend af.

De meegeleverde regels (/etc/falco/falco_rules.yaml) worden niet bewerkt: het bestand wordt bij een update vervangen. Uw wijzigingen komen in /etc/falco/falco_rules.local.yaml, en daar worden ook overbodige regels uitgezet:

- rule: Terminal shell in container
  enabled: false

Wat er doorgaans moet worden bijgesteld op een server zonder containers:

  • alle containerregels — zonder containers nemen ze alleen ruimte in het rapport in;
  • «Write below etc» — gaat af bij elke pakketinstallatie en bij elke wijziging van u aan een configuratiebestand. Er is een uitzondering nodig voor apt, dpkg en unattended-upgrades, anders komen de gebeurtenissen in stromen binnen;
  • «Read sensitive file untrusted» — gaat af bij bewakingsagenten, back-uphulpmiddelen en audithulpmiddelen als Lynis;
  • starts vanuit tijdelijke mappen — legitieme uitzonderingen bestaan: het bouwen van een toepassing, of een geautomatiseerde browser die een stuurprogramma in een tijdelijke map uitpakt. Zulke gebeurtenissen ogen verontrustend maar laten zich verklaren, en het loont meteen een uitzondering voor het concrete pad te maken in plaats van het elke keer opnieuw uit te zoeken.

De verstandige volgorde is dezelfde als bij elk ander detectiehulpmiddel: de eerste week alleen kijken en uitzonderingen aanleggen, en pas daarna een opgedoken gebeurtenis als signaal behandelen. De regel is eenvoudig — bevat het rapport regelmatig gebeurtenissen die u niet leest, dan heeft het geen nut.

Waar de gebeurtenissen heen moeten

De uitvoer wordt in /etc/falco/falco.yaml ingesteld: een bestand, het systeemjournaal of doorgeven aan een extern programma. Voor één server volstaat een bestand met rotatie erachteraan — vergeet de rotatie niet, het gebeurtenissenbestand groeit als elk logboek en standaard let niemand erop.

De prioriteiten zijn het waard om mee te scheiden: kritieke gebeurtenissen daar waar u ze meteen ziet, de rest in het algemene journaal om later door te nemen.

Falco en auditd zijn niet hetzelfde

Beide volgen systeemaanroepen, maar met verschillende doelen. auditd legt vast wat er gebeurt zodat het beeld later kan worden gereconstrueerd: het beoordeelt niets en meldt niets, het houdt een journaal bij. Falco past regels toe op het moment van de gebeurtenis en zegt «dit oogt verdacht» — het geeft dus een signaal in plaats van een record.

Beide draaien is verstandig: het journaal voor de reconstructie, de signalen voor de reactie. Moet u er één kiezen, dan is auditd nuttiger op een server waar het vooral aankomt op het reconstrueren van de volgorde van gebeurtenissen na een incident; Falco daar waar u een vroeg signaal wilt over een draaiende miner of een webshell.

Is het de ruimte waard op een kleine server

Het eerlijke antwoord: niet altijd. Falco verwerkt systeemaanroepen en is op een belaste machine merkbaar in de processor. Draait er op de server één site en hebt u nog integriteitscontrole noch fatsoenlijke automatische updates, dan is dit niet waar u begint.

Zijn moment komt later — wanneer de basis staat en de vraag overblijft wat er op de server gebeurt dat de logboeken niet tonen. Eén klasse gebeurtenissen dekt het beter dan alle andere samen: een shell gestart door het proces van de webserver. Hoe de gebeurtenissen uitgesplitst naar prioriteit en regel ogen, toont de demopagina hieronder.