Falco cu eBPF pe Linux în 2026: Detectare Runtime pentru Containere și Kernel

Actualizat: 22 august 2026

Falco este motorul de detectare runtime al proiectului Cloud Native Computing Foundation (CNCF, absolvent din 2024) care instrumentează syscall-urile kernelului Linux printr-o sondă eBPF modernă (CO-RE, libbpf) și le evaluează în timp real față de un set de reguli YAML, generând alerte pentru comportament suspect în containere, pod-uri și pe host. În 2026, versiunea stabilă 0.44 (lansată pe 26 mai) a eliminat sonda eBPF veche și modulul gRPC, iar sonda modern_ebpf a devenit standardul de facto pentru orice kernel Linux ≥ 5.8. Ghidul de față acoperă instalarea pe Ubuntu 24.04, scrierea regulilor, integrarea cu Falcosidekick și Talon, plus tuning-ul overhead-ului în producție.

• Falco 0.44 (mai 2026) folosește implicit sonda modernă eBPF bazată pe libbpf CO-RE și necesită kernel Linux ≥ 5.8 cu BTF expus și BPF ring buffer.
• Instalarea pe Ubuntu 24.04 se face din repository-ul oficial download.falco.org/packages/deb; driverul se selectează în timpul apt install.
• Regulile Falco sunt YAML cu câmpurile rule, condition, output, priority și tags; se pot mapa direct pe tehnici MITRE ATT&CK.
• Falco detectează, nu blochează. Pentru răspuns automat (kill pod, NetworkPolicy, Lambda) folosiți Falco Talon; pentru fan-out către SIEM sau Slack, Falcosidekick.
• Overhead tipic în producție: 1–3% CPU per nod, sub 1% RAM; scalează cu volumul de syscall-uri, nu cu numărul regulilor.
• În Kubernetes se instalează ca DaemonSet via Helm chart falcosecurity/falco v4.x, cu operatorul dedicat recomandat din 2026.

Ce este Falco și ce face concret pe Linux

Falco e un motor de detectare a intruziunilor la nivel de syscall, scris în C++, care rulează ca un daemon user-space și primește evenimente kernel printr-un driver (implicit, sonda modernă eBPF). Nu e un firewall și nu e un SIEM. Sarcina lui este să transforme fluxul brut de openat(), execve(), connect(), ptrace(), setuid() și alte apeluri într-un flux de alerte structurate pe baza unui limbaj de reguli declarativ.

În practică, Falco răspunde la trei clase de întrebări operaționale pe care frameworkul auditd le rezolvă doar parțial, și cu overhead mai mare: „ce shell-uri se execută în containerele mele?”, „cine scrie în /etc/shadow pe nodurile de producție?” și „ce proces face connect(2) către un IP suspect?”. Răspunsurile vin sub formă de linii JSON sau text către stdout, syslog, fișier sau HTTP, cu latență tipică sub 20 ms de la evenimentul kernel până la alertă.

Trei elemente definesc identitatea Falco în ecosistemul de securitate din 2026: proiectul este absolvent CNCF (același nivel ca Kubernetes sau Prometheus), licența este Apache 2.0, iar mentenanța este condusă de Sysdig cu contribuții semnificative de la Red Hat, IBM și AWS. Alertele Falco nu opresc atacul singure. Pentru enforcement folosiți Talon sau, în paralel, controale kernel precum Linux Security Modules (LSM).

Cerințe kernel și drivere disponibile în 2026

În versiunea 0.44 rămân trei drivere posibile: modern_ebpf (implicit, integrat în binarul Falco), kmod (modul kernel construit cu DKMS) și, pentru medii extrem de restrictive, capturi offline din fișiere .scap. Sonda eBPF veche, bazată pe BPF classic fără CO-RE, a fost eliminată în 0.44.0 pentru a reduce suprafața de mentenanță. Detalii complete în changelog-ul oficial Falco 0.44.0.

Cerințe pentru sonda modernă eBPF

• Kernel Linux ≥ 5.8 (ring buffer BPF introdus în v5.8, iterator BPF stabilizat în v5.11).
• BTF (BPF Type Format) expus, adică /sys/kernel/btf/vmlinux prezent (obligatoriu pentru CO-RE).
• Capabilitățile CAP_SYS_ADMIN, CAP_BPF și CAP_PERFMON pentru procesul Falco.
• Arhitecturi suportate: x86_64 și aarch64.

Verificarea rapidă a suportului pe hostul curent:

uname -r
ls /sys/kernel/btf/vmlinux
bpftool feature probe kernel | grep -E "ringbuf|iterator"

Instalare Falco pe Ubuntu 24.04 pas cu pas

Ubuntu 24.04 LTS (Noble Numbat) livrează kernel 6.8, deci sonda modernă eBPF funcționează out-of-the-box. Instalarea din repository-ul oficial, așa cum e descrisă în documentația oficială de pachete Falco, ia sub cinci minute pe un sistem curat. Am rulat același flux la trei clienți diferiți luna trecută și de fiecare dată promptul debconf pentru driver a fost singurul lucru care putea rata un pipeline automatizat, așa că îl pre-selectăm mai jos.

Adăugarea repository-ului și cheii GPG

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 update

Instalarea propriu-zisă

# Pre-selectăm driverul modern eBPF pentru a evita promptul interactiv
echo "falco falco/driver_choice select Modern eBPF" | sudo debconf-set-selections

sudo DEBIAN_FRONTEND=noninteractive apt install -y falco

sudo systemctl enable --now falco
sudo systemctl status falco --no-pager

Un serviciu Falco pornit corect afișează în jurnal linia Opening 'syscall' source with modern BPF probe. Verificați cu journalctl -u falco -n 50. Prima alertă apare de obicei imediat, pentru că regulile implicite din /etc/falco/falco_rules.yaml detectează evenimente comune precum scriere în binare de sistem sau shell-uri lansate din procese neobișnuite.

Cum funcționează sonda modernă eBPF în Falco

Sonda modern_ebpf este un program eBPF de tip BPF_PROG_TYPE_TRACEPOINT compilat cu libbpf și tehnica CO-RE (Compile Once, Run Everywhere). Introducerea în Falco 0.35 (blogul Falco Modern BPF descrie decizia arhitecturală) și devenirea implicită în 0.40 au rezolvat problema principală a sondelor vechi: dependența de headere kernel la runtime.

La pornire, sonda este încărcată în kernel de user-space prin bpf(BPF_PROG_LOAD, ...), se atașează pe punctele de tracepoint sys_enter_* și sys_exit_* pentru syscall-urile monitorizate, iar evenimentele sunt scrise într-un BPF_MAP_TYPE_RINGBUF partajat per-CPU. libsinsp în user-space consumă ring buffer-ul cu un vpoll, îmbogățește evenimentul cu context (namespace-uri container, cgroups v2, uid resolver) și îl trimite motorului de reguli.

Avantajul concret față de modulul kernel: în cazul unui upgrade de kernel, sonda rămâne funcțională fără recompilare, pentru că BTF-ul target este citit la runtime și tipurile struct-urilor kernel sunt rezolvate dinamic. În cazul modulului DKMS, orice patch minor de kernel declanșează rebuild și, ocazional, incompatibilități. Am pățit exact asta pe un cluster RHEL 8 acum doi ani, când o actualizare de securitate a lăsat două noduri fără sondă timp de o oră; cu modern_ebpf problema pur și simplu nu apare.

Ce syscall-uri monitorizează implicit

Setul minim în 0.44 include: execve, execveat, clone3, openat, openat2, connect, accept4, setuid, setgid, ptrace, chmod, fchmodat, unlink, unlinkat și mount. Setul complet e configurabil prin secțiunea base_syscalls din falco.yaml. Dezactivarea celor pe care nu le folosiți reduce overhead-ul semnificativ.

Cum scriu reguli Falco personalizate în YAML

O regulă Falco are formă declarativă cu cinci câmpuri obligatorii: rule, desc, condition, output, priority. Prioritățile respectă convenția syslog RFC 5424: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY. Documentația exhaustivă a limbajului este la elementele de bază ale regulilor Falco.

Exemplu practic: shell în container

# /etc/falco/falco_rules.local.yaml
- macro: container
  condition: container.id != host

- list: shell_binaries
  items: [bash, sh, zsh, csh, tcsh, ash, dash]

- rule: Shell Spawned in Container
  desc: Detectăm execuția unui shell interactiv într-un container
  condition: >
    spawned_process and
    container and
    proc.name in (shell_binaries)
  output: >
    Shell lansat în container (user=%user.name uid=%user.uid
    container=%container.name image=%container.image.repository
    shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution, T1059.004]

Testarea unei reguli fără a reporni serviciul se face cu falco --dry-run -r /etc/falco/falco_rules.local.yaml. Validarea sintactică strictă (introdusă în 0.44) refuză cheile necunoscute, deci o eroare tipografică precum conditon: declanșează un exit cod diferit de zero. Detaliul ăsta mi-a salvat câteva ore de debugging după ce am copiat o regulă dintr-un gist vechi.

Filtre avansate cu comparatori de string-uri

Începând cu 0.44 sunt disponibili operatorii oneof, allof și anyof pentru compararea listelor de string-uri fără a scrie condiții cu or repetat:

- rule: Curl or Wget in Production Container
  condition: >
    spawned_process and
    container.image.repository startswith "myregistry/prod-" and
    proc.name oneof (curl, wget)
  output: "Fetch tool executat în producție (proc=%proc.name)"
  priority: NOTICE

Falcosidekick și Talon: alerte și răspuns automat

Motorul Falco emite alerte pe stdout, HTTP, syslog și fișier. Pentru rutarea către destinații reale (Slack, Microsoft Teams, PagerDuty, Elasticsearch, Loki, AWS SNS, Google Chat, S3 sau webhook-uri arbitrare) se folosește Falcosidekick, un proxy scris în Go care primește evenimentele pe un endpoint HTTP local și le multiplexează către peste 50 de output-uri configurabile.

# /etc/falco/falco.yaml (extras)
http_output:
  enabled: true
  url: "http://127.0.0.1:2801/"
  user_agent: "falcosecurity/falco"

Falcosidekick în sine se instalează ca binar systemd sau container, cu configurare prin variabile de mediu:

SLACK_WEBHOOKURL=https://hooks.slack.com/services/T00/B00/XXX
SLACK_MINIMUMPRIORITY=warning
ELASTICSEARCH_HOSTPORT=https://elastic.internal:9200
ELASTICSEARCH_INDEX=falco

Pentru răspuns activ, nu doar alertare, proiectul Falco Talon este engine-ul de response lansat oficial de Falcosecurity. Talon consumă evenimentele de la Falcosidekick și rulează actionners: kubernetes:terminate pentru a șterge un pod, kubernetes:networkpolicy pentru a bloca traficul unui deployment, aws:lambda pentru orice logică custom, sau calico:networkpolicy pentru medii care folosesc Calico.

# Exemplu de regulă Talon
- action: Terminate Pod
  actionner: kubernetes:terminate
  parameters:
    grace_period_seconds: 5
  match:
    rules:
      - Shell Spawned in Container
    priority: WARNING

Falco pe Kubernetes: DaemonSet, plugin-uri, audit log

În Kubernetes, Falco se instalează prin Helm chart-ul oficial falcosecurity/falco versiune 4.x, care creează un DaemonSet cu un pod privileged per nod. Fiecare pod încarcă sonda eBPF în kernelul nodului și monitorizează toate syscall-urile din toate containerele de pe acel nod, indiferent de runtime (containerd, CRI-O, Docker).

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

helm install falco falcosecurity/falco \
  --namespace falco --create-namespace \
  --set driver.kind=modern-bpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

Începând cu 0.32.0, sursa de evenimente Kubernetes Audit Log a fost mutată din nucleul Falco într-un plugin separat (k8saudit). Aceasta permite Falco să evalueze reguli pe activitatea API server-ului Kubernetes, de exemplu creări de ClusterRoleBinding către cluster-admin, sau execuții kubectl exec în namespace-uri protejate.

Operatorul Falco

Pentru medii mari se recomandă operatorul dedicat, cu CRD-urile Falco, FalcoRule și FalcoPlugin. Regulile devin astfel resurse Kubernetes versionate în Git, iar GitOps (Argo CD, Flux) le poate reconcilia automat pe toate cluster-ele. Documentația de instalare Kubernetes este la ghidul Falco pentru Kubernetes.

Falco vs Wazuh vs Tetragon: când folosiți fiecare

Trei instrumente domină în 2026 detectarea la nivel de host pe Linux, dar rezolvă probleme diferite. Următorul tabel sintetizează diferențele arhitecturale, nu redundanța: cele trei coexistă frecvent în același SOC.

Dimensiune	Falco 0.44	Tetragon 1.x	Wazuh 4.x
Sursa principală	Syscalls prin eBPF	Syscalls + LSM prin eBPF	Log-uri, FIM, syscall (auditd)
Enforcement	Nu (doar detecție)	Da, sincron (SIGKILL kernel)	Active response scripts
Limbaj de reguli	YAML declarativ	CRD TracingPolicy	XML + reguli decoders
Rulează în K8s	DaemonSet oficial	DaemonSet (Cilium optional)	Agent per nod
Compliance built-in	Prin plugin-uri	Limitat	PCI DSS, HIPAA, GDPR out-of-box
Overhead tipic	1–3% CPU	<1% CPU	3–8% CPU
Statut CNCF	Graduated	Incubating	Nu (open source Wazuh Inc.)

Ca ordine de decizie: dacă aveți un stack Kubernetes și vreți enforcement sincron, Tetragon e alegerea logică pentru căile critice, plus Falco pentru breadth-ul regulilor comunitare. Dacă aveți un mix de VM-uri, containere și cerințe stricte de compliance (PCI, HIPAA), Wazuh acoperă mai bine partea de audit, iar Falco vine ca strat suplimentar de runtime detection.

Overhead, drop-uri și tuning în producție

Overhead-ul Falco cu sonda modernă eBPF în producție este sub 3% CPU per nod pentru workload-uri tipice de aplicații web, până la 5% pentru workload-uri intensive de I/O (baze de date, message broker). Memoria per instanță se plasează sub 200 MB. Numărul de reguli aproape nu contează, costul dominant fiind captura evenimentelor, nu evaluarea.

Metrici pe care să le monitorizați

• falco_events_dropped_total: dacă crește, ring buffer-ul eBPF nu ține pasul; măriți engine.modern_bpf.buf_size_preset.
• falco_cpu_usage: expus pe 127.0.0.1:8765/metrics când metrics.enabled: true.
• falco_num_evts: rata de evenimente procesate per secundă.

Reguli pentru reducerea zgomotului

Alertele fals-pozitive sunt problema principală pentru un deployment Falco proaspăt. Onest vorbind, primele două săptămâni după instalare sunt aproape întotdeauna despre a filtra zgomot. Strategiile care funcționează în producție, în ordinea eficacității:

1. Dezactivați regulile pe care nu le folosiți în falco_rules.local.yaml cu enabled: false (suprascriu regulile din pachetul oficial cu același nume).
2. Extindeți macro-urile user_known_*, de exemplu user_known_shell_spawn_binaries pentru procese legitime de deployment care lansează shell-uri.
3. Restrângeți condițiile prin filtre pe container.image.repository pentru a exclude namespace-urile de sistem (kube-system, monitoring).
4. Configurați base_syscalls.custom_set pentru a monitoriza doar syscall-urile relevante pentru regulile active.

Pentru colectarea complementară a evenimentelor de autentificare, care nu apar la nivel de syscall, combinați Falco cu Fail2ban pentru protecție împotriva atacurilor brute force SSH, astfel încât nivelul de aplicație și nivelul de kernel să se acopere reciproc.

Întrebări frecvente

Ce versiune de kernel Linux este necesară pentru Falco 0.44?

Minim 5.8 pentru sonda modernă eBPF, cu BTF expus în /sys/kernel/btf/vmlinux. Pentru kerneluri mai vechi (RHEL 8, Debian 10) rămâne disponibil driverul kmod, cu costul pierderii CO-RE și necesitatea instalării linux-headers.

Falco blochează atacurile sau doar generează alerte?

Falco în sine doar detectează și alertează, nu face enforcement. Pentru răspuns activ (kill pod, aplicare NetworkPolicy, invocare Lambda) folosiți proiectul separat Falco Talon, care consumă alertele prin Falcosidekick și execută actionners configurabili.

Poate Falco să ruleze fără privilegii de root?

Nu. Falco necesită capabilitățile CAP_SYS_ADMIN, CAP_BPF și CAP_PERFMON pentru a încărca programe eBPF în kernel. În Kubernetes se rulează ca pod privileged: true sau cu securityContext care expune capabilitățile menționate.

Care este diferența între Falco și AppArmor sau SELinux?

AppArmor și SELinux sunt module LSM care aplică politici de control al accesului obligatoriu în kernel și blochează acțiuni interzise sincron. Falco observă syscall-urile deja executate și generează alerte pentru comportamente suspecte. Sunt complementare: LSM previne, Falco detectează, iar Talon adaugă răspuns.

Cum trimit alertele Falco în Slack?

Instalați Falcosidekick, configurați output-ul HTTP din Falco către http://127.0.0.1:2801/ și setați variabila de mediu SLACK_WEBHOOKURL în serviciul Falcosidekick. Filtrați cu SLACK_MINIMUMPRIORITY=warning pentru a evita spamul din alertele de nivel INFO.

Funcționează Falco pe Kubernetes gestionat (EKS, GKE, AKS)?

Da, cu sonda modernă eBPF pe toate cele trei platforme. EKS folosește kernel Amazon Linux 2023 ≥ 6.1, GKE Container-Optimized OS ≥ 6.6, iar AKS Ubuntu 22.04/24.04 ≥ 5.15. Instalați prin Helm chart-ul oficial cu driver.kind=modern-bpf.