Falco er kjent som et verktøy for Kubernetes, og nesten alle veiledninger om det er skrevet for klynger. Det er imidlertid ikke bundet til klynger: det handler om overvåking av systemkall, og på en vanlig server med et nettsted virker det nøyaktig likedan. Det er bare få som skriver om det bruksområdet.

Det er nyttig der de andre verktøyene tier. Et webskall på nettstedet bryter ingen rettigheter, skaper ingen mislykkede innlogginger og utløser ingen signatur hvis det er skrevet for hånd. Men det har en oppførsel som er unormal for en webserver: PHP-FPM-prosessen starter et skall. Det er nettopp det Falco ser.

Hva det oppdager

Typiske hendelser på en vanlig server:

  • et skall skapt av webserverens eller PHPs prosess — praktisk talt et entydig tegn på et webskall;
  • oppstart av et program fra /tmp, /dev/shm eller /var/tmp;
  • lesing av sensitive filer (/etc/shadow, private nøkler) av en prosess som ikke skal gjøre det;
  • endring av systemets binærfiler;
  • en utgående forbindelse fra en prosess som ikke skal bruke nettverket.

Installasjon

Det avgjørende valget tas ved installasjonen — på hvilken måte Falco henter systemkallene. Den moderne varianten bygger på eBPF og krever verken at en kjernemodul bygges, eller at kjernehoder finnes:

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

Den klassiske kjernemodulen krever kjernehoder og bygges om etter hver kjerneoppdatering — på en server med automatiske oppdateringer er det en tilbakevendende kilde til en ødelagt tjeneste. Er kjernen fersk nok (5.8 og nyere), velg eBPF og glem det problemet.

Kontroll av at hendelser faktisk kommer inn:

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

Støyen og hvordan du blir kvitt den

Det er hovedarbeidet. Standardsettet av regler er laget for containermiljøer, og på en vanlig server er en betydelig del av det enten ikke anvendelig eller utløses hele tiden.

Reglene som følger med (/etc/falco/falco_rules.yaml), redigeres ikke — filen erstattes ved oppdatering. Egne endringer legges i /etc/falco/falco_rules.local.yaml, og det er også der de overflødige slås av:

- rule: Terminal shell in container
  enabled: false

Hva man som regel må rette på en server uten containere:

  • alle regler om containere — finnes det ingen containere, tar de bare plass i rapporten;
  • «Write below etc» — utløses ved hver pakkeinstallasjon og ved hver konfigurasjonsendring du gjør. Et unntak trengs for apt, dpkg og unattended-upgrades, ellers kommer hendelsene i en strøm;
  • «Read sensitive file untrusted» — utløses av overvåkings- og sikkerhetskopieringsagenter og av revisjonsverktøy som Lynis;
  • oppstart fra midlertidige kataloger — legitime unntak forekommer: bygging av en applikasjon, en automatisert nettleser som pakker ut en driver i en midlertidig katalog. Slike utslag ser urovekkende ut, men lar seg forklare, og et unntak for den bestemte stien er verdt å legge opp med en gang for å slippe å utrede det samme hver gang.

Den fornuftige rekkefølgen er den samme som for ethvert annet deteksjonsverktøy: den første uken bare se og legge opp unntak, og først deretter behandle en ny hendelse som et signal. Regelen er enkel — finnes det jevnlig hendelser i rapporten som du ikke leser, gjør den ingen nytte.

Hvor hendelsene skal havne

I /etc/falco/falco.yaml stilles utdataene inn: fil, systemlogg eller overlevering til et eksternt program. For én enkelt server holder en fil med påfølgende rotasjon — ikke glem den, hendelsesfilen vokser som enhver logg, og som standard passer ingen på den.

Prioritetene (priority) er verdt å bruke til oppdeling: kritiske hendelser dit du ser dem med en gang, resten til en generell logg for gjennomgang.

Falco og auditd er ikke det samme

Begge overvåker systemkall, men med ulike formål. auditd registrerer det som skjer, slik at bildet kan rekonstrueres etterpå: det vurderer ingenting og varsler ikke, det fører en journal. Falco anvender regler i hendelsens øyeblikk og sier «dette er mistenkelig» — det gir altså et signal og ikke en oppføring.

Å ha begge er fornuftig: journalen til gjennomgang og signalene til reaksjon. Må du velge ett, er auditd nyttigere på en server der det viktigste er å kunne rekonstruere hendelsesforløpet etter en hendelse; der et tidlig signal om en igangsatt graver eller et webskall trengs, er det Falco.

Er det verdt plassen på en liten server

Det ærlige svaret: ikke alltid. Falco behandler systemkall og merkes på prosessoren på en belastet maskin. Holder serveren ett eneste nettsted, og det ennå verken finnes integritetskontroll eller ordentlige automatiske oppdateringer, er det ikke her man begynner.

Øyeblikket kommer senere — når grunnlaget er på plass og spørsmålet gjenstår: hva skjer på serveren som ikke synes i loggene. Én klasse hendelser dekker det bedre enn alle de øvrige til sammen — et skall startet av webserverens prosess. Hvordan hendelsene ser ut fordelt på prioriteter og regler, viser demonstrasjonssiden nedenfor.