Falco gilt als Werkzeug für Kubernetes, und nahezu jede Anleitung dazu ist für Cluster geschrieben. Dabei ist es nicht an Cluster gebunden: Es beobachtet Systemaufrufe, und auf einem gewöhnlichen Server mit Website funktioniert das genauso. Nur schreibt darüber kaum jemand.

Nützlich ist es dort, wo die anderen Werkzeuge schweigen. Eine Web-Shell auf einer Website verletzt keine Rechte, erzeugt keine fehlgeschlagenen Anmeldungen und trifft auf keine Signatur, wenn sie von Hand geschrieben wurde. Aber sie zeigt ein Verhalten, das für einen Webserver unnormal ist: Der PHP-FPM-Prozess startet eine Shell. Genau das sieht Falco.

Was es bemerkt

Typische Ereignisse auf einem gewöhnlichen Server:

  • eine vom Webserver- oder PHP-Prozess erzeugte Shell — praktisch ein eindeutiges Zeichen für eine Web-Shell;
  • ein Programm, das aus /tmp, /dev/shm oder /var/tmp gestartet wurde;
  • sensible Dateien (/etc/shadow, private Schlüssel), die von einem Prozess gelesen werden, der damit nichts zu tun hat;
  • Veränderung von Systemprogrammen;
  • eine ausgehende Verbindung von einem Prozess, der das Netz nicht nutzen sollte.

Installation

Die entscheidende Wahl fällt bei der Installation: wie Falco an die Systemaufrufe kommt. Die moderne Variante beruht auf eBPF und braucht weder ein gebautes Kernelmodul noch Kernel-Header:

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

Das klassische Kernelmodul braucht Header und wird nach jedem Kernel-Update neu gebaut — auf einem Server, auf dem Updates automatisch einspielen, eine wiederkehrende Quelle für einen toten Dienst. Ist der Kernel neu genug (5.8 und höher), wählen Sie eBPF und vergessen das Problem.

Zur Kontrolle, dass tatsächlich Ereignisse eintreffen:

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

Lärm und wie man ihn beseitigt

Das ist die eigentliche Arbeit. Der mitgelieferte Regelsatz zielt auf Container-Umgebungen, und auf einem gewöhnlichen Server ist ein erheblicher Teil davon entweder nicht anwendbar oder löst ständig aus.

Die mitgelieferten Regeln (/etc/falco/falco_rules.yaml) werden nicht bearbeitet — die Datei wird beim Update ersetzt. Eigene Änderungen kommen nach /etc/falco/falco_rules.local.yaml, und dort werden auch unerwünschte Regeln abgeschaltet:

- rule: Terminal shell in container
  enabled: false

Was auf einem Server ohne Container üblicherweise anzupassen ist:

  • alle Container-Regeln — ohne Container nehmen sie nur Platz im Bericht ein;
  • „Write below etc“ — löst bei jeder Paketinstallation und bei jeder Ihrer Änderungen an einer Konfigurationsdatei aus. Nötig ist eine Ausnahme für apt, dpkg und unattended-upgrades, sonst kommen die Ereignisse im Strom;
  • „Read sensitive file untrusted“ — löst bei Überwachungsagenten, Sicherungswerkzeugen und Audit-Werkzeugen wie Lynis aus;
  • Starts aus temporären Verzeichnissen — legitime Ausnahmen gibt es: das Bauen einer Anwendung oder ein automatisierter Browser, der einen Treiber in ein temporäres Verzeichnis entpackt. Solche Ereignisse wirken beunruhigend, sind aber erklärbar, und eine Ausnahme für den konkreten Pfad legt man besser gleich an, statt es jedes Mal neu herauszufinden.

Die vernünftige Reihenfolge ist dieselbe wie bei jedem anderen Erkennungswerkzeug: in der ersten Woche nur beobachten und Ausnahmen anlegen, und erst danach ein auftauchendes Ereignis als Signal behandeln. Die Regel ist einfach — enthält der Bericht regelmäßig Ereignisse, die Sie nicht lesen, nützt er Ihnen nichts.

Wohin mit den Ereignissen

Die Ausgabe wird in /etc/falco/falco.yaml eingestellt: eine Datei, das Systemjournal oder die Weitergabe an ein externes Programm. Für einen einzelnen Server genügt eine Datei mit anschließender Rotation — vergessen Sie die Rotation nicht, die Ereignisdatei wächst wie jedes Protokoll, und standardmäßig achtet niemand darauf.

Die Prioritäten sollten zur Trennung genutzt werden: kritische Ereignisse dorthin, wo Sie sie sofort sehen, der Rest ins allgemeine Journal zur späteren Durchsicht.

Falco und auditd sind nicht dasselbe

Beide beobachten Systemaufrufe, aber mit unterschiedlichem Ziel. auditd zeichnet auf, was geschieht, damit sich das Bild später rekonstruieren lässt: Es bewertet nichts und meldet nichts, es führt ein Journal. Falco wendet im Augenblick des Ereignisses Regeln an und sagt „das sieht verdächtig aus“ — es gibt also ein Signal statt eines Eintrags.

Beides zu betreiben ist sinnvoll: das Journal für die Rekonstruktion, die Signale für die Reaktion. Muss man sich für eines entscheiden, ist auditd auf einem Server nützlicher, auf dem es vor allem darauf ankommt, die Abfolge der Ereignisse nach einem Vorfall zu rekonstruieren; Falco dort, wo Sie ein frühes Signal über einen laufenden Miner oder eine Web-Shell wollen.

Lohnt es den Platz auf einem kleinen Server

Die ehrliche Antwort: nicht immer. Falco verarbeitet Systemaufrufe und ist auf einer stark genutzten Maschine am Prozessor spürbar. Läuft auf dem Server eine Website und haben Sie weder Integritätsüberwachung noch ordentliche automatische Updates, ist es nicht der richtige Anfang.

Sein Moment kommt später — wenn die Grundlagen stehen und die verbleibende Frage lautet, was auf dem Server geschieht, das die Protokolle nicht zeigen. Eine Klasse von Ereignissen deckt es besser ab als alle anderen zusammen: eine vom Webserver-Prozess gestartete Shell. Wie die Ereignisse nach Priorität und Regel aufgeteilt aussehen, zeigt die Demo-Seite unten.