Runtime bezpečnost Linuxu s eBPF: Praktický průvodce Falco a Tetragonem (2026)

Úvod: Proč je runtime monitoring v roce 2026 nezbytný

Statická analýza kontejnerových obrazů a skenování zranitelností při buildu jsou samozřejmě důležité — ale upřímně, nezachytí zdaleka všechno. V roce 2026 čelíme útokům, které se aktivují teprve za běhu: zero-day exploity, kompromitované přihlašovací údaje, útoky typu „living off the land" využívající běžné systémové nástroje, nebo kontejnerové útěky přes zranitelnosti jádra.

A čísla mluví jasně. Podle zprávy CrowdStrike 2025 Global Threat Report bylo 79 % kyberútoků v roce 2024 zcela bez malwaru — útočníci jednoduše používali platné přihlašovací údaje a legitimní systémové utility. Žádný malware, žádný podezřelý binární soubor. Jen normální nástroje, jen jinak.

Právě proto potřebujete runtime bezpečnostní monitoring — vrstvu ochrany, která sleduje, co se ve vašem systému skutečně děje v reálném čase, přímo na úrovni systémových volání jádra. A technologie, která tohle umožňuje s minimální režií a maximální viditelností, se jmenuje eBPF.

V tomhle průvodci si ukážeme, jak nasadit dva špičkové open-source nástroje pro runtime bezpečnost — Falco 0.43 a Tetragon 1.6 — na Linux i Kubernetes. Probereme instalaci, konfiguraci vlastních pravidel, porovnáme oba nástroje a ukážeme si, jak je kombinovat pro maximální ochranu.

Co je eBPF a proč mění bezpečnost Linuxu

eBPF (extended Berkeley Packet Filter) je technologie zabudovaná přímo v jádře Linuxu. Umožňuje spouštět sandboxované programy v prostoru jádra — bez nutnosti modifikovat zdrojový kód jádra, načítat kernel moduly nebo restartovat systém. Každý eBPF program je před spuštěním ověřen verifikátorem, který garantuje, že nemůže poškodit systém ani přistupovat k neautorizovaným datům.

Zní to jednoduše, ale důsledky jsou obrovské.

Klíčové bezpečnostní schopnosti eBPF

• Zachycení systémových volání — monitorování každého execve, open, connect a dalších syscalls v reálném čase
• Sledování síťového provozu — analýza TCP/UDP spojení na úrovni jádra bez nutnosti kopírovat pakety do uživatelského prostoru
• Monitorování integrity souborů — detekce neočekávaných zápisů do kritických souborů jako /etc/passwd nebo /etc/shadow
• Runtime vynucování politik — blokování nebezpečných operací přímo v jádře, ještě předtím, než se dostanou do uživatelského prostoru
• Minimální režie — typicky pod 1 % zatížení CPU díky zpracování přímo v jádře

Mimochodem, v roce 2025 oznámil AWS, že EKS (Elastic Kubernetes Service) bude používat Cilium — postavený právě na eBPF — jako výchozí CNI. To celému odvětví jasně signalizovalo: eBPF opustil výzkumné laboratoře a zabydlel se v jádru produkční infrastruktury.

Falco: Detekce hrozeb v reálném čase

Falco je graduovaný projekt CNCF (Cloud Native Computing Foundation), původně vytvořený společností Sysdig. V podstatě funguje jako runtime bezpečnostní detektor — sleduje systémová volání přes eBPF sondu a vyhodnocuje je oproti sadě YAML pravidel. Když pravidlo zachytí podezřelé chování, Falco vygeneruje upozornění.

Jednoduché, ale účinné.

Instalace Falco na Linux server

Pro instalaci na Debian/Ubuntu s eBPF ovladačem (doporučeno pro jádro 5.8+):

# Přidání GPG klíče a repozitáře Falco
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc |   sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg]   https://download.falco.org/packages/deb stable main" |   sudo tee /etc/apt/sources.list.d/falcosecurity.list

sudo apt-get update
sudo apt-get install -y falco

# Ověření instalace
sudo falco --version
# Falco 0.43.0

Na RHEL/Fedora/Rocky Linux:

# Přidání RPM repozitáře
sudo rpm --import https://falco.org/repo/falcosecurity-packages.asc

cat <<EOF | sudo tee /etc/yum.repos.d/falcosecurity.repo
[falcosecurity]
name=Falco Security Repository
baseurl=https://download.falco.org/packages/rpm/
enabled=1
gpgcheck=1
gpgkey=https://falco.org/repo/falcosecurity-packages.asc
EOF

sudo dnf install -y falco

Instalace na Kubernetes pomocí Helm

Pro nasazení jako DaemonSet na všech uzlech clusteru:

# Přidání Helm repozitáře
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Instalace s eBPF ovladačem a Falcosidekick pro směrování alertů
helm install falco falcosecurity/falco   --namespace falco   --create-namespace   --set driver.kind=modern_ebpf   --set falcosidekick.enabled=true   --set falcosidekick.webui.enabled=true

# Ověření, že Falco běží na všech uzlech
kubectl get pods -n falco -o wide

Konfigurace vlastních pravidel Falco

Výchozí pravidla pokrývají desítky scénářů, což je skvělý start. Ale skutečná síla Falco? Ta spočívá ve vytváření vlastních pravidel specifických pro vaše prostředí. Pravidla se ukládají do /etc/falco/rules.d/:

# /etc/falco/rules.d/custom-rules.yaml

# Detekce spuštění shellu v kontejneru
- rule: Shell v kontejneru
  desc: Detekuje spuštění interaktivního shellu uvnitř kontejneru
  condition: >
    spawned_process
    and container
    and proc.name in (bash, sh, zsh, dash, ksh)
    and proc.tty != 0
  output: >
    Shell spuštěn v kontejneru
    (container=%container.name image=%container.image.repository
    user=%user.name command=%proc.cmdline pid=%proc.pid)
  priority: WARNING
  tags: [container, shell, mitre_execution]

# Detekce čtení citlivých souborů
- rule: Čtení /etc/shadow
  desc: Detekuje proces, který čte soubor /etc/shadow
  condition: >
    open_read
    and fd.name = /etc/shadow
    and not proc.name in (login, passwd, sudo, su, sshd, systemd)
  output: >
    Citlivý soubor přečten
    (file=%fd.name command=%proc.cmdline user=%user.name
    container=%container.name)
  priority: ERROR
  tags: [filesystem, credential_access]

# Detekce reverse shellu
- rule: Podezřelé odchozí spojení
  desc: Detekuje procesy vytvářející odchozí spojení na neobvyklé porty
  condition: >
    evt.type = connect
    and evt.dir = <
    and container
    and fd.typechar = 4
    and fd.ip != "0.0.0.0"
    and not fd.sport in (80, 443, 53, 8080, 8443)
    and proc.name in (bash, sh, python, python3, perl, ruby, nc, ncat)
  output: >
    Podezřelé odchozí síťové spojení z kontejneru
    (command=%proc.cmdline connection=%fd.name container=%container.name
    image=%container.image.repository)
  priority: CRITICAL
  tags: [network, mitre_command_and_control]

Po přidání pravidel můžete Falco restartovat, nebo (a tohle je fajn) poslat signál pro hot-reload:

# Hot-reload pravidel bez restartu
sudo kill -SIGHUP $(pidof falco)

# Nebo klasický restart služby
sudo systemctl restart falco

# Sledování logů s alerty v reálném čase
sudo journalctl -u falco -f

Směrování alertů pomocí Falcosidekick

Tady přichází na řadu Falcosidekick — lehký démon, který přijímá alerty z Falco a přeposílá je do desítek služeb. Slack, Microsoft Teams, PagerDuty, Elasticsearch, Prometheus... zkrátka kamkoliv potřebujete. Konfigurace v Helm:

# values-falcosidekick.yaml
falcosidekick:
  enabled: true
  config:
    slack:
      webhookurl: "https://hooks.slack.com/services/XXXXX/XXXXX/XXXXX"
      minimumpriority: "warning"
    elasticsearch:
      hostport: "https://elasticsearch.monitoring:9200"
      index: "falco-alerts"
      minimumpriority: "notice"
    prometheus:
      extralabels: "env:production,cluster:main"

Tetragon: Observabilita a runtime vynucování

Tetragon je projekt CNCF pod záštitou Cilium a má oproti Falcu jeden zásadní trumf. Zatímco Falco se zaměřuje primárně na detekci a alerting, Tetragon nabízí navíc runtime vynucování — dokáže nebezpečné operace přímo blokovat na úrovni jádra, ještě předtím, než se dostanou do uživatelského prostoru.

To je důležitější, než to na první pohled vypadá. Eliminuje to totiž problém TOCTOU (Time-of-Check-to-Time-of-Use), kdy útočník může provést škodlivou akci v tom krátkém okně mezi detekcí a reakcí. U Tetragonu žádné takové okno neexistuje.

Požadavky na systém

• Linux jádro: minimálně 4.19, doporučeno 5.10+ pro plnou funkcionalitu
• BTF podpora: CONFIG_DEBUG_INFO_BTF=y — ověřte příkazem ls /sys/kernel/btf/vmlinux
• Kubernetes: verze 1.24+ (pro Kubernetes nasazení)

Instalace Tetragonu na Kubernetes

# Přidání Cilium Helm repozitáře
helm repo add cilium https://helm.cilium.io
helm repo update

# Instalace Tetragonu
helm install tetragon cilium/tetragon   --namespace tetragon   --create-namespace   --set tetragon.enableProcessCred=true   --set tetragon.enableProcessNs=true

# Ověření stavu
kubectl get pods -n tetragon
kubectl logs -n tetragon -l app.kubernetes.io/name=tetragon -c tetragon | head -20

# Instalace CLI nástroje tetra
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --remote-name-all   https://github.com/cilium/tetragon/releases/latest/download/tetra-${GOOS}-${GOARCH}.tar.gz
sudo tar -C /usr/local/bin -xzf tetra-${GOOS}-${GOARCH}.tar.gz
tetra version

Vytváření TracingPolicy — deklarativní politiky

Tetragon používá Kubernetes CRD (Custom Resource Definitions) zvané TracingPolicy pro definici bezpečnostních politik. Syntaxe je trochu složitější než u Falco YAML pravidel (počítejte s tím, že budete potřebovat znalost kernel API), ale nabízí výrazně víc kontroly. Pojďme se podívat na pár praktických příkladů:

# detekce-zapisu-etc.yaml
# Sledování zápisů do /etc/ adresáře
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-etc-writes
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/"
          matchActions:
            - action: Post
              kernelStackTrace: true
              userStackTrace: true

# blokovani-nebezpecnych-procesu.yaml
# Blokování spuštění vybraných nástrojů v kontejnerech
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-dangerous-binaries
spec:
  kprobes:
    - call: "security_bprm_check"
      syscall: false
      args:
        - index: 0
          type: "linux_binprm"
      selectors:
        - matchArgs:
            - index: 0
              operator: "In"
              values:
                - "/usr/bin/nc"
                - "/usr/bin/ncat"
                - "/usr/bin/nmap"
                - "/usr/bin/tcpdump"
                - "/usr/bin/strace"
          matchNamespaces:
            - namespace: Pid
              operator: NotIn
              values:
                - "host_ns"
          matchActions:
            - action: Sigkill

Ten druhý příklad je obzvlášť zajímavý — pokud se někdo pokusí spustit nmap, nc nebo tcpdump uvnitř kontejneru, Tetragon proces okamžitě ukončí signálem SIGKILL. Přímo v jádře, bez diskuze.

Aplikace politik:

# Aplikace politiky
kubectl apply -f detekce-zapisu-etc.yaml
kubectl apply -f blokovani-nebezpecnych-procesu.yaml

# Ověření aktivních politik
kubectl get tracingpolicy
kubectl describe tracingpolicy monitor-etc-writes

# Sledování událostí v reálném čase pomocí CLI
kubectl exec -n tetragon -ti ds/tetragon -c tetragon --   tetra getevents -o compact

Falco vs. Tetragon: Kdy použít který nástroj

Oba nástroje staví na eBPF, ale mají dost odlišnou filosofii. Tady je přehledné srovnání, které vám pomůže rozhodnout se:

Vlastnost	Falco 0.43	Tetragon 1.6
Primární zaměření	Detekce a alerting	Detekce + runtime vynucování
Výkonnostní režie	5–10 % (zpracování v userspace)	<1 % (zpracování v jádře)
Formát pravidel	YAML (jednoduchá syntaxe)	TracingPolicy CRD (deklarativní)
Blokování hrozeb	Ne (pouze detekce, reakce přes skripty)	Ano (Sigkill, Override přímo v jádře)
Falešné poplachy	Vyšší (široká pravidla)	Nižší (přesné kernel-level kontexty)
Ekosystém	Samostatný, široká integrace	Cilium / Hubble ekosystém
Pluginy	CloudTrail, Okta, GitHub a další	Zaměřeno na kernel a síťovou vrstvu
Křivka učení	Nižší (srozumitelné YAML)	Vyšší (vyžaduje znalost kernel API)
Nejlepší pro	Alert-centrické workflow, SIEM integrace	Proaktivní runtime enforcement

Doporučená strategie: kombinace obou nástrojů

Po zkušenostech s nasazením obou nástrojů v různých prostředích se jako nejlepší strategie osvědčuje jejich kombinace, kde každý hraje svou specifickou roli:

• Tetragon — nasaďte jako první linii obrany pro runtime vynucování. Blokuje spouštění nebezpečných binárních souborů, chrání kritické systémové soubory a omezuje síťový přístup na úrovni jádra. Prostě tvrdé „ne" pro známé hrozby.
• Falco — nasaďte jako druhou vrstvu pro širokou detekci a alerting. Díky bohaté knihovně výchozích pravidel a pluginům pro cloudové služby poskytuje komplexní přehled o bezpečnostních událostech a integruje se s SIEM platformami.

Tímhle způsobem získáte to nejlepší z obou světů — Tetragon zastaví známé útoky okamžitě, zatímco Falco detekuje subtilnější anomálie a poskytuje kontext pro forenzní analýzu. Žádný nástroj sám o sobě nepokryje všechno, ale tenhle tandem se doplňuje opravdu dobře.

Praktický scénář: Detekce kontejnerového útěku

Tak, pojďme si ukázat kompletní příklad z praxe — detekci a blokování pokusu o kontejnerový útěk. Kontejnerové útěky patří mezi nejzávažnější hrozby v prostředí Kubernetes, protože umožňují útočníkovi dostat se z kontejneru ven na hostitelský systém. A to rozhodně nechcete.

Falco pravidlo pro detekci

# /etc/falco/rules.d/container-escape.yaml
- rule: Pokus o kontejnerový útěk přes nsenter
  desc: Detekuje použití nsenter pro přístup k host namespace
  condition: >
    spawned_process
    and container
    and proc.name = nsenter
  output: >
    KRITICKÉ: Potenciální kontejnerový útěk detekován!
    (command=%proc.cmdline container=%container.name
    image=%container.image.repository user=%user.name
    pid=%proc.pid parent=%proc.pname)
  priority: CRITICAL
  tags: [container, escape, mitre_privilege_escalation]

- rule: Přístup ke kontejnerovému runtime socketu
  desc: Detekuje přístup k Docker/containerd socketu zevnitř kontejneru
  condition: >
    container
    and (open_read or open_write)
    and (fd.name startswith /var/run/docker.sock
         or fd.name startswith /run/containerd/containerd.sock)
  output: >
    Přístup ke kontejnerovému runtime socketu z kontejneru
    (file=%fd.name command=%proc.cmdline container=%container.name)
  priority: CRITICAL
  tags: [container, escape, mitre_privilege_escalation]

Tetragon politika pro blokování

# block-container-escape.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-container-escape
spec:
  kprobes:
    - call: "security_bprm_check"
      syscall: false
      args:
        - index: 0
          type: "linux_binprm"
      selectors:
        - matchArgs:
            - index: 0
              operator: "In"
              values:
                - "/usr/bin/nsenter"
                - "/usr/bin/unshare"
          matchNamespaces:
            - namespace: Pid
              operator: NotIn
              values:
                - "host_ns"
          matchActions:
            - action: Sigkill

Všimněte si, jak se oba nástroje doplňují — Falco detekuje a zaloguje pokus (včetně kontextu jako image, uživatel, příkaz), zatímco Tetragon ho rovnou zastaví. Pokud by Tetragon z jakéhokoli důvodu selhal, Falco vás stejně upozorní.

Hardening eBPF: Ochrana ochránce

Tady je důležitá věc, na kterou se občas zapomíná. eBPF je mocný nástroj — ale právě jeho síla může být zneužita. Výzkumníci už prokázali, že eBPF programy mohou být použity k zachycení provozu, maskování aktivity nebo manipulaci s chováním jádra, aniž by se to projevilo v uživatelských lozích.

Proto je kriticky důležité zabezpečit samotný eBPF:

# Omezení neprivilegovaného eBPF (sysctl)
sudo sysctl -w kernel.unprivileged_bpf_disabled=1

# Trvalé nastavení
echo "kernel.unprivileged_bpf_disabled=1" | sudo tee /etc/sysctl.d/99-ebpf-hardening.conf

# SELinux/AppArmor omezení pro eBPF
# V SELinux profilu:
# allow tetragon_t self:bpf { map_create map_read map_write prog_load prog_run };
# deny unprivileged_user_t self:bpf *;

# Audit logování BPF operací
sudo auditctl -a always,exit -F arch=b64 -S bpf -k ebpf_audit

Integrace s SIEM a centrální monitoring

Runtime bezpečnostní data mají skutečnou hodnotu teprve tehdy, když jsou centralizována a korelována. Samy o sobě jsou to jen izolované události — teprve v kontextu dalších dat se z nich stávají příběhy o tom, co se ve vašem prostředí děje.

Doporučený monitoring stack pro rok 2026:

• Falco → Falcosidekick → Elasticsearch / OpenSearch — pro indexování a fulltextové vyhledávání bezpečnostních událostí
• Tetragon → Hubble → Grafana — pro vizualizaci síťových toků a bezpečnostních metrik
• Prometheus + Alertmanager — pro metriky a eskalace alertů do on-call týmů

Příklad konfigurace Prometheus pro sběr metrik z Falco:

# prometheus.yml - scrape konfigurace pro Falcosidekick
scrape_configs:
  - job_name: "falcosidekick"
    scrape_interval: 15s
    static_configs:
      - targets: ["falcosidekick.falco:2801"]

# Grafana alert rule příklad
# alert: FalcoCriticalAlert
# expr: rate(falcosidekick_outputs_total{priority="critical"}[5m]) > 0
# for: 0m
# labels:
#   severity: critical
# annotations:
#   summary: "Falco detekoval kritickou bezpečnostní událost"

Často kladené otázky (FAQ)

Jaký je rozdíl mezi eBPF a tradičním kernel modulem pro bezpečnostní monitoring?

Kernel modul běží s plnými oprávněními v prostoru jádra a chyba v něm může způsobit kernel panic nebo bezpečnostní zranitelnost. eBPF programy jsou před spuštěním ověřeny verifikátorem, který garantuje jejich bezpečnost — nemohou přistupovat k neautorizované paměti, provádět nekonečné smyčky ani poškodit jádro. A díky technologii CO-RE (Compile Once, Run Everywhere) jsou navíc přenositelné mezi různými verzemi jádra bez nutnosti rekompilace. To je obrovská výhoda oproti tradičním modulům.

Ovlivní Falco nebo Tetragon výkon mého produkčního serveru?

Tetragon zpracovává události přímo v jádře pomocí eBPF a přidává typicky méně než 1 % CPU režie. Falco přenáší události do uživatelského prostoru pro vyhodnocení pravidel, což může přidat 5–10 % režie v prostředích s vysokým objemem systémových volání. V obou případech je ale dopad výrazně nižší než u tradičních bezpečnostních agentů spoléhajících na moduly jádra nebo ptrace.

Mohu používat Falco a Tetragon společně na stejném clusteru?

Ano, a upřímně — je to dokonce doporučená strategie. Oba nástroje využívají eBPF nezávisle na sobě a nekolidují. Tetragon slouží jako proaktivní vrstva pro blokování známých hrozeb přímo v jádře, zatímco Falco poskytuje širší detekci anomálií a bohatou integraci s SIEM platformami. Prostě se doplňují.

Jakou minimální verzi jádra potřebuji?

Falco vyžaduje minimálně jádro 4.14+ pro eBPF ovladač, ale doporučená je verze 5.8+ pro moderní eBPF (modern_ebpf). Tetragon potřebuje jádro 4.19+, přičemž pro plnou funkcionalitu (BTF, kprobes, uprobes) je doporučeno 5.10+. Obecně platí jednoduché pravidlo: novější jádro = lepší výkon a víc dostupných funkcí.

Jak začít, pokud nemám zkušenosti s eBPF?

Začněte s Falcem. Jeho YAML pravidla jsou intuitivní a výchozí sada pokrývá desítky běžných útočných scénářů bez nutnosti jakékoli konfigurace. Nainstalujte Falco na testovací server, nechte ho pár dní běžet a sledujte generované alerty. Postupně přidávejte vlastní pravidla specifická pro vaše prostředí. Teprve po zvládnutí detekce (a pochopení toho, co je ve vašem prostředí normální a co ne) přidejte Tetragon pro runtime vynucování na Kubernetes.