eBPF Security: Kernel-Level Runtime Protection
eBPF (Extended Berkeley Packet Filter) enables programmable, high-performance security monitoring directly in the Linux kernel. It powers modern runtime security tools like Falco, Tetragon, and Tracee for real-time threat detection, container security, and network policy enforcement without agent overhead.
eBPF Security: Kernel-Level Runtime Protection
eBPF (Extended Berkeley Packet Filter) has revolutionized security monitoring by enabling programmable, high-performance observation and enforcement directly in the Linux kernel. Traditional security monitoring requires kernel modules (risky) or heavy userspace agents (high overhead). eBPF provides a sandboxed, efficient way to hook kernel events—system calls, network packets, process execution, file operations—with minimal performance impact. It powers modern runtime security tools including Falco, Tetragon, Tracee, and Cilium for real-time threat detection, container security, compliance monitoring, and network policy enforcement.
To understand eBPF security properly, it helps to be familiar with eBPF fundamentals, Linux kernel concepts, runtime security, and container security.
┌─────────────────────────────────────────────────────────────────────────┐
│ eBPF Security Architecture │
├─────────────────────────────────────────────────────────────────────────┤
│ │
│ Userspace Kernel Space │
│ ┌─────────────────────────────────┐ ┌─────────────────┐ │
│ │ Security Tools (Falco, │ │ eBPF Programs │ │
│ │ Tetragon, Tracee, Cilium) │ │ (Attached to │ │
│ └───────────────┬─────────────────┘ │ kernel hooks)│ │
│ │ └────────┬────────┘ │
│ │ eBPF Maps │ │
│ │ (Events, Metrics, Config) │ │
│ │ ┌────────────▼────────┐│
│ │ │ Kernel Hook ││
│ │ │ Points: ││
│ │ │ • syscall ││
│ │ │ • kprobe/tracepoint││
│ │ │ • socket ││
│ │ │ • XDP/TC ││
│ │ └────────────────────┘│
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ Alerting & Response │ │
│ │ (SIEM, PagerDuty, Auto-remediate) │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────┘What Is eBPF Security?
eBPF security is the practice of using eBPF programs to monitor, detect, and respond to security threats at the kernel level. eBPF programs attach to kernel events: system calls, process execution, file access, network connections, and container operations. The eBPF verifier ensures programs are safe (no kernel crashes). Performance overhead is minimal (eBPF runs in kernel without context switching). eBPF security tools provide real-time visibility without modifying applications or deploying per-container agents.
- Kernel-Level Observability: Access to every system call, network packet, process lifecycle event, and file operation. Unavoidable by evasive malware (can't hide from kernel).
- Zero Instrumentation: No application changes, no sidecar containers, no code modification for observability. Works for any Linux application unmodified.
- Low Overhead: eBPF programs efficient, event filtering in kernel (only relevant events sent to userspace).
- Real-Time Detection: Events processed as they occur (milliseconds to detection). No polling, no sampling delays.
- Container-Aware: eBPF programs access container metadata (namespace, cgroup IDs, pod labels in Kubernetes).
Why eBPF Security Matters
Traditional security monitoring approaches have significant limitations in modern cloud-native environments with high churn and ephemeral workloads.
- Container Challenges: Traditional agents per-VM fail to see container boundaries. Sidecar agents add overhead and operational complexity. eBPF provides host-level visibility with container-awareness.
- Evasion Risks: Malware can disable userspace agents (kill process, delete logs). eBPF runs in kernel, harder for attackers to disable (requires kernel exploit).
- Performance Overhead: Userspace agents add CPU overhead per event, sampling loses details, and logging all events overwhelms storage. eBPF filters and aggregates in kernel before sending events.
- Kernel Module Risks: Traditional kernel modules can crash kernel, need kernel recompilation per version, and lack safety verification. eBPF programs are verifier-checked, version-agnostic (CO-RE), and portable across kernel versions.
- Observability Gaps: Many security events not exposed via standard APIs (e.g., failed system calls, file access patterns). eBPF hooks into any kernel function (kprobe) for full visibility.
Aspect Traditional eBPF Security
─────────────────────────────────────────────────────────────────────────────
Visibility Limited (logs, API) Full (kernel events)
Overhead High (sampling often) Low (filtered in kernel)
Evasion Risk High (disable agent) Lower (kernel-resident)
Container Awareness Limited Native
Kernel Module Risk High (system stability) None (verifier)
Deployment Complexity Per-host or per-pod Per-host (one-time)eBPF Security Hook Points
| Hook Type | Description | Security Use Cases |
|---|---|---|
| Tracepoints | Stable kernel tracepoints for key events | Process execution (sched_process_exec), file open, network connection, system calls (enter/exit) |
| kprobes/kretprobes | Dynamic instrumentation of any kernel function | Custom kernel function monitoring, function arguments, return values |
| uprobes | Userspace function instrumentation | Application-level monitoring (e.g., TLS decryption) |
| LSM Hooks | Linux Security Module hooks (since kernel 5.7) | Deny system calls (policy enforcement, not just monitoring) | XDP/TC | Network packet processing | DDoS mitigation, network policy, TLS traffic inspection |
eBPF Security Tools
Falco
Falco is the CNCF runtime security tool using eBPF (or kernel module) to monitor system calls and network events. It detects container escapes, privilege escalations, shell execution in containers, unexpected network connections, and file access to sensitive paths. Falco is covered in our Falco guide.
Tetragon
Tetragon is Cilium's eBPF-based security observability and enforcement tool. It provides deep kernel visibility, security policy enforcement (process execution, file access, network), and identity-aware (Kubernetes labels, namespaces). Tetragon supports JSON output for SIEM integration.
Tracee
Tracee (Aqua Security) detects suspicious behavior via eBPF with MITRE ATT&CK mapping, event signatures for known attack patterns, and forensic event capture for investigation.
Cilium Network Policies
Cilium enforces L3-L7 network policies using eBPF, supporting HTTP, gRPC, Kafka protocol filtering. Network policy is identity-based (labels), not IP-based. Hubble for network observability (flow logs, service maps).
Tool Focus eBPF Hooks Key Features
─────────────────────────────────────────────────────────────────────────────
Falco Runtime threat detection syscall, kprobe Rules engine,
tracepoint community rules
Tetragon Security observability kprobe, tracepoint, Process lifecycle,
& enforcement LSM file access
Tracee Behavior detection tracepoint, kprobe MITRE ATT&CK,
signature library
Cilium Network security XDP, TC, socket L7 policies,
transparent enc.Security Detection Examples
Process Execution Monitoring
eBPF programs attach to execve system calls or sched_process_exec tracepoint, capturing parent PID, child PID, binary path, command-line arguments, container ID, Kubernetes pod metadata, and user/group IDs. Anomaly detection includes shells started by web servers, unexpected binaries executed (cryptominers), and execution from writeable directories.
File System Monitoring
eBPF hooks file open, read, write, unlink events, capturing file path, operation type (read/write/create/delete), process info, and file integrity monitoring (tracking changes to sensitive files like /etc/passwd, /etc/shadow, SSH keys, Kubernetes secrets). Detect unauthorized modifications and ransomware file encryption patterns.
Network Connection Monitoring
eBPF tracks TCP/UDP connection events: source/destination IP and port, connection count and volume, process associated with connection, DNS requests (dns response monitoring for DGA domains). Detect connections to known malicious IPs, excessive connection rates (scanning/DoS), and traffic to unexpected geographic locations.
Privilege Escalation Detection
eBPF monitors setuid/setgid binary execution, privilege escalation via kernel exploits (unusual kernel function calls), container escape attempts (namespace manipulation, host mount access), and reading /etc/passwd or /etc/shadow.
Event Pattern Suspicion Level Real-World Attack
─────────────────────────────────────────────────────────────────────────────
nginx spawning bash Critical Web shell upload
cryptominer from /tmp High Cryptojacking
sudo via www-data High Privilege escalation
Connection to known miner pool High Cryptomining
Modified /etc/passwd Critical Backdoor user
SSH from unexpected country Medium Compromised creds
Child process of privileged app Medium RCE exploit
Repeated failed file access Low Scanning/cred bruteeBPF for Container Security
eBPF provides container-aware security by accessing namespace and cgroup information from kernel, enabling per-container policy enforcement without sidecar agents. eBPF programs can filter by container ID and attach to cgroup hooks. Kubernetes metadata enrichment (pod name, namespace, labels) via eBPF maps populated by agent.
Container Attack eBPF Detection
─────────────────────────────────────────────────────────────────────────────
Container escape unshare + setns syscalls,
/proc or /sys access
Privileged container misuse Capabilities check + actions
(receiving incoming connections)
Image with crypto miner Process execution (cryptominer pattern)
Privilege escalation inside setuid binary execution
container
Writeable container filesystem File write to container rootfs
Kubernetes API abuse Process connecting to K8s APIeBPF Security Enforcement (LSM Hooks)
Since Linux kernel 5.7, eBPF can attach to LSM hooks, enabling not just monitoring but active enforcement (blocking policy violations). This allows security policies to deny system calls directly from eBPF, pre-container escape (block mount, unshare), and prevent file writes to sensitive locations.
Security Policy LSM Hook Action
─────────────────────────────────────────────────────────────────────────────
No shell in webserver containers bprm_check_security Deny exec of /bin/sh
Container mounts prohibited sb_mount Deny mount syscall
No privilege escalation capable Deny setuid binary exec
Block access to Kubernetes secrets inode_permission Deny read of secrets
Only allow outbound to specific IPs socket_connect Deny connectioneBPF Security Anti-Patterns
- Logging All Events (Data Flood): eBPF can generate millions of events per second. Logging all events to userspace overwhelms storage and creates network bandwidth costs. Perform filtering and aggregation in kernel (eBPF maps). Only send security-relevant events to userspace.
- No Rate Limiting: Attackers flood events to overwhelm monitoring (DoS for detectors). Implement per-event-type rate limiting in eBPF (specifically for repeated syscall failures).
- Ignoring User IDs: Allowing unprivileged eBPF programs increases attack surface (CAP_BPF capabilities). Restrict eBPF to privileged users (root or CAP_BPF). Use kernel lockdown mode to disable unprivileged eBPF.
- Performance-Intensive In-Kernel Processing: Complex eBPF processing on every packet or syscall adds overhead (offload heavyweight processing to userspace). Use eBPF for filtering, aggregation; userspace for complex analysis.
- No Fallback to Userspace: eBPF programs may fail to load due to unsupported kernel version or verifier rejection. Have fallback detection mechanisms (e.g., kernel audit logs). Monitor eBPF program load status.
Prerequisites:
□ Linux kernel 4.1+ (5.7+ for LSM enforcement)
□ CONFIG_BPF, CONFIG_BPF_SYSCALL enabled
□ BPF filesystem mounted (mount -t bpf)
□ (Optional) BTF support for CO-RE (kernel 5.2+)
Security Controls:
□ Restrict eBPF to privileged users (CAP_BPF)
□ Enable kernel lockdown (integrity/confidentiality)
□ Monitor eBPF program load/attach failures
□ Set rate limits on event generation
Deployment:
□ Deploy per-node (not per-container)
□ Test eBPF program loading before production
□ Have fallback monitoring (auditd)
□ Monitor eBPF performance overheadeBPF Security Best Practices
- Filter in Kernel, Analyze in Userspace: eBPF kernel programs should be simple: drop non-security events, aggregate counters, rate-limit repeated events. Send only relevant events to userspace, then use userspace for complex analysis (correlation, pattern matching).
- Use CO-RE (Compile Once, Run Everywhere): Kernel versions differ across hosts (different function signatures, structure layouts). CO-RE with BTF enables eBPF binary portability. Use libbpf or cilium/ebpf for CO-RE support.
- Test eBPF Programs Thoroughly: eBPF verifier rejects unsafe programs but does not catch logic errors. Use kernel debug trace (`trace_pipe`) for debugging. Simulate attacks in staging environment, test with bpftrace for quick prototyping before C eBPF.
- Monitor eBPF Metrics: Track loaded eBPF programs count, map usage, and map collisions (limit reached). Check verifier failures (indicates program errors).
- Combine with Other Security Layers: eBPF provides visibility but not a silver bullet. Combine with vulnerability scanning, network segmentation, and admission control.
- Least Privilege for eBPF: Unprivileged eBPF (kernel lockdown mode) increases attack surface. Disable unprivileged BPF: `kernel.unprivileged_bpf_disabled = 1`. Restrict CAP_BPF to trusted processes.
Level 1: Monitoring (Observability)
- Deploy Falco/Tracee to monitor events
- Alert on suspicious activity
- Build baseline of normal behavior
Level 2: Detection (Active rules)
- Tune Falco rules for environment
- Integrate with SIEM
- Enable custom rule detection
Level 3: Automated Response
- Automate alerts to PagerDuty/Slack
- Isolate compromised containers
- Block malicious IPs via XDP
Level 4: Enforcement (Prevention)
- Deploy Tetragon for LSM enforcement
- Block policy violations (not just alert)
- Enforce zero trust policiesFrequently Asked Questions
- Is eBPF secure itself?
The eBPF verifier ensures programs are safe (no memory corruption, no infinite loops). However, malicious eBPF programs could exploit verifier vulnerabilities (historically few CVEs). Production use (Facebook, Google) is widespread. Restrict eBPF to trusted users and keep kernel updated. - Can eBPF replace traditional EDR agents?
Not entirely, but eBPF significantly improves endpoint detection. eBPF provides kernel-level visibility impossible for userspace agents. However, eDR solutions also provide application-level context, memory scanning, and file system scanning not yet available in eBPF. eBPF + lightweight agent works well. - Does eBPF work in containers?
Yes, but eBPF programs run in host kernel, not container (host kernel sees all container processes). eBPF programs can filter events by container ID (namespace). Containers need privileged mode (CAP_BPF) to load eBPF programs (not recommended). Deploy eBPF agents on node (not per container). - What Kubernetes versions support eBPF?
eBPF support depends on host Linux kernel, not Kubernetes version. Most managed Kubernetes (GKE, EKS, AKS) use modern kernels supporting eBPF. Check node kernel version before deploying eBPF security tooling. - How much performance overhead does eBPF add?
Minimal (1-5% CPU depending on event volume). XDP programs operate at wire speed (millions of packets per second). System call monitoring adds few microseconds per syscall. Much lower overhead than kernel modules or userspace sampling. - What should I learn next after eBPF security?
After mastering eBPF security, explore Falco for runtime security, Tetragon for security observability, Cilium for Kubernetes network security, eBPF for networking, container security best practices, and kernel attack detection.