eBPF Security: A Linux Kernel Superpower for Defenders and Attackers

If you’ve heard about Cilium, Falco, Tetragon, or “agentless observability” in recent years, there’s one technology behind it all: eBPF. It’s one of the most important mechanisms in the modern Linux kernel - and a new, poorly understood attack surface. It’s worth understanding how it works because it powers both modern defense and the next generation of malware.

What is eBPF

eBPF (extended Berkeley Packet Filter) allows you to run small, sandboxed programs inside the kernel, without writing a kernel module and without recompilation. You load the eBPF program from userspace (with a call to bpf()), and the kernel hooks it to the event - and executes it whenever it occurs.

The connection places (hooks) are crucial:

• kprobes / tracepoints - kernel function calls and tracepoints (observability, behavior detection).
• XDP (eXpress Data Path) - the earliest possible packet handling point, before the allocation of network structures; hence, XDP is suitable for very fast filtering and DDoS mitigation.
• tc (traffic control) - traffic shaping and filtering.
• LSM (Linux Security Module) - plugged into kernel security decisions (KRSI): allow/deny at the security event level.

The program communicates with the user space via eBPF maps (arrays, ringbuffers), which allows you to export metrics and events without expensive context switching.

Verifier - why this is not a regular kernel module

Running arbitrary code in the kernel sounds terrifying. Therefore, the heart of eBPF security is the *verifier - a kernel component that statically proves that a program is “safe” before it is loaded:

• Ends - no unlimited loops (historically no loops, today limited loops allowed).
• Does not reach beyond memory - every memory access is checked for bounds.
• Does not hang in the kernel - limited number of instructions and complexity.

Only the program that passes the verifier is compiled (JIT) into machine code and run at full speed. It is the verifier that distinguishes eBPF from a classic kernel module that can do literally anything in the system.

eBPF in Defense: Observability and Enforcement

For security teams, eBPF is a breakthrough because it gives deep insight into the system without interfering with applications:

• Runtime security. Tools like Falco and Tetragon observe system calls, process startups, file access, and network connections - and detect suspicious behavior (e.g. shell running in a container, trying to read sensitive files). This is especially valuable in Kubernetes and container security, where classic agents are cumbersome.
• Network and Policies Cilium implements network policies and micro-segmentation (consistent with the idea of ​​Zero Trust) directly in the kernel, more efficiently than traditional iptables.
• DDoS Mitigation on XDP. Rejecting malicious packets at the earliest stage means minimal cost per packet - hence XDP in anti-DDoS solutions.

The big advantage is performance: events are filtered and aggregated in the kernel, so only what’s important ends up in user space.

eBPF under attack: a new class of rootkits

The same power that helps the defender tempts the attacker. eBPF operating with appropriate permissions can:

• Hide and hide other artifacts - Manipulate what tools see (hiding processes, files, connections), performing rootkit functions without loading a kernel module.
• Eavesdrop and Steal Data - intercept traffic, system call data, credentials before they are encrypted.
• Modify system behavior - influence kernel decisions where hooks are inserted.

Public frameworks for malicious eBPF have already been created, and research shows how difficult it is to detect such code using classical methods. In addition, there are vulnerabilities in the verifier itself: bugs in the kernel have previously made it possible to bypass verifier guarantees and escalate privileges from a local user to the kernel. eBPF is therefore both a defensive tool and an attack target.

Hardening: how to reduce your risk

Basic rule: eBPF is a powerful permission - treat it like kernel access.

• Disable unprivileged eBPF. In most distros this is already the default, but verify:

sysctl kernel.unprivileged_bpf_disabled   # should return 1 or 2

This prevents an ordinary user from loading eBPF programs.

• Control permissions. Loading eBPF requires CAP_BPF (and additional capabilities depending on program type). Don’t grant these capabilities to containers or services that don’t need them - this is part of overall Linux hardening.
• Monitor use of bpf(). Since an attacker can also use eBPF, program loading itself is a signal worth watching. Including system calls in the audit and alerting on unusual bpf() is a good element of security monitoring.
• Keep the kernel updated. Verifier vulnerabilities are patched in the kernel - maintaining the current version is critical here.
• Minimize the base image. In container environments, use minimal images and seccomp/AppArmor profiles to limit available system calls.

Summary

eBPF is one of the most important technologies in modern Linux: it provides unprecedented insight into the system and a fast, programmable network - therefore it powers modern monitoring, micro-segmentation and anti-DDoS. This same power, however, makes it an attractive tool for an attacker and a target for vulnerability. A sensible approach is to take advantage of the defensive potential of eBPF, but at the same time treat program loading as a kernel class privilege - disable unprivileged access, control capabilities, monitor bpf(), and update the kernel.

If you are building a container environment or want to evaluate the hardening of your Linux systems, contact us - hardening and configuration audits are among our areas of expertise.

Frequently asked questions (FAQ)

Is eBPF safe if it can be used to write a rootkit? The mechanism itself has solid security features - a verifier and the requirement for high privileges to load programs. The risk arises once the attacker has gained appropriate privileges (or when unprivileged eBPF is enabled). Therefore, it is crucial to limit who can load eBPF programs and monitor this.

Do I need eBPF to secure my servers? It is not mandatory, but tools based on eBPF (for runtime security and observability) provide qualitatively better insight than many classic solutions, especially in containers. This is one of the best options available for modern threat detection on Linux.

How to detect eBPF malware on your system? This is difficult because eBPF can actively hide itself. Monitoring bpf() calls, inventorying loaded programs (bpftool prog list), restricting permissions to load them, and kernel monitoring tools help. Prevention is the most effective: preventing the attacker from gaining the privileges needed to load the program.

How is eBPF different from a kernel module? A kernel module has unrestricted access and can crash or compromise the entire system. The eBPF program goes through a verifier that proves its security (limited memory, completion), runs in a sandbox, and is loaded without kernel recompilation. This is a much safer, although still powerful, model for extending the kernel.