eBPF: The Linux Kernel Feature That's Changing Security (and Attack Surfaces)

For most of Linux’s life there was a hard wall between code you wrote and the kernel that ran underneath it. If you wanted the kernel to do something new, you wrote a kernel module — which is to say, you wrote code with the power to crash, corrupt, or backdoor the entire machine, loaded it with your fingers crossed, and hoped. eBPF tore a window in that wall. And like any window, it lets the light in and gives someone a way to look out.

eBPF is one of those technologies that quietly became load-bearing for half the modern infrastructure stack while most people weren’t watching. It’s worth understanding what it is, because it’s reshaping both how we defend Linux boxes and, less comfortably, how they get attacked.

1 What eBPF actually is

eBPF lets you load small programs into the running kernel and attach them to events — a system call firing, a network packet arriving, a function being entered — without writing a kernel module or rebooting. The trick that makes this safe-ish is the verifier: before your program runs, the kernel statically analyses it to prove it terminates, doesn’t read uninitialised memory, and can’t wander off into arbitrary kernel addresses. Programs that don’t pass simply don’t load.

So you get something genuinely new: sandboxed, verified, near-native-speed code running inside the kernel, with visibility into everything the kernel sees. That’s an extraordinary capability, and the security world has fallen on it from two directions at once.

2 The defender’s dream: total visibility

For defence, eBPF is close to a superpower. Because it can hook the syscall layer, you can observe every process that spawns, every file opened, every outbound connection — system-wide, with negligible overhead, and without modifying the applications you’re watching. This is the foundation under tools like Cilium (kernel-level network policy and observability) and Falco and Tetragon (runtime threat detection).

The classic demonstration is watching every new process on the box, live. The bpftrace tool makes this a one-liner:

# print every process exec across the whole system, as it happens
bpftrace -e 'tracepoint:syscalls:sys_enter_execve {
    printf("%-16s %-6d %s\n", comm, pid, str(args->filename));
}'

Run that and you’ll see cron jobs, your shell, and — if something nasty has got in — the cryptominer it’s trying to launch, the moment it execs. For runtime security this is gold: you can write policy that says “no process in this container should ever exec a shell” and enforce it in the kernel, where malware can’t easily lie to you about what it’s doing.

A more security-flavoured example: alerting on any connection to a port outside an expected set, or counting which binaries open /etc/shadow. The data was always there in principle. eBPF makes collecting it cheap enough to do continuously.

3 The attacker’s new toy: the same superpower, inverted

Here’s the uncomfortable half. Everything that makes eBPF a brilliant observability tool makes it a brilliant tool for the wrong people. A program that can see every packet can also hide packets. A program that can hook getdents (the syscall behind directory listings) can filter its own files out of ls. eBPF has become a fashionable substrate for rootkits precisely because it sits below the userspace tools an investigator would normally trust.

A defensive eBPF agent watches syscalls; a malicious eBPF program can intercept those same syscalls to feed the agent — and the human at the keyboard — a sanitised version of reality. There’s published research and real-world tooling demonstrating eBPF-based hiding of processes, connections and files. The very layer you deployed for visibility can be turned into a layer of concealment.

The mitigation is partly governance: loading eBPF programs requires privilege (historically CAP_SYS_ADMIN, narrowed to CAP_BPF plus friends in newer kernels), so an attacker needs to already be root-ish to abuse it. But “they were already root” describes most of the post-exploitation phase, which is exactly when hiding tools earn their keep.

4 What this means for hardening

The practical takeaways for anyone running Linux boxes:

• Treat eBPF capability as the sensitive thing it is. Don’t hand CAP_BPF or CAP_SYS_ADMIN to containers that have no business loading kernel programs.
• Inventory what’s loaded. bpftool prog list shows every eBPF program currently attached. An unexpected entry on a box that shouldn’t be running any is a finding.

# what eBPF programs are loaded right now?
sudo bpftool prog show

• Lock the kernel down. Features like a hardened kernel.unprivileged_bpf_disabled sysctl and lockdown mode raise the bar, even if they don’t slam the door entirely.

5 The verdict

eBPF is not optional knowledge any more. If you run containers, modern networking, or any serious observability stack, it’s already underneath you, whether you invited it or not. For defenders it’s the best visibility into Linux behaviour we’ve ever had cheaply. For attackers who reach root, it’s a tidy way to become invisible.

Who is this for? Anyone responsible for a Linux host that matters. Learn bpftrace for the genuine debugging and detection wins — they’re real and they’re addictive. Then go and check what bpftool prog list shows on your boxes, because the answer should be “exactly the programs I expect,” and the day it isn’t, you’ll want to have looked before.