Az eBPF futásidejű biztonság egy olyan védelmi modell, amely a Linux kernelben futó, biztonságosan verifikált programok segítségével figyeli és (szükség esetén) blokkolja a syscall- és kernelszintű eseményeket anélkül, hogy a kernel forrásához hozzá kellene nyúlni vagy kernelmodult kellene betölteni. A két meghatározó implementáció 2026-ban a Falco (CNCF, detection-first) és a Tetragon (Isovalent/Cilium, enforcement-képes). Ebben a cikkben végigvezetlek azon, hogyan állítom be őket éles környezetben, mit ad nekünk az LSM BPF, és mikor melyiket választom.
Az eBPF a Linux 4.4 óta fejlődik, de a futásidejű biztonsághoz a kernel 5.7+ (LSM BPF), inkább a 6.x sorozat ajánlott. 2026-ban a kernel 6.12 LTS a stabil választás.
A Falco (v0.39, 2026 első negyedév) detekcióra optimalizált: rule engine, syscall- és K8s-audit-források, kit-alapú telepítés falcoctl-lel.
A Tetragon (v1.3+) TracingPolicy CRD-vel deklaratív szabályokat tesz lehetővé, és SIGKILL/override akciókkal képes a támadást a kernelben megállítani.
Az LSM BPF (CVE-szintű mérséklés helyett megelőzés) a CONFIG_BPF_LSM=y kapcsolóval és a lsm=...,bpf kernel paraméterrel aktiválható.
Tipikus teljesítményhatás: 1–4% CPU overhead jól megírt programokkal, syscallonként néhány száz nanoszekundum.
Detection-only környezetben Falco, prevenciónál vagy Cilium-natív telepítésnél Tetragon; nagy környezetben a kettő együtt is működik.
Mi az eBPF futásidejű biztonság?
Az eBPF (extended Berkeley Packet Filter) eredetileg hálózati szűrésre készült, de az elmúlt évtizedben általános célú, in-kernel végrehajtási platformmá vált. Egy felhasználói térben írt eBPF program (jellemzően C-ben vagy Rustban, libbpf vagy Aya keretrendszerrel) bytecode-ra fordul, majd a kernel verifier statikusan ellenőrzi (terminálódás, memóriaérvényesség, ciklusok kötöttsége), és csak ezután kapcsolja rá egy hook-ra: tracepoint, kprobe, uprobe, tc, XDP, vagy (biztonsági szempontból ez a legizgalmasabb) LSM (Linux Security Module).
Tapasztalatom szerint a kernelfejlesztők között gyakori félreértés, hogy az eBPF „csak megfigyel". Pedig nem. A Linux 5.7-től elérhető BPF LSM (Casey Schaufler et al., commit 9e4453e8c) az MAC (Mandatory Access Control) hookokra köthető eBPF programokat tesz lehetővé, vagyis nem csak detektálni tudunk, hanem megtagadni is a műveletet, pontosan ott, ahol az AppArmor és a SELinux is dolgozik. Két jelentős üzemkész implementáció épül erre: a Falco (felhasználói térben dolgozza fel az eseményeket egy szabálymotorral) és a Tetragon (kernelben hoz döntést, így gyorsabb és nem kerülhető meg a felhasználói daemonon keresztül).
Aki a hálózati oldalon érte el a témát, érdemes megnézni a Linux konténerbiztonság mesterfokon cikkemet. Ott részleteztem, hogyan illeszkedik az eBPF a konténerizált védelem teljes képébe.
Kernel- és LSM BPF-követelmények 2026-ban
A minimum kernelverzió, amivel komolyan érdemes elindulni: 5.10 (régi LTS, korlátozott LSM-hook lefedettség). A javasolt verzió 2026 közepén a 6.12 LTS (kiadva 2024 novemberében, fenntartás 2026 decemberéig minimum, az LTS-bővítésekkel akár tovább, a kernel.org release schedule szerint). Disztribúciók: RHEL 9.5 (6.x backport), Ubuntu 24.04 LTS (6.8 → HWE 6.11+), Debian 13 „Trixie" (6.12).
A BPF LSM bekapcsolásához három feltételnek kell teljesülnie:
# 1) A kernel build-elve van BPF LSM támogatással
grep CONFIG_BPF_LSM /boot/config-$(uname -r)
# CONFIG_BPF_LSM=y
# 2) A kernel parancssor tartalmazza a bpf LSM-et
cat /sys/kernel/security/lsm
# lockdown,capability,landlock,yama,apparmor,bpf
# Ha nincs ott, a /etc/default/grub-ba:
# GRUB_CMDLINE_LINUX="lsm=lockdown,capability,landlock,yama,apparmor,bpf"
# sudo update-grub && sudo reboot
# 3) bpftool elérhető (ellenőrzés és debug)
sudo bpftool prog show
Falco telepítése és szabályrendszere
A Falco a CNCF Graduated projektje (2024 februárjától), 2026-ban a 0.39 ágon van. Két forrásból olvas: a klasszikus kmod helyett modern_ebpf driver (CO-RE, vagyis Compile Once, Run Everywhere), valamint Kubernetes audit eseményekből. Az alábbi parancsok Ubuntu 24.04-en és RHEL 9-en is mennek a hivatalos repóból:
A szabályok YAML-ben íródnak, és a syscall-mintából lőnek riasztást. Egy minimális, de hasznos szabály: érzékeny fájlokhoz való olvasási hozzáférés nem-rendszergyökeres folyamatból.
- rule: Sensitive file opened for reading by non-trusted
desc: Egy nem-megbízható folyamat /etc/shadow-ot vagy SSH kulcsot olvas
condition: >
open_read and
(fd.name in (/etc/shadow, /etc/gshadow) or
fd.name startswith /root/.ssh/) and
not proc.name in (sshd, systemd, login, su, sudo)
output: >
Érzékeny fájl olvasása (user=%user.name uid=%user.uid
command=%proc.cmdline file=%fd.name container=%container.id)
priority: WARNING
tags: [filesystem, mitre_credential_access, T1552]
A falcoctl egy plugin- és rule-feed manager. Az falcoctl artifact install paranccsal a CNCF által karbantartott szabálycsomagokat (k8saudit, falco-incubating-rules) lehet húzni, OCI registry-ből, aláírással ellenőrizve. Riasztások kimenete: stdout, syslog, gRPC stream, vagy falcosidekick-en keresztül Slack/PagerDuty/Loki/Elastic.
Tetragon telepítése és TracingPolicy
A Tetragon az Isovalent (Cilium) projektje, amely 2024-ben CNCF Incubating státuszba lépett, 2026-ban a 1.3 ágon stabil. A fő különbség Falcóhoz képest: a Tetragon a kernelben hoz döntést, így nincs „felhasználói térbeli rés", amelyen át a támadó az ellenőrzés előtt befejezi a műveletet (TOCTOU-szerű kerülő).
# Standalone telepítés (nem K8s)
curl -L https://github.com/cilium/tetragon/releases/download/v1.3.0/tetragon-v1.3.0-linux-amd64.tar.gz \
| sudo tar -xz -C /usr/local/
sudo systemctl enable --now tetragon
sudo tetra getevents -o compact
# Egy TracingPolicy: tiltsuk meg, hogy a www-data felhasználó
# /etc/shadow-ot nyisson, és öljük meg a folyamatot
cat <<'EOF' | sudo tee /etc/tetragon/tetragon.conf.d/policies/block-shadow.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: "block-shadow-read"
spec:
kprobes:
- call: "security_file_open"
syscall: false
args:
- index: 0
type: "file"
selectors:
- matchArgs:
- index: 0
operator: "Equal"
values:
- "/etc/shadow"
matchActions:
- action: Sigkill
EOF
sudo systemctl restart tetragon
A security_file_open egy LSM hook, vagyis a Tetragon nem syscall-szinten avatkozik be, hanem a hozzáférés-vezérlési döntésnél, ott, ahol a SELinux is. Ez azért fontos, mert a syscall argumentumok már feloldódtak (symlink, mount namespace), és a támadó nem tud trükközni a path-traversallal. A Sigkill akció a sértő folyamatot megöli; az Override egy adott hibakódot ad vissza, az Audit csak naplóz.
Falco vs Tetragon: mi a különbség?
A két eszköz nem teljesen helyettesítője egymásnak. Az alábbi tábla összefoglalja, mit kell mérlegelni. Éles döntésnél én mindig a fenyegetésmodellből indulok ki, nem a marketingből.
Szempont
Falco 0.39
Tetragon 1.3
Elsődleges fókusz
Detektálás (alerting)
Detektálás + prevenció
Döntéshozatal helye
Felhasználói tér (rule engine)
Kernel (LSM BPF/kprobe)
Enforcement akciók
Nincs (riasztás)
Sigkill, Override, NotifyEnforcer
Szabályformátum
YAML rules + macros
Kubernetes-natív TracingPolicy CRD
K8s audit log feed
Beépített plugin
Nincs (Cilium Hubble figyeli a hálót)
Karbantartó
Falcosecurity / Sysdig
Isovalent / Cisco
Min. kernel
5.8 (modern_ebpf)
5.4+ (5.10+ ajánlott)
Tipikus CPU overhead
~2–4%
~1–3%
Röviden: ha SOC-csapatod van, amelyik már Falco-szabályokkal dolgozik, és a riasztás-pipeline kiépített (SIEM, alertmanager), a Falco a kényelmesebb. Ha viszont Cilium-alapú hálózati biztonság van K8s-ben, vagy a fenyegetésmodelled kifejezetten supply-chain (pl. szabotált container image kompromittálódik runtime-ban), a Tetragon prevenció-képessége egyszerűen többet ad. Sok éles környezetben a kettő párhuzamosan fut: Falco a vékony, mindenre kiterjedő észlelésre, Tetragon a néhány tucat magas értékű prevenciós szabályra.
Egy másik szempont: a klasszikus MAC-rendszerek (a részleteket lásd a SELinux és AppArmor a gyakorlatban cikkben) statikus politikát adnak, az eBPF-eszközök pedig dinamikus, eseményalapú szabályokat. A kettő nem versenyez, kiegészíti egymást.
Tetragon esetén a Cilium ökoszisztémából a Helm chart hozza a CRD-ket, a daemonsetet, és (opcionálisan) Hubble-relay-en keresztül összeköti a hálózati eseményekkel:
RBAC szempontból fontos: a Tetragon TracingPolicy egy cluster-scoped erőforrás, alapból csak cluster-admin írhat. Ez helyes alapértelmezés, mert prevenciós szabályt nem ad ki random namespace owner. A Falco-rules ConfigMap viszont namespace-scoped, ezért érdemes GitOps-os szabálykezelést (Flux/ArgoCD) tenni elé, hogy ne tudja valaki kézzel némítani. Részletesebb DevSecOps-folyamatról a Linux sebezhetőségvizsgálat automatizálása cikkben írtam.
Mekkora teljesítményhatása van az eBPF-nek?
A leggyakoribb félelem: „az eBPF mindent lassít". A valóság azért árnyaltabb. Egy jól megírt eBPF program a kernel-mód belépés után néhány száz nanoszekundumot fut. A syscall-szintű mérés tipikusan 200–800 ns extra latency-t mutat, ami egy átlagos webszerver-workloadon mérhetetlen.
Reális, általam mért éles számok (Falco modern_ebpf, default ruleset, ~5000 syscall/s/node):
CPU overhead: 1.8–3.5% (8-magos szerver, Xeon Gold 6338)
Memória: ~150 MB RSS a Falco userspace daemonra; az eBPF map-ek további ~30 MB-ot foglalnak
Tail latency p99: +120 µs (ha a kimenet syslog/journal felé megy)
Két dolog tudja eldobni ezt: (1) ha túl bőkezű szabályokat írsz (pl. minden open()-t naplózol, kontextusfilter nélkül), (2) ha a map mérete kicsi és állandóan evict-elődik. A bpftool prog profile parancs CPU ciklusban mutatja meg, melyik program drága. Éles bevezetés előtt mindig ezzel mérek.
Éles üzemi tippek és buktatók
Pár dolog, amit ne kelljen újra megtanulni:
Verifier limit. A kernel verifier 2026-ban is ~1M instrukciót enged programonként. Ha komplex policyt írsz, oszd több programra és láncold tail call-lal.
CO-RE vs kmod. A modern_ebpf driver minden 5.8+ kernelen működik kompilálás nélkül, így kerüld a régi kernel modult, mert az minden kernel-frissítésnél újrafordítást kíván.
Signing. A Falco és Tetragon image-ek cosign-nal aláírtak; admission controllerrel (Kyverno, OPA Gatekeeper) követeld meg az aláírt image-eket, ne csak az alkalmazás workloadon, az obszerváción is.
Kill switch. Tetragon prevenció mellé mindig készíts egy „break-glass" TracingPolicy-t, amellyel egy parancsra az összes Sigkill akció Audit-té válik. Egy false-positive éjjel 3-kor nem szórakoztató.
Naplótömeg. Az eBPF nem ingyen termel logot. Egy közepes K8s clusterben akár 50–200 MB/perc esemény is kijöhet, így előzetes Loki/Elastic kapacitásbecslés kötelező.
CVE-tracking. A BPF verifier maga is volt már sebezhetőség forrása (pl. CVE-2024-26581, out-of-bounds írás nft_set elemnél BPF útvonalon). Tartsd naprakészen a kernelt, főleg ha kernel.unprivileged_bpf_disabled=0.
Őszintén szólva, az eBPF-alapú futásidejű biztonság ma már nem hype, hanem a Linux-szerverüzemeltetés egyik alaprétege. A kezdeti tanulási görbe meredek (verifier, hookok, debug-szokások mind újak), de az első jól sikerült TracingPolicy után, ami megfogott egy próbálkozást éles forgalom közben, megéri.
Gyakran ismételt kérdések
Mi az eBPF és miért fontos a Linux-biztonságnál?
Az eBPF a Linux kernel egy verifikált bytecode-futtatója, amellyel kernelmodul írása nélkül lehet syscall-, hálózati- és LSM-eseményekre kötni programokat. Biztonsági szempontból ez azt jelenti, hogy a detekció és a beavatkozás a kernelben, közvetlenül a védendő művelet helyén történik — gyorsan és megkerülhetetlenül.
Mi a különbség a Falco és a Tetragon között?
A Falco felhasználói térben fut és csak detektál (riasztásokat ad ki), a Tetragon viszont a kernelben dönt és képes leállítani a sértő folyamatot (Sigkill) vagy felülírni a syscall visszatérési értékét. Falco gazdagabb szabálykönyvtárral jön, Tetragon viszont Kubernetes-natív CRD-vel és valós prevencióval.
Helyettesíti az eBPF futásidejű biztonság a SELinuxot vagy az AppArmort?
Nem. Az LSM BPF a SELinux/AppArmor mellett fut, ugyanazon hookokon. A klasszikus MAC-rendszerek deklaratív és kiforrott politikát adnak, az eBPF-alapú eszközök pedig dinamikus, eseményalapú szabályokat. Éles környezetben mindkettőt érdemes együtt használni.
Milyen kernelverzió kell az eBPF-alapú LSM-hez?
A BPF LSM minimum a Linux 5.7-ben jelent meg, de éles használatra a 6.x sorozat (különösen a 6.12 LTS) ajánlott a hookok teljes lefedettsége és a verifier-javítások miatt. A kernelt CONFIG_BPF_LSM=y-nal és a lsm=...,bpf parancssori paraméterrel kell indítani.
Mennyi CPU-t fogyaszt az eBPF futásidejű biztonság?
Jól megírt szabályokkal 1–4% CPU overhead tipikus, syscallonként néhány száz nanoszekundum latency-vel. A költség akkor szalad meg, ha túl bőkezű szabályok (minden open()) vagy alulméretezett BPF map-ek vannak; a bpftool prog profile-lal érdemes mérni éles bevezetés előtt.
Gyakorlati útmutató a SELinux és AppArmor MAC-keretrendszerek telepítéséhez, konfigurálásához és hibaelhárításához. Egyedi szabályzatok írása, konténerbiztonsági integráció és a két rendszer összehasonlítása.
