How to Stop DDoS Attacks Using eBPF & XDP on Bare Metal Linux Servers

Why traditional firewalls fail during volumetric attacks, and how to build zero-cost, enterprise-grade mitigation at the hardware driver level.

ebpf logo

If you have ever watched your server’s CPU spike to 100% and crash during a massive SYN flood, you already know the harsh truth: traditional firewalling alone is no longer sufficient for high-volume modern DDoS attacks.

By the time a malicious packet reaches iptables or nftables, the Linux kernel has already allocated memory and CPU cycles to process it. State-tracking mechanisms like conntrack become overwhelmed. When you are hit with 10 million packets per second (PPS), your firewall doesn't save you; the overhead of processing the attack is what actually kills your server.

To survive volumetric attacks, you need to drop packets before the operating system even builds the networking context.

That is where eBPF (Extended Berkeley Packet Filter) and XDP (eXpress Data Path) come in.

As a high-performance dedicated server provider, we see enterprise clients moving complex workloads to bare metal to handle massive network throughput. In this guide, we will show you how to leverage XDP to build an ultra-fast, kernel-level DDoS mitigation shield directly on your infrastructure.

The Limits of Traditional Packet Filtering

Before diving into the code, let’s understand why traditional firewalls struggle against modern packet floods.

When a packet arrives at your network interface card (NIC), it typically travels up the entire Linux networking stack. It passes through the NIC driver, enters the core network stack, and hits the netfilter hooks (where iptables and nftables operate).

This is highly inefficient for mitigation. Dealing with line-rate filtering during an L4 mitigation scenario (like a UDP flood) requires kernel bypass or extremely early interception.

Enter eBPF and XDP

eBPF is a revolutionary technology that allows you to run sandboxed, highly efficient programs within the Linux kernel. A built-in verifier ensures the code is safe and won't cause kernel panics.

XDP is a specific networking hook in the eBPF ecosystem. It attaches directly to your server's NIC driver. When a packet arrives, the XDP program inspects it immediately. If the packet is malicious, it is discarded before traversing the full kernel networking stack.

⚠️
Note for advanced deployments: Engineers building ultra-low-latency applications can also leverage AF_XDP sockets to pass packets directly to userspace for custom processing.

Why Bare Metal Delivers the Best XDP Performance

Does XDP work on a standard VPS or cloud instance? Yes. But there is a massive performance difference based on the environment.

In a virtualized environment, packets usually travel through the hypervisor's network stack before reaching your VM's generic XDP hook. However, bare metal delivers the best XDP performance because packets reach the physical NIC directly. Running native XDP on bare metal (especially with supported SmartNICs or enterprise cards like the Intel X710 or Mellanox ConnectX) allows you to achieve true hardware-level drop rates.


Technical Requirements

To run this tutorial, you will need:

  • A Linux kernel of 4.18+ (Kernel 5.x or 6.x is highly preferred for modern eBPF features).
  • A high-performance Bare Metal Servers environment.
  • Root access to compile and attach the BPF code.

First, install the necessary compiler tools and Linux kernel headers:

1
Bash sudo apt update sudo apt install clang llvm libbpf-dev gcc-multilib linux-headers-$(uname -r)

Writing and Attaching an XDP Drop Program

🚨
Security Warning: While the eBPF verifier ensures your code won't crash the OS, logic errors can still lock you out. Accidentally returning XDP_DROP for port 22 will kill your SSH session. Always ensure you have out-of-band management (like IPMI or KVM) configured

For this tutorial, we will write a simple C program that drops all incoming ICMP (Ping) packets.

⚠️
Networking Note: In production, avoid blanket ICMP blocking. ICMP is critical for PMTU (Path MTU) discovery and network diagnostics. This is strictly a safe, easily testable example to verify your XDP hook is functioning.

Step 1: The Code (xdp_drop_icmp.c)

Create a file named xdp_drop_icmp.c:

2
C #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_icmp_prog(struct xdp_md *ctx) { void *data_end = (void *)(long)ctx->data_end; void *data = (void *)(long)ctx->data; struct ethhdr *eth = data; if ((void *)(eth + 1) > data_end) return XDP_PASS; if (eth->h_proto == __constant_htons(ETH_P_IP)) { struct iphdr *iph = (struct iphdr *)(eth + 1); if ((void *)(iph + 1) > data_end) return XDP_PASS; // Drop ICMP packets at the NIC driver level if (iph->protocol == IPPROTO_ICMP) { return XDP_DROP; } } return XDP_PASS; } char _license[] SEC("license") = "GPL";

Step 2: Compiling and Attaching

Compile the code into an eBPF object file:

3
Bash clang -O2 -g -Wall -target bpf -c xdp_drop_icmp.c -o xdp_drop_icmp.o

Find your primary network interface (e.g., eth0), and attach the XDP program:

4
Bash sudo ip link set dev eth0 xdp obj xdp_drop_icmp.o sec xdp

Try pinging your server from an external machine. The pings will time out, yet your CPU utilization will remain completely flat. The packets are being destroyed by the hardware early in the data path.

To remove the filter, run: sudo ip link set dev eth0 xdp off

Production Considerations: Upstream vs. Edge Mitigation

XDP dramatically reduces the need for expensive on-server packet filtering infrastructure. In internal testing, XDP filtering can reduce CPU utilization during synthetic UDP flood simulations by over 80% compared to traditional netfilter drops.

However, it is vital to understand the limits of server-side mitigation.

XDP solves PPS (Packets Per Second) exhaustion. It does not solve transit exhaustion. If an attacker sends 20Gbps of garbage traffic to a server with a 10Gbps uplink, your bandwidth will saturate upstream, and XDP cannot save you. For massive volumetric attacks, a combination of upstream BGP scrubbing DDoS Protected Hosting and edge XDP filtering is the industry standard.

Furthermore, do not hardcode IP addresses in C. Production environments should use eBPF maps, key-value data structures that allow you to dynamically add or remove blacklisted IPs from user space without recompiling the kernel code.

Build Your Custom Shield on Powerful Hardware

High-performance networking requires hardware that doesn't bottleneck under pressure.

Servers99 dedicated servers provide high PPS network capacity, enterprise-grade AMD EPYC and Intel hardware, and advanced DDoS-ready infrastructure ideal for XDP and eBPF deployments

Whether you are building a custom scrubbing center or deploying intensive game servers, our bare-metal infrastructure gives you absolute control over your network stack. Check Servers99 Dedicated Servers.


📚 Read Next: Security Related Guides & Tutorials

👉 eBPF & XDP: Defeating DDoS at the Kernel Level
👉 Generate a Modern Self-Signed SSL Certificate (SAN & EKU)
👉 How to Tune Linux Permissions for Maximum Security

FAQ

They serve different purposes. XDP is superior for dropping high-volume, stateless traffic (like DDoS floods) at the lowest possible level. However, nftables is still required for complex, stateful firewall rules and NAT routing. Best practice is to use both: XDP for dropping garbage, and nftables for fine-grained access control.
Yes, but with reduced efficiency. In virtualized environments (KVM, cloud), XDP usually runs in "generic mode," meaning the packets still traverse the host hypervisor. For line-rate hardware offloading, bare metal servers or VMs with SR-IOV passthrough are required.
Yes. Advanced eBPF programs can implement SYN cookies entirely within XDP, mitigating massive TCP SYN floods without relying on the kernel's TCP/IP stack.
Yes. The eBPF verifier rigorously checks the code before attaching it to the kernel. If the code contains infinite loops, memory leaks, or out-of-bounds access, the kernel will refuse to load it.
Most modern Linux distributions support eBPF and XDP, including Ubuntu 20.04+, Debian 11+, AlmaLinux 9+, Rocky Linux, and RHEL-based systems. For the best compatibility and performance, Linux kernel 5.x or newer is recommended, especially when using advanced XDP features, AF_XDP sockets, or modern NIC drivers.
Yes. Because XDP processes packets at the NIC driver level before they traverse the full Linux networking stack, it can dramatically reduce CPU overhead during high PPS attacks. Compared to traditional netfilter-based filtering, XDP is capable of dropping malicious packets with minimal resource usage, making it ideal for high-performance dedicated servers and bare metal environments.