Falco mit Docker installieren: CNCF-Runtime-Security für Container

Wer Docker-Container betreibt, sichert sie meist vor dem Start ab: Images scannen, Ports minimieren, Netzwerke trennen. Was danach passiert – zur Laufzeit – bleibt oft blind. Genau hier setzt Falco an: Das CNCF-graduierte Open-Source-Tool hängt sich per eBPF tief in den Linux-Kernel ein und analysiert jeden Systemaufruf aller laufenden Container in Echtzeit. Sobald ein Container eine Shell startet, Rechte eskaliert, auf sensible Dateien zugreift oder unerwartete Netzwerkverbindungen öffnet, feuert Falco sofort einen Alert – ohne nennenswerten Performance-Impact. Für DevOps- und Security-Teams in KMU ist Falco der fehlende letzte Verteidigungsring, der auch nach dem Deployment noch schützt.

Voraussetzungen

1. Linux-Host (Ubuntu 22.04+, Debian 12, oder beliebige Linux-VM/NAS mit Docker-Support) – Windows und macOS Docker Desktop werden von Falco nicht unterstützt, da der Kernel-Zugriff fehlt.
2. Linux-Kernel 5.8+ für den Modern-eBPF-Modus (empfohlen, kein Treiber-Kompilieren nötig). Ältere Kernel (ab 4.14) funktionieren mit eBPF-Probe oder Kernel-Modul.
3. Docker Engine 20.10+ und Docker Compose v2 (Plugin-Variante, Befehl docker compose) installiert – siehe Docker und Docker Compose auf Linux installieren.
4. Root- oder sudo-Zugriff: Falco braucht zwingend erhöhte Rechte (privileged: true oder CAP_SYS_ADMIN).
5. Internetzugang vom Host: Beim ersten Start lädt falcoctl automatisch die Community-Regelsets herunter.
6. Mindestens 512 MB RAM für Falco, weitere 256 MB für Falcosidekick + Redis.
7. Optional: Reverse Proxy mit HTTPS, wenn die Falcosidekick-UI über das Internet erreichbar sein soll – empfehlenswert, da die UI keine eigene Authentifizierung mitbringt.

Schritt 1: Projektordner und .env anlegen

Lege einen dedizierten Projektordner an und erstelle die Konfigurationsdatei. Alle anpassbaren Einstellungen – z. B. Slack-Webhook für Alert-Weiterleitung – kommen ausschließlich in die .env, nicht direkt in die compose.yaml.

sudo mkdir -p /opt/falco
cd /opt/falco

Erstelle die .env-Datei:

# /opt/falco/.env
# Falcosidekick: optionaler Slack-Webhook für Alert-Weiterleitung
# Leer lassen, wenn kein Slack verwendet wird
SLACK_WEBHOOKURL=

# Weitere Ausgabe-Ziele (optional, Falcosidekick unterstützt >50 Ziele)
# TEAMS_WEBHOOKURL=
# PAGERDUTY_ROUTINGKEY=

# Falcosidekick-UI aktivieren
FALCOSIDEKICK_UI=true

Verifizieren: Die Datei ist vorhanden und lesbar:

ls -la /opt/falco/.env
# Erwartete Ausgabe: -rw-r--r-- 1 root root ... .env

Schritt 2: compose.yaml erstellen

Der Stack besteht aus vier Services: Falco (Kernel-Sensor), Falcosidekick (Alert-Router), Falcosidekick-UI (Web-Dashboard) und Redis (Alert-Persistenz für die UI). Wichtig: Falco benötigt zwingend privileged: true sowie mehrere Host-Bind-Mounts für Kernel-Tracing, Docker-Socket und Prozess-Informationen.

Die nachfolgende Tabelle gibt einen Überblick über alle Image-Parameter, bevor wir zur vollständigen compose.yaml kommen:

Erstelle jetzt die vollständige compose.yaml:

# /opt/falco/compose.yaml
services:
  falco:
    image: falcosecurity/falco:0.44.1
    restart: unless-stopped
    # Falco benötigt privilegierten Zugriff für Kernel-Tracing.
    # In Produktion stattdessen: cap_add + cap_drop all (siehe Troubleshooting).
    privileged: true
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      # Kernel-Tracing für Modern eBPF (Kernel 5.8+ pflicht)
      - /sys/kernel/tracing:/sys/kernel/tracing:ro
      # Docker-Socket für Container-Metadaten
      - /var/run/docker.sock:/host/var/run/docker.sock
      # Prozess-Informationen vom Host
      - /proc:/host/proc:ro
      # Host-Konfiguration für Kontext-Anreicherung
      - /etc:/host/etc:ro
    environment:
      # falcoctl lädt Community-Rules beim ersten Start automatisch
      - SKIP_DRIVER_LOADER=false
    # Falcosidekick-Verbindung: Falco sendet Alerts per HTTP an Port 2345
    command: >
      falco
      -o "json_output=true"
      -o "http_output.enabled=true"
      -o "http_output.url=http://falcosidekick:2345"
    depends_on:
      - falcosidekick

  falcosidekick:
    image: falcosecurity/falcosidekick:latest
    restart: unless-stopped
    ports:
      - "2345:2345"
    environment:
      - LISTENADDRESS=0.0.0.0
      - LISTENPORT=2345
      # Slack-Webhook aus .env (leer = deaktiviert)
      - SLACK_WEBHOOKURL=${SLACK_WEBHOOKURL:-}
      # Webui aktivieren und Adresse angeben
      - WEBUI_URL=http://falcosidekick-ui:2346
    depends_on:
      - falcosidekick-ui

  falcosidekick-ui:
    image: falcosecurity/falcosidekick-ui:latest
    restart: unless-stopped
    ports:
      - "2346:2346"
    environment:
      # Redis für Alert-Persistenz (optional, aber empfohlen)
      - FALCOSIDEKICK_UI_REDIS_URL=redis:6379
    depends_on:
      - redis

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    volumes:
      - redis_data:/data

volumes:
  redis_data:

Verifizieren: Die YAML-Syntax ist korrekt (kein Fehler bei der Ausgabe):

cd /opt/falco && docker compose config --quiet
# Keine Ausgabe = kein Syntaxfehler

Schritt 3: Stack starten

Starte alle vier Services mit einem einzigen Befehl. Beim ersten Start zieht Docker die Images und falcoctl lädt automatisch die aktuellen Community-Regelsets herunter – das dauert je nach Internetverbindung bis zu zwei Minuten.

cd /opt/falco
docker compose up -d

Erwartete Ausgabe (gekürzt):

✔ Network falco_default              Created
✔ Container falco-redis-1            Started
✔ Container falco-falcosidekick-ui-1 Started
✔ Container falco-falcosidekick-1    Started
✔ Container falco-falco-1            Started

Verifizieren: Alle Container laufen (Status „Up"):

docker compose ps
# NAME                        STATUS
# falco-falco-1               Up X seconds
# falco-falcosidekick-1       Up X seconds
# falco-falcosidekick-ui-1    Up X seconds
# falco-redis-1               Up X seconds

Prüfe außerdem die Falco-Logs auf erfolgreichen Treiber-Load und Regelsets:

docker compose logs falco | tail -30
# Gesuchte Zeilen (Beispiel):
# Falco version: 0.44.1
# Loading rules from file /etc/falco/falco_rules.yaml
# Starting health webserver with threadiness 4
# Enabled event sources: syscall

Schritt 4: Falcosidekick-UI im Browser öffnen

Öffne im Browser http://<SERVER-IP>:2346 – du siehst die Falcosidekick-UI mit einer Echtzeit-Übersicht aller Falco-Alerts nach Priorität, Regelname und betroffenen Containern. Zu Beginn ist die Ansicht leer, da noch keine Alerts gefeuert wurden.

Verifizieren: Die UI antwortet per HTTP:

curl -I http://localhost:2346
# Erwartete Ausgabe:
# HTTP/1.1 200 OK

Falcosidekick selbst ist auf Port 2345 erreichbar:

curl -s http://localhost:2345/ping
# Erwartete Ausgabe: pong

Schritt 5: Falco-Erkennung testen

Falco schlägt sofort an, wenn ein Container eine Shell startet – eines der häufigsten Anzeichen für eine laufende Attacke. Teste das mit einem einzeiligen Befehl: Der offizielle event-generator triggert gezielt bekannte Regeln und ist das empfohlene Werkzeug für funktionale Tests.

Variante A – einfacher Shell-Test in einem bestehenden Container:

# Starte einen Test-Container und öffne eine Shell darin
docker run -it --rm alpine sh -c "whoami"
# Falco sollte sofort 'Terminal shell in container' loggen

Variante B – offizieller Event-Generator (triggert mehrere Regeln):

docker run -it --rm falcosecurity/event-generator run syscall --loop

Verifizieren: Alerts erscheinen in den Falco-Logs:

docker compose logs falco | grep -i "Warning\|Critical\|Error" | tail -20
# Beispiel-Alert:
# Warning Symlinks created over sensitive files
#   (user=root command=ln -s /etc/shadow /tmp/shadow ...)

In der Falcosidekick-UI unter http://<SERVER-IP>:2346 tauchen die Alerts jetzt ebenfalls auf – mit Zeitstempel, Regelname, Container-ID und Host-Kontext.

Schritt 6: Eigene Regeln einbinden (optional)

Falco liest Regeln aus /etc/falco/falco_rules.yaml und aus allem, was in /etc/falco/rules.d/ liegt. Eigene Regeln ergänzen die Community-Defaults, ohne sie zu überschreiben. Erstelle lokal eine Regel-Datei und mounte sie per Volume:

Beispiel-Regelfile /opt/falco/custom_rules.yaml:

- rule: Curl in Container detected
  desc: Jemand führt curl in einem Container aus
  condition: spawned_process and proc.name = "curl" and container
  output: "curl-Aufruf in Container (user=%user.name cmd=%proc.cmdline container=%container.name)"
  priority: WARNING
  tags: [network, custom]

Füge das Volume in der compose.yaml unter dem falco-Service hinzu:

    volumes:
      - /sys/kernel/tracing:/sys/kernel/tracing:ro
      - /var/run/docker.sock:/host/var/run/docker.sock
      - /proc:/host/proc:ro
      - /etc:/host/etc:ro
      # Eigene Regeln:
      - /opt/falco/custom_rules.yaml:/etc/falco/rules.d/custom_rules.yaml:ro

Danach den Falco-Service neu starten:

cd /opt/falco && docker compose up -d falco

Verifizieren: Falco lädt die eigene Regel:

docker compose logs falco | grep "custom_rules"
# Erwartete Ausgabe:
# Loading rules from file /etc/falco/rules.d/custom_rules.yaml

Schritt 7: Updates durchführen

Für Updates ziehe neue Images und starte den Stack neu. Das gepinnte Tag 0.44.1 für Falco solltest du bewusst auf neue Releases anpassen – prüfe dazu das Falco GitHub-Repository auf neue Releases. Falcosidekick und die UI laufen auf :latest und werden automatisch aktuell gezogen. Für ein strukturiertes Container-Update-Konzept empfiehlt sich Diun oder WUD als Watchtower-Nachfolger.

cd /opt/falco
docker compose pull
docker compose up -d
docker compose ps

Verifizieren: Alle Container laufen mit aktualisierten Images:

docker compose ps
docker images | grep falco

Troubleshooting / Typische Fehler

1. „Failed to load the driver" / „BPF probe: permission denied" – Ursache: privileged: true fehlt, oder der Kernel ist älter als 5.8. Lösung: privileged: true ergänzen oder Kernel-Modul-Modus aktivieren: -o engine.kind=kmod in den Falco-Startparametern.
2. „/sys/kernel/tracing: No such file or directory" – Ursache: Ältere Kernels mounten tracefs unter /sys/kernel/debug/tracing. Lösung: Volume-Mount ändern auf /sys/kernel/debug/tracing:/sys/kernel/debug/tracing:ro.
3. Falco startet, aber keine Alerts erscheinen – Ursache: falcoctl kann Community-Regeln nicht herunterladen (kein Internetzugang vom Container). Lösung: Regeln manuell herunterladen und als Volume mounten, oder FALCOCTL_DRIVER_REPOS auf einen internen Mirror setzen.
4. „docker.sock: permission denied" – Ursache: Falscher Volume-Pfad. Das Mapping muss exakt /var/run/docker.sock:/host/var/run/docker.sock lauten – nicht /var/run/docker.sock:/var/run/docker.sock.
5. Falcosidekick zeigt „connection refused" zu Falco – Ursache: Falco sendet Alerts nicht per HTTP an Falcosidekick. Prüfe, ob der Befehl in der compose.yaml die Flags -o "http_output.enabled=true" und -o "http_output.url=http://falcosidekick:2345" enthält.
6. „mmap: Operation not permitted" beim eBPF-Probe-Laden – Ursache: RLIMIT_MEMLOCK zu niedrig. Lösung: ulimits: memlock: soft: -1 hard: -1 unter dem falco-Service ergänzen (im Beispiel oben bereits enthalten).
7. ARM64-Host: Kernel-Modul-Treiber steht nicht bereit – Empfehlung: Modern eBPF verwenden (engine.kind=modern_ebpf), das erfordert keine Kompilierung.
8. „rule file not found" für eigene Regeln – Ursache: Regelfiles außerhalb von /etc/falco/rules.d/ gemountet. Falco liest nur aus /etc/falco/falco_rules.yaml und /etc/falco/rules.d/.

Häufige Fragen

Braucht Falco eine Datenbank?

Nein. Falco selbst ist vollständig zustandslos und benötigt keine Datenbank. Redis im Stack dient ausschließlich der Falcosidekick-UI, damit die Alert-Geschichte über Container-Neustarts hinaus erhalten bleibt. Wer die UI-Persistenz nicht braucht, kann Redis weglassen und die FALCOSIDEKICK_UI_REDIS_URL-Umgebungsvariable entfernen.

Welcher Treiber-Modus ist empfohlen?

Für die meisten Setups ist Modern eBPF die beste Wahl: Er ist seit Falco 0.35+ direkt im Falco-Binär eingebettet, muss nicht separat kompiliert werden und läuft auf jedem Linux-Kernel ab 5.8. Ubuntu 22.04 und Debian 12 erfüllen diese Anforderung von Haus aus. Für ältere Kernel (ab 4.14) ist die eBPF-Probe die nächste Option, erfordert aber einen Treiber-Build via falco-driver-loader.

Kann Falco auf Windows oder macOS laufen?

Nein. Falco greift direkt auf Linux-Kernel-Systemaufrufe zu – das ist technisch nicht möglich unter Windows oder macOS, auch nicht über Docker Desktop. Du brauchst zwingend einen echten Linux-Host oder eine Linux-VM (z. B. auf Proxmox, Hetzner oder Netcup). Docker Desktop auf Windows/macOS simuliert keinen vollständigen Linux-Kernel mit eBPF-Support.

Wie hoch ist der Performance-Impact?

Laut Falco-Projekt-Benchmarks liegt der CPU-Overhead des Modern-eBPF-Treibers auf einem typischen Produktionssystem unter 3 % – deutlich weniger als klassische Kernel-Module oder User-Space-Agenten. Der Grund: eBPF-Programme laufen im Kernel-Kontext ohne Kontext-Wechsel in den User-Space.

Kann ich Alerts an Slack, Teams oder PagerDuty weiterleiten?

Ja, genau dafür ist Falcosidekick zuständig. Es unterstützt über 50 Ausgabe-Ziele. Für Slack reicht es, die Variable SLACK_WEBHOOKURL in der .env-Datei zu setzen. Weitere Ziele wie Microsoft Teams (TEAMS_WEBHOOKURL) oder PagerDuty (PAGERDUTY_ROUTINGKEY) werden analog konfiguriert.

Sollte ich in Produktion wirklich --privileged verwenden?

Der Einfachheit halber setzt diese Anleitung auf privileged: true, was dem Container nahezu uneingeschränkten Host-Zugriff gibt. In Produktionsumgebungen empfiehlt die offizielle Falco-Dokumentation stattdessen Least-Privilege: cap_add: [SYS_ADMIN, SYS_RESOURCE, SYS_PTRACE] kombiniert mit cap_drop: [ALL]. Das reduziert die Angriffsfläche erheblich, während Falco weiterhin alle notwendigen Rechte behält. Mehr dazu in der Anleitung Docker Compose absichern: Secrets, Healthchecks, Non-Root.

Wie überprüfe ich, ob Falco-Images legitim sind?

Alle offiziellen Falco-Container-Images ab Version 0.35.0 sind mit cosign signiert. Du kannst die Signatur prüfen mit: cosign verify falcosecurity/falco:0.44.1 --certificate-oidc-issuer=https://token.actions.githubusercontent.com. Das ist besonders sinnvoll in automatisierten CI/CD-Pipelines, bevor ein neues Image eingespielt wird. Mehr zum Thema Image-Sicherheit findest du in der Anleitung Docker-Images auf Schwachstellen scannen mit Trivy.

Fazit

Falco schließt eine echte Lücke im Container-Sicherheitskonzept: Was vor dem Deployment passiert, lässt sich gut mit Image-Scannern absichern. Was zur Laufzeit passiert, sieht man ohne ein Tool wie Falco schlicht nicht. Das CNCF-Graduation-Label ist dabei kein Marketing, sondern ein Zeichen für produktionsreife Stabilität – das Projekt wird aktiv gepflegt und folgt klaren Release-Zyklen.

Für KMU und DevOps-Teams, die Docker-Umgebungen ohne enormen Aufwand gegen Laufzeit-Angriffe absichern wollen, ist der hier beschriebene Stack aus Falco, Falcosidekick und der Web-UI ein pragmatischer Einstieg: einmal aufgesetzt, läuft er wartungsarm im Hintergrund und liefert sofort umsetzbare Alerts. Wer danach mehr Tiefe will, kann Falcosidekick an Elasticsearch oder Grafana Loki anbinden und die Alerts in bestehende Monitoring-Infrastruktur integrieren – etwa zusammen mit dem Beszel Server Monitoring.

Weiterführende Anleitungen und Quellen

1. Docker-Images auf Schwachstellen scannen mit Trivy: CVE-Check, SBOM und automatische Scans
2. Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only für den Produktivbetrieb
3. Docker-Container automatisch aktualisieren nach dem Watchtower-Aus: Diun, WUD und Renovate
4. Docker und Docker Compose auf Linux installieren: die Self-Hosting-Grundlage
5. Linux-Server absichern: UFW-Firewall und Fail2ban

Offizielle Quellen: Falco Container-Deployment-Dokumentation | Falco Docker Quickstart | Falco GitHub-Repository | falcosecurity/falco auf Docker Hub

Passende Anleitungen auf S-EDV

1. netcup Local Block Storage bestellen, einrichten und unter Linux einbinden
2. Linux 7.1-rc6 veröffentlicht: Kernel-Entwicklung stabilisiert sich nach KI-bedin
3. Linux-Kernel CVE-2026-23111: Ein-Zeichen-Fehler in nf_tables ermöglicht lokale R