Falco er kendt som et værktøj til Kubernetes, og næsten alle vejledninger om det er skrevet til klynger. Det er dog ikke bundet til klynger: det handler om overvågning af systemkald, og på en almindelig server med en hjemmeside virker det nøjagtig ligesådan. Der er blot få, der skriver om det anvendelsesområde.

Det er nyttigt der, hvor de andre værktøjer tier. En webshell på hjemmesiden overtræder ingen rettigheder, skaber ingen mislykkede logins og udløser ingen signatur, hvis den er skrevet i hånden. Men den har en adfærd, der er unormal for en webserver: PHP-FPM-processen starter en skal. Det er præcis det, Falco ser.

Hvad det opdager

Typiske hændelser på en almindelig server:

  • en skal skabt af webserverens eller PHP's proces — praktisk talt et entydigt tegn på en webshell;
  • start af et program fra /tmp, /dev/shm eller /var/tmp;
  • læsning af følsomme filer (/etc/shadow, private nøgler) af en proces, der ikke skal gøre det;
  • ændring af systemets binærfiler;
  • en udgående forbindelse fra en proces, der ikke skal bruge netværket.

Installation

Det afgørende valg træffes ved installationen — på hvilken måde Falco henter systemkaldene. Den moderne variant bygger på eBPF og kræver hverken, at et kernemodul bygges, eller at kernehoveder findes:

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

Det klassiske kernemodul kræver kernehoveder og genopbygges efter hver kerneopdatering — på en server med automatiske opdateringer er det en tilbagevendende kilde til en ødelagt tjeneste. Er kernen frisk nok (5.8 og nyere), vælg eBPF og glem det problem.

Kontrol af at hændelser rent faktisk kommer ind:

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

Støjen og hvordan du slipper af med den

Det er hovedarbejdet. Standardsættet af regler er lavet til containermiljøer, og på en almindelig server er en betydelig del af det enten ikke anvendeligt eller udløses hele tiden.

Reglerne, der følger med (/etc/falco/falco_rules.yaml), redigeres ikke — filen erstattes ved opdatering. Egne ændringer lægges i /etc/falco/falco_rules.local.yaml, og det er også der, de overflødige slås fra:

- rule: Terminal shell in container
  enabled: false

Hvad man som regel må rette på en server uden containere:

  • alle regler om containere — findes der ingen containere, optager de blot plads i rapporten;
  • »Write below etc« — udløses ved hver pakkeinstallation og ved hver konfigurationsændring, du foretager. Der er brug for en undtagelse til apt, dpkg og unattended-upgrades, ellers kommer hændelserne i en strøm;
  • »Read sensitive file untrusted« — udløses af overvågnings- og sikkerhedskopieringsagenter og af revisionsværktøjer som Lynis;
  • start fra midlertidige mapper — legitime undtagelser forekommer: bygning af en applikation, en automatiseret browser, der pakker en driver ud i en midlertidig mappe. Sådanne udslag ser foruroligende ud, men kan forklares, og en undtagelse til den bestemte sti er værd at oprette med det samme for at slippe for at udrede det samme hver gang.

Den fornuftige rækkefølge er den samme som for ethvert andet detektionsværktøj: den første uge blot se og oprette undtagelser, og først derefter behandle en ny hændelse som et signal. Reglen er enkel — findes der jævnligt hændelser i rapporten, som du ikke læser, gør den ingen nytte.

Hvor hændelserne skal havne

I /etc/falco/falco.yaml indstilles outputtet: fil, systemlog eller overlevering til et eksternt program. Til en enkelt server rækker en fil med efterfølgende rotation — glem den ikke, hændelsesfilen vokser som enhver logfil, og som standard holder ingen øje med den.

Prioriteterne (priority) er værd at bruge til opdeling: kritiske hændelser hen, hvor du ser dem med det samme, resten til en generel logfil til gennemgang.

Falco og auditd er ikke det samme

Begge overvåger systemkald, men med forskellige formål. auditd registrerer det, der sker, så billedet kan rekonstrueres bagefter: det vurderer intet og advarer ikke, det fører en journal. Falco anvender regler i hændelsens øjeblik og siger »det her er mistænkeligt« — det giver altså et signal og ikke en post.

At have begge er fornuftigt: journalen til gennemgang og signalerne til reaktion. Skal du vælge ét, er auditd mere nyttigt på en server, hvor det vigtigste er at kunne rekonstruere hændelsesforløbet efter en hændelse; hvor et tidligt signal om en igangsat miner eller en webshell er nødvendigt, er det Falco.

Er det pladsen værd på en lille server

Det ærlige svar: ikke altid. Falco behandler systemkald og mærkes på processoren på en belastet maskine. Holder serveren én enkelt hjemmeside, og der endnu hverken findes integritetskontrol eller ordentlige automatiske opdateringer, er det ikke her, man begynder.

Dets øjeblik kommer senere — når grundlaget er på plads, og spørgsmålet står tilbage: hvad sker der på serveren, som ikke ses i logfilerne. Én klasse hændelser dækker det bedre end alle de øvrige tilsammen — en skal startet af webserverens proces. Hvordan hændelserne ser ud fordelt på prioriteter og regler, viser demonstrationssiden nedenfor.