Laufzeit-Bedrohungserkennung in Containern mit Falco

1. Warum Laufzeit-Bedrohungserkennung eine eigene Ebene braucht

Ein durchgescanntes Image ohne bekannte CVEs ist kein Garant für Sicherheit, sobald ein Angreifer eine Anwendungslücke ausnutzt, die zum Zeitpunkt des Scans noch nicht bekannt war. Genau hier setzt Laufzeit-Bedrohungserkennung mit Falco an: Statt Images vor dem Start zu prüfen, beobachtet Falco, was ein Container während seiner Laufzeit tatsächlich tut, und meldet Abweichungen vom erwarteten Verhalten in Echtzeit. Ein Image-Scan ist eine Momentaufnahme, Laufzeit-Bedrohungserkennung ist ein kontinuierlicher Prozess.

Typische Angriffsmuster, die nur zur Laufzeit sichtbar werden, sind das Starten einer interaktiven Shell in einem Container, der eigentlich nie eine Shell benötigt, unerwartete Netzwerkverbindungen zu unbekannten Hosts, oder Schreibzugriffe auf sensible Systemverzeichnisse wie `/etc/shadow`. Falco erkennt solche Muster, weil es direkt auf Kernel-Ebene ansetzt und jeden relevanten Systemaufruf sieht, unabhängig davon, welche Anwendung im Container läuft. Die folgenden Abschnitte zeigen, wie Falco für Laufzeit-Bedrohungserkennung in Docker-Umgebungen aufgesetzt, konfiguriert und produktiv betrieben wird.

2. Wie Falco funktioniert: eBPF, Kernel-Modul und Syscalls

Falco kann Systemaufrufe auf zwei Wegen beobachten: über ein klassisches Kernel-Modul oder über eBPF, das moderne und empfohlene Verfahren für Laufzeit-Bedrohungserkennung. eBPF-Programme laufen in einer isolierten, verifizierten Sandbox innerhalb des Kernels und können Syscalls, Dateizugriffe und Netzwerkereignisse abgreifen, ohne den Kernel selbst zu modifizieren. Das macht Falco robuster gegenüber Kernel-Updates und reduziert das Risiko von Kernel-Panics durch fehlerhafte Module erheblich.

Jeder abgefangene Syscall wird von Falco mit Kontextinformationen angereichert: Container-ID, Image-Name, Prozessname, Benutzer und die vollständige Prozesshierarchie. Diese Anreicherung ist entscheidend, denn ein roher Syscall wie `openat` sagt für sich genommen wenig aus, aber `openat` auf `/etc/shadow` durch einen Prozess namens `nginx` in einem Webserver-Container ist ein eindeutiges Warnsignal für Laufzeit-Bedrohungserkennung. Falco vergleicht jedes so angereicherte Ereignis gegen einen Regelsatz und löst bei einem Treffer einen Alert mit konfigurierbarem Schweregrad aus.

3. Falco installieren und gegen Docker-Container betreiben

Auf einem Docker-Host lässt sich Falco selbst als privilegierter Container betreiben, der Zugriff auf den Kernel, den Docker-Socket und die Prozess-Namespaces des Hosts benötigt. Diese Anforderung mag paradox wirken, denn ein privilegierter Container widerspricht auf den ersten Blick dem Prinzip minimaler Rechte, ist hier aber unvermeidlich, weil Falco genau diese Systemebene für seine Laufzeit-Bedrohungserkennung beobachten muss.

Nach dem Start liest Falco kontinuierlich den Event-Stream und prüft jedes Ereignis gegen die geladenen Regeln. Die Standardkonfiguration `falco_rules.yaml` deckt bereits gängige Angriffsmuster ab, sollte aber nicht unverändert übernommen werden, weil sie auf eine generische Umgebung ausgelegt ist und in einer spezifischen Infrastruktur viele irrelevante Alerts erzeugen kann.

#!/usr/bin/env bash
# Run Falco as a privileged container using eBPF probe
set -euo pipefail

docker run --rm -it \
  --name falco \
  --privileged \
  --pid host \
  --net host \
  -e FALCO_BPF_PROBE="" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /dev:/dev \
  -v /proc:/host/proc:ro \
  -v /boot:/host/boot:ro \
  -v /lib/modules:/host/lib/modules:ro \
  -v /usr:/host/usr:ro \
  -v ./falco_rules.local.yaml:/etc/falco/falco_rules.local.yaml:ro \
  falcosecurity/falco:latest

# Watch live alerts in JSON format for downstream processing
docker logs -f falco 2>&1 | grep --line-buffered '"priority"'

4. Die mitgelieferten Falco-Regeln verstehen

Die Standardregeln von Falco decken Kategorien wie "Terminal shell in container", "Write below binary dir", "Read sensitive file untrusted" und "Contact K8S API Server From Container" ab. Jede Regel besteht aus einer Bedingung, die auf Syscall-Feldern wie `proc.name`, `fd.name` oder `container.id` basiert, einem Ausgabeformat für den Alert-Text und einem Schweregrad von `INFO` bis `CRITICAL`. Diese Struktur macht Falco-Regeln lesbar, ohne dass man den zugrundeliegenden Syscall-Mechanismus im Detail kennen muss.

Eine der wichtigsten Standardregeln für Laufzeit-Bedrohungserkennung ist "Terminal shell in container", die auslöst, sobald ein interaktiver Shell-Prozess in einem Container gestartet wird, der über `docker exec` oder direkt vom Angreifer initiiert wurde. In den meisten produktiven Container-Umgebungen sollte niemand interaktiv eine Shell öffnen, weshalb diese Regel eine der zuverlässigsten Frühwarnungen für kompromittierte Container liefert.

# Example Falco alert emitted by the default "Terminal shell in container" rule
{
  "output": "A shell was spawned in a container with an attached terminal",
  "priority": "NOTICE",
  "rule": "Terminal shell in container",
  "time": "2026-07-30T09:14:22.000000000Z",
  "output_fields": {
    "container.id": "8f3c1a9b2e77",
    "container.image.repository": "shop-api",
    "proc.cmdline": "bash",
    "proc.pname": "docker-runc",
    "user.name": "root"
  }
}

5. Eigene Falco-Regeln für die eigene Umgebung schreiben

Die generischen Standardregeln decken viel ab, aber die wertvollste Laufzeit-Bedrohungserkennung entsteht durch Regeln, die auf das konkrete erwartete Verhalten einer Anwendung zugeschnitten sind. Für einen PHP-FPM-Container etwa lässt sich definieren, dass ausgehende Netzwerkverbindungen nur zu bekannten Datenbank- und Cache-Hosts erlaubt sind, und jede andere Verbindung einen Alert auslöst. Diese Positivliste ist deutlich robuster als der Versuch, jedes mögliche Angriffsmuster einzeln zu verbieten.

Eigene Falco-Regeln werden in YAML definiert und über `-r` oder die lokale Regel-Datei geladen. Wichtig ist, neue Regeln zunächst im reinen Log-Modus mit niedrigem Schweregrad zu testen, bevor sie mit `CRITICAL` markiert und an ein Alerting-System angebunden werden, damit Falco nicht sofort das gesamte Team mit ungetesteten Regeln überflutet.

# Custom Falco rule: unexpected outbound connection from a PHP-FPM container
- rule: Unexpected outbound connection from PHP-FPM
  desc: >
    A php-fpm process opened an outbound connection to a host
    that is not on the documented allowlist for this workload.
  condition: >
    outbound and container and
    proc.name = "php-fpm" and
    not fd.sip in (allowed_backend_ips)
  output: >
    Unexpected outbound connection from PHP-FPM
    (command=%proc.cmdline connection=%fd.name container=%container.name)
  priority: WARNING
  tags: [network, php, custom]

- list: allowed_backend_ips
  items: ["10.0.1.10", "10.0.1.20", "10.0.2.5"]

6. Alert-Tuning: False Positives systematisch reduzieren

Der größte praktische Feind jeder Laufzeit-Bedrohungserkennung ist Alarmmüdigkeit. Falco erzeugt bei einer unveränderten Standardkonfiguration schnell hunderte Alerts pro Tag, sobald legitime Deployment-Tools, Health-Checks oder CI-Agenten Muster auslösen, die eigentlich harmlos sind. Wer diese Flut ignoriert, verpasst irgendwann auch die echten Alerts, weil das Team aufgehört hat, die Ausgabe überhaupt zu lesen.

Der systematische Ansatz ist, jede neue Regel zunächst gegen produktionsnahe Logs zu testen und bekannte, harmlose Muster explizit über `macro`-Definitionen auszuschließen, statt die gesamte Regel zu deaktivieren. Falco unterstützt wiederverwendbare Makros, mit denen sich zum Beispiel "bekannte CI-Runner-Prozesse" einmal definieren und in mehreren Regeln referenzieren lassen. Das hält den Regelsatz wartbar, während die eigentliche Laufzeit-Bedrohungserkennung scharf bleibt.

# Reusable macro to exclude known-harmless CI runner processes from alerts
- macro: known_ci_runner_processes
  condition: >
    proc.name in (gitlab-runner, docker-entrypoint.sh, healthcheck.sh)

- rule: Unexpected process spawned in production container
  desc: A process was spawned that is not part of the expected image entrypoint chain.
  condition: >
    spawned_process and container and
    not proc.name in (expected_app_processes) and
    not known_ci_runner_processes
  output: >
    Unexpected process in container
    (proc=%proc.name cmdline=%proc.cmdline container=%container.name image=%container.image.repository)
  priority: NOTICE
  tags: [process, custom]

7. Automatisierte Reaktion auf Falco-Alerts

Falco selbst erkennt Bedrohungen, greift aber standardmäßig nicht aktiv ein. Für eine vollständige Laufzeit-Bedrohungserkennung-Pipeline wird Falco daher meist mit `Falco Sidekick` kombiniert, das Alerts an externe Systeme weiterleitet: Slack, PagerDuty, ein SIEM oder eine eigene Webhook-Verarbeitung. Kritische Alerts wie ein erkannter Ausbruchsversuch sollten sofort eskalieren, während informative Alerts in ein Dashboard für die spätere Analyse fließen können.

Für besonders kritische Regeln, etwa ein bestätigter Container-Escape-Versuch, kann eine automatisierte Reaktion sinnvoll sein: Der betroffene Container wird sofort gestoppt oder isoliert, bevor ein Mensch überhaupt reagieren kann. Diese Automatisierung sollte aber sehr sparsam eingesetzt werden, weil eine fehlerhafte Regel sonst produktive Container ohne menschliche Kontrolle beendet, was den Betrieb stärker stört als der ursprüngliche Alert.

#!/usr/bin/env bash
# Minimal Falco Sidekick config forwarding CRITICAL alerts to Slack
set -euo pipefail

cat > falcosidekick-config.yaml <<'EOF'
slack:
  webhookurl: "https://hooks.slack.com/services/REPLACE/WITH/YOUR_WEBHOOK"
  minimumpriority: "warning"
  # messageformat supports host/rule placeholders, see official docs
EOF

docker run -d --name falcosidekick \
  -p 2801:2801 \
  -v ./falcosidekick-config.yaml:/etc/falcosidekick/config.yaml:ro \
  falcosecurity/falcosidekick:latest

8. Falco im produktiven Betrieb: Performance und Skalierung

Falco läuft als ein Prozess pro Host und beobachtet dort alle Container gleichzeitig, was den Ressourcenaufwand im Vergleich zu einem Agenten pro Container gering hält. Bei der eBPF-Variante liegt der typische CPU-Overhead im niedrigen einstelligen Prozentbereich, abhängig von der Syscall-Rate der beobachteten Workloads. Für Laufzeit-Bedrohungserkennung in Umgebungen mit sehr hoher Syscall-Dichte, etwa Datenbank-Container mit intensiver I/O, lohnt sich ein gezieltes Benchmarking vor dem produktiven Rollout.

In größeren Docker-Umgebungen mit vielen Hosts empfiehlt sich eine zentrale Aggregation der Falco-Ausgaben, etwa über Fluentd oder direkt über Falco Sidekick in ein zentrales Log-System. So bleibt die Laufzeit-Bedrohungserkennung auch bei zehn oder hundert Hosts als ein zusammenhängendes Bild lesbar, statt in verstreuten lokalen Logdateien zu versanden.

9. Falco im Vergleich zu anderen Ansätzen

Falco ist nicht die einzige Möglichkeit für Laufzeit-Bedrohungserkennung, unterscheidet sich aber deutlich von statischen Sicherheitsprüfungen. Die folgende Tabelle stellt die wichtigsten Eigenschaften gegenüber.

Falco schließt damit gezielt die Lücke, die statische Scanner und geplante Audits offen lassen: das Verhalten eines Containers, nachdem er bereits gestartet ist. In Kombination mit Docker Bench Security für die Konfiguration und Trivy oder Grype für die Images entsteht eine mehrschichtige Laufzeit-Bedrohungserkennung, die Angriffe in jeder Phase des Container-Lebenszyklus abdeckt.

10. Zusammenfassung

Laufzeit-Bedrohungserkennung mit Falco schließt eine Lücke, die kein Image-Scanner und kein statischer Audit abdecken kann: das tatsächliche Verhalten eines Containers während der Ausführung. Über eBPF beobachtet Falco Systemaufrufe direkt im Kernel, reichert sie mit Container-Kontext an und vergleicht sie gegen einen konfigurierbaren Regelsatz. Die mitgelieferten Standardregeln decken gängige Angriffsmuster ab, entfalten ihren vollen Wert aber erst durch Regeln, die auf das erwartete Verhalten der eigenen Workloads zugeschnitten sind.

Der entscheidende Erfolgsfaktor ist konsequentes Alert-Tuning: Ohne systematische Reduktion von False Positives verkommt jede Laufzeit-Bedrohungserkennung zur ignorierten Log-Flut. Wer neue Regeln zunächst im Log-Modus testet, Makros für bekannte harmlose Muster nutzt und kritische Alerts über eine klare Eskalationskette weiterleitet, bekommt mit Falco ein Werkzeug, das echte Angriffe erkennt, ohne das Team zu überfordern.

11. FAQ: Laufzeit-Bedrohungserkennung mit Falco