Falco är känt som ett verktyg för Kubernetes, och nästan alla guider om det är skrivna för kluster. Det är emellertid inte bundet till kluster: det handlar om bevakning av systemanrop, och på en vanlig server med en sajt fungerar det precis likadant. Det är bara få som skriver om det användningsfallet.

Det är nyttigt där de andra verktygen tiger. Ett webbskal på sajten bryter inte mot några rättigheter, skapar inga misslyckade inloggningar och utlöser ingen signatur om det skrivits för hand. Men det har ett beteende som är onormalt för en webbserver: PHP-FPM-processen startar ett skal. Det är precis vad Falco ser.

Vad det upptäcker

Typiska händelser på en vanlig server:

  • ett skal skapat av webbserverns eller PHP:s process — praktiskt taget ett entydigt tecken på ett webbskal;
  • start av ett program från /tmp, /dev/shm eller /var/tmp;
  • läsning av känsliga filer (/etc/shadow, privata nycklar) av en process som inte ska göra det;
  • ändring av systemets binärfiler;
  • en utgående anslutning från en process som inte ska använda nätverket.

Installation

Det avgörande valet görs vid installationen — på vilket sätt Falco hämtar systemanropen. Den moderna varianten bygger på eBPF och kräver varken att en kärnmodul byggs eller att kärnhuvuden finns:

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

Den klassiska kärnmodulen kräver kärnhuvuden och byggs om efter varje kärnuppdatering — på en server med automatiska uppdateringar är det en återkommande källa till en trasig tjänst. Är kärnan tillräckligt färsk (5.8 och senare), välj eBPF och glöm det problemet.

Kontroll av att händelser verkligen kommer in:

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

Bruset och hur du blir av med det

Det är huvudarbetet. Standarduppsättningen regler är gjord för containermiljöer, och på en vanlig server är en betydande del av den antingen inte tillämplig eller utlöses hela tiden.

Reglerna som följer med (/etc/falco/falco_rules.yaml) redigeras inte — filen ersätts vid uppdatering. Egna ändringar läggs i /etc/falco/falco_rules.local.yaml, och det är också där de överflödiga stängs av:

- rule: Terminal shell in container
  enabled: false

Vad man vanligen får rätta till på en server utan containrar:

  • alla regler om containrar — finns inga containrar tar de bara plats i rapporten;
  • ”Write below etc” — utlöses vid varje paketinstallation och vid varje konfigurationsändring du gör. Ett undantag behövs för apt, dpkg och unattended-upgrades, annars kommer händelserna i en ström;
  • ”Read sensitive file untrusted” — utlöses av övervaknings- och säkerhetskopieringsagenter och av granskningsverktyg som Lynis;
  • start från tillfälliga kataloger — legitima undantag förekommer: bygge av en applikation, en automatiserad webbläsare som packar upp en drivrutin i en temporär katalog. Sådana utlösningar ser oroande ut men går att förklara, och ett undantag för den bestämda sökvägen är värt att lägga upp direkt för att slippa reda ut samma sak varje gång.

Den rimliga ordningen är densamma som för alla andra detekteringsverktyg: första veckan bara titta och lägga upp undantag, och först därefter behandla en ny händelse som en signal. Regeln är enkel — finns det regelbundet händelser i rapporten som du inte läser, gör den ingen nytta.

Var händelserna ska hamna

I /etc/falco/falco.yaml ställs utdatan in: fil, systemlogg eller överlämning till ett externt program. För en enda server räcker en fil med efterföljande rotation — glöm den inte, händelsefilen växer som vilken logg som helst och som standard bevakar ingen den.

Prioriteterna (priority) är värda att använda för uppdelning: kritiska händelser dit du ser dem direkt, resten till en allmän logg för genomgång.

Falco och auditd är inte samma sak

Båda bevakar systemanrop, men i olika syften. auditd registrerar det som händer så att bilden kan rekonstrueras efteråt: det bedömer ingenting och larmar inte, det för en journal. Falco tillämpar regler i händelsens ögonblick och säger ”det här är misstänkt” — det ger alltså en signal och inte en anteckning.

Att ha båda är rimligt: journalen för genomgång och signalerna för reaktion. Måste du välja ett är auditd nyttigare på en server där det viktigaste är att kunna rekonstruera händelseförloppet efter en incident; där en tidig signal om en igångsatt gruvare eller ett webbskal behövs är det Falco.

Är det värt platsen på en liten server

Det ärliga svaret: inte alltid. Falco bearbetar systemanrop och märks på processorn på en belastad maskin. Håller servern en enda sajt och det ännu varken finns integritetskontroll eller ordentliga automatiska uppdateringar är det inte här man börjar.

Dess stund kommer senare — när grunderna är gjorda och frågan återstår: vad händer på servern som inte syns i loggarna. En klass av händelser täcker det bättre än alla övriga tillsammans — ett skal startat av webbserverns process. Hur händelserna ser ut uppdelade på prioriteter och regler visar demonstrationssidan nedan.