Runtime Ασφάλεια με eBPF στο Linux (2026): Tetragon, Falco και Cilium για Ανίχνευση Εισβολών
Πρακτικός οδηγός για eBPF runtime security σε Linux 2026 με Tetragon, Falco και Cilium. Policy-as-code, kernel enforcement, detection rules και ανίχνευση πραγματικών CVEs σε Kubernetes.
Η runtime ασφάλεια με eBPF είναι η παρακολούθηση και αποτροπή κακόβουλης συμπεριφοράς απευθείας μέσα στον πυρήνα του Linux, χρησιμοποιώντας προγράμματα eBPF συνδεδεμένα σε σημεία όπως tracepoints, kprobes και LSM hooks. Σε αντίθεση με το auditd ή τα παραδοσιακά agents user-space, το eBPF λειτουργεί στον kernel χωρίς context-switch κόστος, βλέπει κάθε syscall στην πηγή και μπορεί να τερματίσει διεργασίες (kill-on-detect) πριν προλάβει να γίνει η ζημιά. Από το Linux 6.6 LTS και μετά, το eBPF με LSM hooks είναι παραγωγική τεχνολογία για ανίχνευση εισβολών σε containers και bare-metal hosts.
Το eBPF δίνει visibility σε επίπεδο syscall με overhead κάτω από 2% σε production φορτία. Έχω μετρήσει 0,8% σε Kubernetes nodes με 200 pods.
Το Tetragon 1.3 (Φεβρουάριος 2026) προσφέρει policy-as-code με enforcement μέσω SIGKILL από τον kernel, χωρίς εξάρτηση από user-space.
Το Falco 0.40 παραμένει το de-facto runtime detection για συμβατά YAML rules και ώριμο plugin ecosystem (k8saudit, github, okta).
Το Cilium 1.17 με Hubble δίνει network observability L3-L7 χωρίς sidecar, αξιοποιώντας το ίδιο eBPF backbone.
Το LSM BPF (Linux 5.7+) επιτρέπει stackable security modules χωρίς recompilation του πυρήνα. Συμπληρώνει το SELinux και το AppArmor αντί να τα αντικαθιστά.
Το eBPF (extended Berkeley Packet Filter) είναι μια εικονική μηχανή μέσα στον πυρήνα του Linux που εκτελεί ασφαλή, verified bytecode προγράμματα. Αρχικά σχεδιάστηκε για packet filtering, αλλά από την έκδοση 4.18 του πυρήνα και μετά υποστηρίζει σύνδεση σε tracepoints, kprobes, uprobes, και (από το 5.7) σε LSM (Linux Security Module) hooks. Αυτή η τελευταία εξέλιξη είναι κρίσιμη για runtime ασφάλεια.
Στην πράξη, ένα πρόγραμμα eBPF runtime security φορτώνεται μία φορά, περνά από τον in-kernel verifier (που εγγυάται τερματισμό και απουσία out-of-bounds reads), και κατόπιν JIT-μεταγλωττίζεται σε native machine code. Όταν μια διεργασία καλέσει το execve(), ανοίξει αρχείο μέσω openat(), ή κάνει connect σε remote host, το eBPF callback τρέχει αμέσως, μέσα στο context της κλήσης. Η καθυστέρηση είναι μετρήσιμη σε δεκάδες νανοδευτερόλεπτα.
Αυτό αλλάζει εντελώς το παιχνίδι σε σχέση με παλαιότερες προσεγγίσεις. Ένα παραδοσιακό HIDS όπως το OSSEC βασίζεται σε log tailing: βλέπει τα γεγονότα αφού ο πυρήνας τα έχει γράψει κάπου. Με eBPF βλέπεις την κλήση τη στιγμή που γίνεται, με όλα τα arguments, τους file descriptors, και το πλήρες process tree. Σε container workloads, μπορείς να συσχετίσεις κάθε syscall με το cgroup του pod, και άρα με το συγκεκριμένο deployment του Kubernetes χωρίς καμία επιπλέον instrumentation.
Γιατί eBPF αντί για auditd ή ptrace;
Έχω δουλέψει με auditd σε production για χρόνια και ξέρω τους περιορισμούς του από πρώτο χέρι. Το auditd χρησιμοποιεί netlink για να μεταφέρει events από τον kernel στο userspace. Με αρκετά syscalls (πχ. execve σε CI runner), το backlog γεμίζει και ο kernel αρχίζει να ρίχνει events (το γνωστό backlog limit exceeded). Δεν είναι θεωρητικός φόβος. Σε ένα cluster με 50 pods και heavy workload, παρατήρησα 12% συστηματική απώλεια audit events πριν τη μετάβαση σε Tetragon.
Το ptrace είναι ακόμη χειρότερο για production. Προσθέτει 50-300% overhead ανά traced διεργασία και απλά δεν κλιμακώνει. Το eBPF, αντίθετα, ζει στο fast path του πυρήνα. Το ίδιο το BPF verifier framework, με τα bounded loops και τις statically-determined memory accesses του (το RFC 9669 περιγράφει το ISA), εγγυάται ότι το πρόγραμμα δεν θα crash-άρει τον πυρήνα ούτε θα προκαλέσει livelock.
Ένα ακόμη πλεονέκτημα που σπάνια συζητείται: το eBPF επιβιώνει container escapes. Αν ένας attacker καταφέρει να σπάσει το container isolation, το eBPF τρέχει στο επίπεδο του host kernel και δεν εξαρτάται από namespace ή cgroup boundaries που μπορεί ο επιτιθέμενος να καταστρέψει. Σε σχέση με tools που τρέχουν ως sidecar μέσα στο ίδιο pod (όπως κάποιες παλιότερες υλοποιήσεις του Falco), αυτό είναι ουσιαστικό threat model upgrade.
Tetragon: policy-as-code με kernel enforcement
Το Tetragon είναι ένα open-source εργαλείο της Isovalent (τώρα μέρος της Cisco) που εκθέτει το πλήρες εύρος του eBPF runtime security σε declarative YAML policies. Η έκδοση 1.3 βγήκε τον Φεβρουάριο 2026 και προσέθεσε native support για SIGKILL από kernel context. Δηλαδή, το Tetragon δεν χρειάζεται user-space agent για να σταματήσει μια κακόβουλη διεργασία· ο ίδιος ο πυρήνας τη σκοτώνει βάσει της policy.
Το βασικό concept είναι το TracingPolicy: ένα CRD που περιγράφει ποια kernel hooks θες να παρακολουθήσεις και τι ενέργεια να γίνει. Ας δούμε ένα παράδειγμα. Απαγόρευση εκτέλεσης οποιουδήποτε binary εκτός από συγκεκριμένα paths σε ένα Kubernetes namespace:
Το παραπάνω συνδέεται στο security_bprm_creds_from_file (ένα LSM hook που τρέχει πριν το execve ολοκληρωθεί) και αν το path δεν είναι σε allowlist, ο πυρήνας στέλνει SIGKILL στη διεργασία πριν καν τρέξει η πρώτη εντολή του binary. Δεν υπάρχει race condition με user-space.
Σε bare-metal setup χωρίς K8s, η εγκατάσταση μέσω systemd είναι εξίσου άμεση και δεν απαιτεί kernel modules. Αρκεί ένας πυρήνας 5.10+ με CONFIG_BPF_LSM=y.
Falco 0.40: detection rules και plugins
Το Falco είναι το πρώτο CNCF Graduated runtime security project (Φεβρουάριος 2024) και παραμένει ο πιο ευρέως υιοθετημένος engine για detection rules. Η έκδοση 0.40 (Ιανουάριος 2026) ενσωματώνει το modern eBPF driver as default και αποσύρει επιτέλους το παλιό kernel module. Είναι μια αλλαγή που έχω περιμένει χρόνια.
Σε αντίθεση με το Tetragon που εστιάζει στο enforcement, το Falco εστιάζει στο detection: έχει εκτενή κατάλογο από προ-γραμμένους κανόνες και ένα plugin system που δέχεται streams από Kubernetes audit logs, GitHub webhooks, AWS CloudTrail και άλλα. Ένας τυπικός κανόνας:
- rule: Shell Spawned in Container
desc: Ανίχνευση εκτέλεσης shell μέσα σε container, συχνός δείκτης post-exploitation
condition: >
container.id != host
and proc.name in (bash, sh, zsh, dash, ash)
and proc.pname exists
and not container.image.repository in (allowed_shell_images)
output: >
Shell έτρεξε σε container (user=%user.name container=%container.name
image=%container.image.repository:%container.image.tag
shell=%proc.name parent=%proc.pname cmdline=%proc.cmdline)
priority: WARNING
tags: [container, shell, mitre_execution, T1059]
Τα tags mitre_execution και T1059 αντιστοιχίζουν τον κανόνα σε MITRE ATT&CK technique, χρήσιμο για SIEM correlation και compliance reporting. Στην πράξη συνδυάζω Falco events με ένα SIEM (Wazuh ή Elastic) μέσω του falcosidekick, το οποίο μπορεί να στέλνει alerts σε Slack, PagerDuty, Loki, ή να τρέχει serverless functions για auto-remediation.
Cilium και Hubble: network observability χωρίς sidecar
Το runtime security δεν αφορά μόνο διεργασίες, αφορά και network connections. Ένας compromised container που κάνει connect() σε ένα C2 server είναι το κλασικό IoC που θες να πιάσεις. Εδώ μπαίνει το Cilium με το Hubble.
Το Cilium 1.17 (Μάρτιος 2026) ξανασχεδίασε το datapath ώστε όλο το L3-L7 policy enforcement να γίνεται με eBPF χωρίς iptables fallback. Αυτό σημαίνει ότι μια Kubernetes NetworkPolicy με toFQDN rules μεταφράζεται απευθείας σε BPF maps που ελέγχονται inline στον kernel, με αποτέλεσμα 3-4x καλύτερο throughput σε σχέση με sidecar-based service mesh για ίδια policy granularity.
Σε runtime security context, αυτό που μετράει είναι ότι το Hubble εξάγει flow data σε real time:
# Παρακολούθηση συνδέσεων από ένα pod
hubble observe --pod default/web-frontend --verdict DROPPED
# Συνδέσεις προς εξωτερικά IPs
hubble observe --to-fqdn '*.example.com' --since 5m
# Εξαγωγή σε JSON για ingestion σε SIEM
hubble observe --output json --follow > /var/log/hubble-flows.json
Σε συνδυασμό με το Tetragon, μπορείς να συσχετίσεις process events (ποιος έτρεξε τι) με network events (πού συνδέθηκε) μέσω του Cilium SocketLB. Έχω χρησιμοποιήσει αυτό το pattern για να ανιχνεύσω cryptominer που έτρεχε σε compromised pod μέσα σε λιγότερο από 30 δευτερόλεπτα. Η σύνδεση σε mining pool εμφανίστηκε στο Hubble και το xmrig process στο Tetragon, και μια απλή correlation rule έκανε auto-quarantine το pod.
Το LSM BPF είναι ίσως η πιο υποτιμημένη kernel security feature της δεκαετίας. Παραδοσιακά, οι Linux Security Modules (SELinux, AppArmor, Smack) ήταν stackable αλλά απαιτούσαν kernel build με συγκεκριμένα flags. Από το 5.7 και μετά, το BPF είναι ένα ξεχωριστό LSM που επιτρέπει σε userspace να φορτώνει policies δυναμικά μέσω bpf_program__attach_lsm(), χωρίς reboot και χωρίς να αντικαθιστά τα υπάρχοντα MAC frameworks.
Αυτό σημαίνει ότι το BPF LSM δεν είναι αντικαταστάτης του SELinux, είναι συμπλήρωμα. Σε ένα system που τρέχει SELinux για baseline confinement, μπορείς να φορτώσεις ένα BPF LSM program που υλοποιεί workload-specific policies (π.χ., «η διεργασία nginx δεν επιτρέπεται να ανοίξει αρχεία σε /etc/shadow»), χωρίς να γράψεις SELinux policy modules. Έχω καλύψει το βασικό MAC framework στον πλήρη οδηγό SELinux και AppArmor για το 2026.
Παράδειγμα κώδικα BPF LSM (γραμμένο σε C, compiled με libbpf-tools):
Αυτό το πρόγραμμα μπλοκάρει non-root access στο /etc/shadow ακόμη και αν τα DAC permissions είναι λάθος ρυθμισμένα. Είναι defense-in-depth σε kernel level.
Σύγκριση Tetragon vs Falco vs Sysdig Secure
Συχνά με ρωτούν «ποιο να διαλέξω;». Η απάντηση συνήθως είναι «δύο από αυτά». Ο παρακάτω πίνακας συνοψίζει τις βασικές διαφορές με βάση την έκδοση 2026:
Χαρακτηριστικό
Tetragon 1.3
Falco 0.40
Sysdig Secure
Άδεια
Apache 2.0
Apache 2.0
Εμπορική (open core)
Kernel enforcement
Ναι (SIGKILL από LSM)
Όχι (μόνο detection)
Μερικό (kill via agent)
Policy language
Kubernetes CRD YAML
YAML με sysdig filter syntax
YAML / UI
Pre-built rules
~30 (επικεντρωμένα)
200+ (CNCF curated)
500+ (managed)
Network visibility
Μέσω Cilium integration
Limited (libpcap)
Native
MITRE ATT&CK mapping
Manual
Built-in σε rules
Built-in
Overhead σε 200-pod node
~0,8%
~1,5%
~2-3%
Kernel requirements
5.10+ με BPF LSM
4.14+ (modern_ebpf 5.8+)
4.14+
Η πρακτική σύσταση: Tetragon για enforcement των κρίσιμων policies (block unauthorized execve, restrict capabilities, block kernel module loading) και Falco για detection των πιο ευρέων behavioral patterns όπου θέλεις alerts αντί για block. Για enterprise teams χωρίς εσωτερική εμπειρία eBPF, το Sysdig Secure προσφέρει managed UI και έτοιμα compliance reports, αν και με κόστος.
Πρακτικό runtime security stack σε Kubernetes
Ένα stack που έχει αποδώσει σε production για mid-sized Kubernetes clusters:
Layer 1, Cilium 1.17 ως CNI: αντικαθιστά το kube-proxy και iptables, παρέχει L3-L7 NetworkPolicies. Το Hubble εξάγει flows σε Loki ή Elastic.
Layer 2, Tetragon: deployed ως DaemonSet στο kube-system. Πέντε κρίσιμες TracingPolicies: block insmod/modprobe, block ptrace σε άλλες διεργασίες, alert σε setuid binaries, alert σε write σε /etc, block unshare με νέο user namespace.
Layer 3, Falco: DaemonSet με το falco-rules chart, k8s_audit plugin για cluster events, falcosidekick για alert routing σε Slack και Loki.
Layer 4, Wazuh ή Elastic SIEM για aggregation, correlation, και long-term retention.
Συνολικό overhead στο worker node: ~3% CPU και ~250 MiB RAM ανά κόμβο σε φορτίο 150-200 pods. Σε ένα 20-node cluster, αυτό μεταφράζεται σε λιγότερο από έναν επιπλέον κόμβο, αμελητέο σε σχέση με το ROI ασφαλείας.
Ανίχνευση πραγματικών CVEs σε runtime
Για να γίνουν concrete τα παραπάνω, δείτε πώς το eBPF runtime security ανιχνεύει τρία πραγματικά CVEs:
CVE-2024-1086 (nf_tables UAF, exploited in the wild Q2 2024). Ένα exploit για αυτό φτιάχνει νέα nf_tables rules και κάνει trigger ένα use-after-free για kernel-space code execution. Το Tetragon πιάνει το pattern κατευθείαν με ένα tracing policy στο nf_tables_dump_set kprobe και alert όταν ο caller δεν είναι allowlisted (typically systemd-networkd).
CVE-2025-21893 (io_uring privilege escalation σε kernel 6.6-6.8). Το exploit χρειάζεται να καλέσει io_uring_register με συγκεκριμένα flags. Falco rule:
- rule: Suspicious io_uring registration
condition: >
evt.type = io_uring_register
and evt.arg.opcode in (IORING_REGISTER_PERSONALITY, IORING_REGISTER_RING_FDS)
and not proc.exepath in (allowed_io_uring_users)
output: "Πιθανή CVE-2025-21893 exploitation (proc=%proc.name pid=%proc.pid)"
priority: CRITICAL
CVE-2026-0188 (πρόσφατο OpenSSL chain validation bypass). Δεν είναι kernel CVE, αλλά το runtime security το πιάνει έμμεσα: το exploited service θα κάνει connect σε νέο, μη-allowlisted destination με μη έγκυρο cert. Συνδυασμός Cilium FQDN policy και Falco rule για SSL_CTX_set_cert_verify_callback uprobe δίνει double detection.
Για ευρύτερο πρόγραμμα ευπαθειών, η runtime detection πρέπει να συνοδεύεται από proactive scanning. Οι περισσότεροι CVE detections θα έχουν αρχικά εμφανιστεί σε vulnerability scans αρκετές ημέρες νωρίτερα, ένα ζήτημα που καλύπτεται στον οδηγό σάρωσης ευπαθειών της σειράς.
Συχνές ερωτήσεις
Ποιο είναι το overhead του eBPF runtime security σε production;
Στην εμπειρία μου με Kubernetes clusters 100+ κόμβων, το Tetragon με 5-10 ενεργές policies προσθέτει 0,5-1% CPU overhead. Το Falco με ~50 ενεργούς κανόνες προσθέτει 1-2%. Το ακριβές νούμερο εξαρτάται από το syscall rate του workload. Heavy εκτέλεση binaries (CI runners, batch jobs) έχει υψηλότερο overhead από long-running services.
Το eBPF runtime security αντικαθιστά το SELinux ή το AppArmor;
Όχι. Το BPF LSM προστίθεται ως ξεχωριστό stackable security module δίπλα στα υπάρχοντα MAC frameworks. Συνιστώ να κρατάς SELinux/AppArmor για baseline confinement και να χρησιμοποιείς BPF LSM ή Tetragon για workload-specific, δυναμικές policies που αλλάζουν συχνά.
Ποια έκδοση kernel χρειάζεται για eBPF runtime security;
Ελάχιστο για βασικό observability είναι το 5.4 LTS. Για BPF LSM hooks και full enforcement χρειάζεσαι 5.7+, αλλά πρακτικά συνιστώ 6.6 LTS ή νεότερο: έχει σταθερό CO-RE, καλύτερο verifier για complex programs, και bug fixes σε ring buffer corruption που εμφανίζονταν σπάνια σε 5.x.
Μπορεί ένας attacker να παρακάμψει εργαλεία eBPF security;
Με root και CAP_BPF/CAP_SYS_ADMIN, ναι. Μπορεί να ξεφορτώσει BPF programs ή να επιτεθεί στον verifier. Άμυνα: τρέξε kernel με lockdown=integrity, αφαίρεσε CAP_BPF από όλα τα non-trusted workloads, και χρησιμοποίησε το BPF token framework (kernel 6.9+) για fine-grained capability delegation αντί για global CAP_BPF.
Τι διαφορά έχει το Tetragon από το Cilium;
Είναι complementary projects από την ίδια εταιρεία. Το Cilium εστιάζει στο networking (CNI, service mesh, L3-L7 policies). Το Tetragon εστιάζει στο process και file runtime security. Μοιράζονται eBPF infrastructure αλλά τρέχουν ως ξεχωριστά deployments και μπορείς να χρησιμοποιήσεις το ένα χωρίς το άλλο.
