How to block malicious traffic at the edge with eBPF and XDP

The challenge of protecting the edge against volumetric attacks

When a server faces a denial-of-service attack, known as DDoS, the sheer volume of malicious traffic can exhaust processing resources long before traditional firewall rules can kick in. Historically, user-space security tools suffer from the overhead of context switching between the kernel and the application, creating severe CPU bottlenecks and high latency. In practice, this means the machine spends more time switching execution contexts than actually processing legitimate traffic. To overcome this barrier, network and infrastructure engineers seek alternatives capable of inspecting and dropping unwanted packets the exact moment they hit the network interface, well before the operating system needs to allocate memory for them.

What is eBPF and how it revolutionizes the Linux kernel

eBPF, or Extended Berkeley Packet Filter, is a technology that allows running safe, sandboxed programs directly inside the Linux kernel space without compiling custom kernel modules or rebooting the machine. Think of it as a lightweight virtual machine embedded in the OS core, capable of running optimized code in response to network events, system calls, and tracepoints. When we combine this technology with classic filtering tools, such as iptables and fail2ban, we gain an extra layer of intelligence operating at hardware speed. This model eliminates the complexity of managing static rules and makes room for dynamic decision-making based on actual traffic behavior.

Understanding XDP and network driver-level execution

XDP, which stands for eXpress Data Path, represents the deepest and fastest packet processing stage available in modern Linux. It injects eBPF code directly into the network card driver, executing filtering logic the instant the driver receives the physical packet from the interface. If the packet is deemed malicious, the XDP program can immediately issue a drop instruction known as XDP_DROP, ending that packet's lifecycle without consuming additional CPU cycles. This approach differs radically from conventional methods that force the packet through the entire kernel TCP/IP stack, guaranteeing maximum throughput even under heavy attacks.

Deciding return actions within the packet flow

When programming an XDP filter, we must define with surgical precision the destination of every analyzed packet using specific return codes. The XDP_TX return code, for instance, bounces the packet back out through the same network interface it entered, which is useful for redirection or loopback tests. Meanwhile, XDP_REDIRECT forwards the packet to another interface or to an AF_XDP socket in user space for deep inspection. When handling obvious threats, such as IPs listed in threat intelligence databases, XDP_DROP is the definitive choice to stop the bleeding and prevent traffic from reaching the web server or database.

Implementing a practical packet filter in C and eBPF

To put theory into practice, we need to write a restricted C program that will be compiled into BPF bytecode and loaded into the kernel. The code below demonstrates a basic structure of an XDP program that inspects the Ethernet header and drops IPv4 packets directed at a specific port under suspicion. It is crucial to ensure that packet boundary checks are rigorous to prevent kernel reading faults.

#define KBUILD_MODNAME "xdp_filter"
#include <linux/bpf.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/in.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int xdp_drop_malicious(struct xdp_md *ctx) {
    void *data = (void *)(long)ctx->data;
    void *data_end = (void *)(long)ctx->data_end;
    
    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return XDP_PASS;
        
    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return XDP_PASS;
        
    struct iphdr *ip = data + sizeof(*eth);
    if ((void *)(ip + 1) > data_end)
        return XDP_PASS;
        
    // Example: Block traffic coming from a specific subnet or test IP
    if (ip->saddr == 0x0100007F) { // 127.0.0.1 in educational example
        return XDP_DROP;
    }
    
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

Loading and managing eBPF maps at runtime

Writing the code is only the first step; the next challenge involves compiling the program using Clang/LLVM and loading it into the correct network interface using iproute2 or libbpf tools. To update blocklists without recompiling or unloading the kernel program, we use data structures called eBPF maps. These maps act as shared hash tables between user space and the kernel, allowing external scripts to inject new malicious IPs instantly. This operational flexibility ensures that edge security evolves in real time as new attack patterns are identified across the infrastructure. To explore these architectural concepts further in production, see our related technical analysis on How to test the motherboard NVMe connector with a multimeter.

Final considerations on edge resilience and maintenance

Adopting eBPF and XDP at the network edge radically transforms the defensive posture of any modern infrastructure, offering an almost impenetrable barrier against bandwidth saturations. However, this power comes with operational responsibility: a poorly written kernel program can cause severe operating system crashes or corruption of legitimate packets. Rigorously testing each rule in staging environments and constantly monitoring network interface behavior are essential practices to keep systems resilient and secure over the long term.