XDP und eBPF: Paketfilterung der nächsten Generation für Gaming-Server

Wenn ein DDoS-Angriff mit 50 Millionen Paketen pro Sekunde auf Ihren Minecraft-Server trifft, kann iptables nicht mithalten. Nicht weil es schlechte Software ist. Sondern weil es zu hoch im Linux-Netzwerkstack arbeitet, um dieses Volumen zu bewaeltigen. Jedes Paket durchlaeuft Dutzende Kernel-Schichten, bevor iptables es ueberhaupt sieht. Zu diesem Zeitpunkt sind die CPU-Zyklen bereits verbraucht.

Es gibt einen anderen Ansatz. XDP (eXpress Data Path) faengt Pakete auf NIC-Treiberebene ab, bevor der Linux-Kernel sie zu verarbeiten beginnt. Und eBPF (extended Berkeley Packet Filter) ermoeglicht das Schreiben von Programmen, die das Schicksal jedes Pakets in Nanosekunden entscheiden. Durchlassen, verwerfen oder umleiten.

Diese Technologie laeuft bereits in der Produktion bei Cloudflare, Meta und Netflix fuer den DDoS-Schutz. Und genau diese setzen wir bei MineGuard ein, um Traffic zu Gaming-Servern zu filtern.

Was ist eBPF

eBPF ist eine Technologie, die benutzerdefinierte Programme direkt im Linux-Kernel ausfuehren laesst. Keine Kernel-Module (die bei einem Bug das gesamte System zum Absturz bringen koennen), sondern Programme in einer Sandbox-Umgebung. Der Kernel verifiziert jedes eBPF-Programm vor dem Laden: Pruefung auf Endlosschleifen, Speicherzugriffe ausserhalb der Grenzen, Division durch Null.

Wenn ein Programm die Verifizierung nicht besteht, wird es nicht geladen. Wenn es besteht, laeuft es mit nativer Kernel-Geschwindigkeit, weil der JIT-Compiler (Just-In-Time) es in Maschinenbefehle fuer den spezifischen Prozessor uebersetzt.

Im Grunde hat eBPF den Linux-Kernel in eine programmierbare Plattform verwandelt. Frueher bedeutete das Hinzufuegen benutzerdefinierter Paketverarbeitungslogik zum Kernel das Schreiben eines Kernel-Moduls in C, die Kompilierung fuer eine bestimmte Kernel-Version und das Risiko eines Kernel Panic bei jedem Fehler. Mit eBPF schreiben Sie ein kleines Programm, der Kernel garantiert seine Sicherheit, und es laeuft mit minimalem Overhead.

Schluesselmerkmale von eBPF:

• Sicherheit. Der Kernel-Verifier prueft jede Instruktion vor dem Laden
• Geschwindigkeit. JIT-Kompilierung in nativen Maschinencode
• Flexibilitaet. Programme koennen ohne Systemneustart aktualisiert werden
• Isolation. Ein eBPF-Programmabsturz bringt den Kernel nicht zum Absturz

Was ist XDP

XDP (eXpress Data Path) ist ein Hook-Point in Linux auf der niedrigsten Ebene des Netzwerkstacks, direkt im NIC-Treiber. Wenn die Netzwerkkarte ein Paket empfaengt, verarbeitet XDP es VOR der Erstellung einer sk_buff-Struktur durch den Kernel, VOR netfilter, VOR conntrack, VOR iptables.

Warum ist das entscheidend? Weil der groesste Teil der CPU-Kosten bei der Paketverarbeitung auf die oberen Stack-Schichten entfaellt. sk_buff erstellen, netfilter-Ketten durchlaufen, conntrack-Tabellen aktualisieren - all das dauert Hunderte von Nanosekunden pro Paket. Bei einem DDoS-Angriff mit Millionen von Paketen pro Sekunde werden diese "Hunderte von Nanosekunden" zu 100% CPU-Auslastung.

XDP arbeitet dort, wo das Paket noch rohe Bytes in einem DMA-Puffer ist. Keine Speicherallokationen, kein Conntrack. Das XDP-Programm erhaelt einen Zeiger auf die Rohdaten des Pakets und trifft eine von vier Entscheidungen:

• XDP_DROP - Paket verwerfen. Die schnellste Aktion, das Paket erreicht nie den Kernel-Stack
• XDP_PASS - Paket an den normalen Kernel-Stack zur Verarbeitung weiterleiten
• XDP_TX - Paket ueber dasselbe Interface zuruecksenden (nuetzlich fuer SYN Cookies)
• XDP_REDIRECT - Paket an ein anderes Interface oder Programm umleiten

Hier ein vereinfachtes XDP-Programm in C:

SEC("xdp")
int xdp_filter(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_DROP;

    if (eth->h_proto != htons(ETH_P_IP))
        return XDP_PASS;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return XDP_DROP;

    // Blockliste pruefen
    __u32 src_ip = ip->saddr;
    if (bpf_map_lookup_elem(&blocklist, &src_ip))
        return XDP_DROP;

    // Rate Limit pruefen
    struct rate_info *rate = bpf_map_lookup_elem(&rate_counters, &src_ip);
    if (rate && rate->pps > MAX_PPS_PER_IP)
        return XDP_DROP;

    return XDP_PASS;
}

Dieser Code wird in 50-100 Nanosekunden ausgefuehrt. Zum Vergleich: Ein Paket durch den gesamten iptables-Stack braucht 2000-5000 Nanosekunden.

Warum iptables zu langsam ist

Um den Vorteil von XDP zu verstehen, schauen wir uns den Weg eines Pakets bei iptables an.

Wenn ein Paket an der Netzwerkkarte ankommt:

1. NIC legt das Paket per DMA in den Ring Buffer
2. Kernel empfaengt einen Interrupt, startet NAPI Polling
3. Eine sk_buff-Struktur wird erstellt (Speicherallokation)
4. Paket durchlaeuft ingress qdisc (Traffic Control)
5. netfilter: raw-Tabelle, PREROUTING-Kette
6. conntrack: Hash-Tabellen-Lookup, neue Eintrags-Erstellung
7. netfilter: mangle-Tabelle, PREROUTING-Kette
8. Routing-Entscheidung
9. netfilter: filter-Tabelle, INPUT-Kette
10. iptables: Pruefung JEDER Regel der Reihe nach

Erst bei Schritt 10 entscheidet iptables: DROP oder ACCEPT. Aber zu diesem Zeitpunkt hat der Kernel bereits CPU fuer die Schritte 1-9 verbraucht. Bei einem DDoS-Angriff sind 90% der Pakete Muell, und jedes einzelne durch den gesamten Stack zu schicken ist sinnlose Verschwendung.

XDP arbeitet zwischen Schritt 1 und 2. Das Paket wird vor der sk_buff-Erstellung abgefangen, vor conntrack, vor netfilter. Wenn es verworfen werden muss, wird es sofort verworfen, ohne eine einzige Speicherallokation.

Die Zahlen

Echte Benchmarks zeigen den Unterschied in Groessenordnungen:

Methode	Pakete/Sek (1 Kern)	Latenz
iptables	~1 Mio	2-5 us
nftables	~2 Mio	1-3 us
XDP (generic)	~5 Mio	0.5-1 us
XDP (native)	~14 Mio	0.05-0.1 us

XDP im Native-Modus (vom NIC-Treiber unterstuetzt) verarbeitet 14x mehr Pakete als iptables. Auf einem 8-Kern-Server sind das theoretisch 100+ Millionen Pakete pro Sekunde. Zum Kontext: Die meisten DDoS-Angriffe auf Minecraft-Server generieren zwischen 5 und 50 Millionen pps.

BPF Maps: zustandsbasierte Filterung

Nur nach IP droppen reicht nicht. Echter Schutz erfordert Zustand: Paketzaehler, Blocklisten, Session-Informationen. eBPF bietet dafuer BPF Maps, Datenstrukturen die zwischen dem eBPF-Programm im Kernel und der User-Space-Anwendung geteilt werden.

Wichtige Map-Typen:

Hash Map - klassische Hash-Tabelle. Ideal fuer IP-Blocklisten:

struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 100000);
    __type(key, __u32);         // IP-Adresse
    __type(value, __u64);       // Zeitstempel
} blocklist SEC(".maps");

LRU Hash - Hash-Tabelle mit automatischer Verdraenung alter Eintraege. Gut fuer Rate Limiting:

struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, __u32);            // IP-Adresse
    __type(value, struct rate_info); // Paketzahl, Zeitstempel
} rate_counters SEC(".maps");

Per-CPU Array - Array mit separater Kopie fuer jeden CPU-Kern. Keine Sperren, maximale Geschwindigkeit:

struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 1);
    __type(key, __u32);
    __type(value, struct stats);
} packet_stats SEC(".maps");

Die User-Space-Anwendung kann Blocklisten aktualisieren, Statistiken lesen und Rate-Limit-Schwellen in Echtzeit aendern. Das eBPF-Programm im Kernel uebernimmt Aenderungen ohne Neuladen. Das ist ein wesentlicher Unterschied zu iptables, wo das Hinzufuegen von 10.000 Regeln Sekunden dauert und die Paketverarbeitung blockiert.

Wie traditioneller DDoS-Schutz funktioniert

Die meisten DDoS-Schutzdienste fuer Minecraft verwenden immer noch iptables oder nftables als primaeres Filterwerkzeug. Das Setup ist einfach: Traffic laeuft durch einen Proxy-Server, auf dem iptables-Regeln "schlechte" Pakete filtern.

Die Probleme dieses Ansatzes:

Lineare Regelpruefung. iptables prueft Regeln der Reihe nach. 1.000 Regeln in einer Blockliste bedeuten 1.000 Pruefungen pro Paket. ipset hilft (O(1)-Suche), geht aber immer noch durch conntrack und netfilter.

Conntrack-Overhead. Jede neue Verbindung erstellt einen conntrack-Eintrag. Bei einem SYN-Flood fuellt sich die conntrack-Tabelle in Sekunden und beginnt, legitime Verbindungen zu verwerfen. Wir haben das ausfuehrlich in unserem Artikel ueber SYN-Flood-Angriffe auf Minecraft beschrieben.

Context Switches. iptables laeuft im softirq-Kontext, aber jede Regelaenderung (Hinzufuegen, Loeschen) erfordert Sperren, was unter hoher Last Contention erzeugt.

Begrenzte Logik. Komplexe Filterung (Minecraft-Payload-Analyse, zustandsbasiertes Rate Limiting, adaptive Schwellen) ist in iptables entweder unmoeglich oder erfordert Workarounds mit u32/string match Modulen.

XDP/eBPF loest all diese Probleme. Blockliste in einer BPF Hash Map: O(1)-Suche ohne conntrack. Rate Limiting auf Per-CPU-Countern: ohne Sperren. Minecraft-Protokollanalyse in eBPF: voller Zugriff auf Paketdaten. Regelaktualisierungen ueber BPF Maps: kein Neuladen, keine Blockierung der Verarbeitung.

Warum Gaming-Server XDP brauchen

Gaming-Server, insbesondere Minecraft, haben spezifische Anforderungen an den DDoS-Schutz.

Niedrige Latenz. Jede Millisekunde zusaetzliche Verzoegerung ist fuer Spieler spuerbar. Wenn der Filter 5 ms pro Paket hinzufuegt, bemerken Spieler Lag. XDP fuegt weniger als 0.1 ms hinzu, selbst bei 100+ Spielern online nicht bemerkbar.

Hohe pps bei Angriffen. Moderne DDoS-Angriffe auf Minecraft generieren Dutzende Millionen Pakete pro Sekunde. Das ist kein volumetrisches Flooding (Gbps), sondern Packet-Rate-Flooding, das darauf abzielt, die Server-CPU zu ueberlasten. iptables kann physisch nicht mit dieser Rate umgehen. Den Unterschied zwischen volumetrischen und Packet-Rate-Angriffen haben wir in unserem Artikel ueber TCP- und UDP-Angriffe auf Minecraft beschrieben.

Bot-Angriffe auf Protokollebene. Angreifer simulieren den Minecraft-Handshake und senden gueltige SYN-Pakete gefolgt von Login-Paketen. iptables kann den Inhalt von Minecraft-Paketen nicht inspizieren. Ein eBPF-Programm kann den Payload auf Kernel-Ebene parsen und einen gefaelschten Handshake verwerfen, bevor er den Userspace erreicht.

Schnelles Regelwechseln. Waehrend eines Angriffs aendert sich das Traffic-Profil alle paar Sekunden. Neue IPs, neue Muster, adaptive Botnets. BPF Maps ermoeglichen sofortige Blocklisten- und Zaehler-Updates ohne Neuladen des Filters.

Bei MineGuard verwenden wir XDP/eBPF als erste Filterschicht. Pakete, die die XDP-Pruefung nicht bestehen, werden verworfen, noch bevor eine sk_buff-Erstellung stattfindet. Nur legitimer Traffic wird im Stack nach oben weitergeleitet, wo eine zusaetzliche Minecraft-Protokoll-Validierung stattfindet.

Realer Einsatz: Wer nutzt eBPF

XDP/eBPF ist keine experimentelle Technologie. Die groessten Unternehmen setzen sie in der Produktion ein.

Cloudflare verarbeitet den gesamten eingehenden Traffic auf ihren Edge-Servern mit eBPF-Programmen. Ihre Magic Firewall ist vollstaendig auf XDP aufgebaut und bewaeltigt Dutzende Terabit pro Sekunde an DDoS-Angriffen.

Meta (Facebook) nutzt XDP fuer Load Balancing (Katran) und DDoS-Schutz. Ihre Loesung verarbeitet Milliarden von Paketen pro Sekunde auf Produktionsservern.

Netflix verwendet eBPF fuer Netzwerkanalyse und den Schutz ihrer CDN-Infrastruktur.

Cilium ist ein Kubernetes-Netzwerk-Plugin, das vollstaendig auf eBPF aufgebaut ist und iptables fuer Routing und Filterung in Container-Umgebungen ersetzt.

Der Trend ist klar: eBPF ersetzt iptables ueberall, wo hohe Leistung gefragt ist. Die Gaming-Branche ist keine Ausnahme. Die neuesten Daten zu Minecraft-DDoS-Angriffen und Verteidigungsmethoden haben wir in unserer Uebersicht der DDoS-Trends fuer Minecraft 2026 zusammengestellt.

Einschraenkungen von XDP/eBPF

Es waere unehrlich, nur ueber die Vorteile zu sprechen. Die Technologie hat reale Einschraenkungen.

Kernel-Version. XDP erfordert Linux 4.8+, und viele nuetzliche Features (BPF_MAP_TYPE_LRU_HASH, bpf_fib_lookup) erschienen erst in 5.x-Kernels. Die meisten VPS-Hoster fuer Minecraft verwenden noch 4.x- oder sogar 3.x-Kernel. Auf solchen Kernels funktioniert XDP entweder gar nicht oder nur im begrenzten Generic-Modus.

Treiberunterstuetzung. Fuer volle Geschwindigkeit benoetigt XDP NIC-Treiberunterstuetzung (natives XDP). Nicht alle Treiber unterstuetzen das. Ohne nativen Modus laeuft XDP im Generic-Modus, der schneller als iptables ist, aber nicht die maximalen 14M+ pps erreicht.

Entwicklungskomplexitaet. Ein eBPF-Programm fuer Paketfilterung zu schreiben ist nicht trivial. Sie muessen kennen:

• C (eBPF-Programme werden in einer Teilmenge von C geschrieben)
• Den Linux-Netzwerkstack auf Kernel-Ebene
• Paketstrukturen (Ethernet, IP, TCP/UDP)
• Einschraenkungen des eBPF-Verifiers (keine Schleifen beliebiger Laenge, begrenzter Stack)
• BPF Maps und ihr Nebenlaeuigkeitsmodell
• Gaming-Server-Protokolle (Minecraft-Protokoll fuer Payload-Analyse)

Verifier-Beschraenkungen. Der eBPF-Verifier ist streng. Keine Endlosschleifen, 512-Byte-Stack-Limit, jeder Speicherzugriff muss auf Grenzen geprueft werden. Gut fuer die Sicherheit, aber erschwert das Schreiben komplexer Logik.

Debugging. Das Debuggen von eBPF-Programmen ist deutlich schwieriger als bei normalem Code. printk in eBPF ist eingeschraenkt, und Fehler aeussern sich oft als "verifier rejected program" mit kryptischen Meldungen.

Warum man XDP nicht einfach selbst einrichten kann

Theoretisch ist XDP offene Technologie, und jeder kann ein eBPF-Filterprogramm schreiben. In der Praxis erfordert es:

1. Einen geeigneten Kernel (5.10+ fuer komfortables Arbeiten)
2. Eine NIC mit nativer XDP-Unterstuetzung (Intel i40e, Mellanox mlx5, virtio in manchen Konfigurationen)
3. Tiefes Wissen ueber den Linux-Netzwerkstack
4. Verstaendnis des Minecraft-Protokolls (fuer Application-Level-Filterung)
5. Monitoring und Analytik (um zu verstehen, was der Filter tut)
6. Staendige Aktualisierungen (Angriffe entwickeln sich, Filter muessen sich anpassen)

Einen einfachen XDP Rate Limiter zu schreiben dauert einen halben Tag. Einen produktionsreifen DDoS-Filter mit Minecraft-Protokollanalyse, adaptiven Schwellen, BPF-Map-Rotation, Graceful Reload und Monitoring zu bauen, dauert Monate an Entwicklung.

Fuer einen Minecraft-Server-Betreiber ist das ungefaehr wie ein eigenes Antivirenprogramm zu bauen statt eines zu kaufen. Technisch moeglich, praktisch sinnlos. Ihre Zeit ist besser investiert in das Wachstum Ihres Servers als in den Kampf mit eBPF-Verifier-Eigenheiten.

Es ist weitaus effektiver, DDoS-Schutz zu nutzen, bei dem XDP/eBPF bereits konfiguriert und optimiert ist. Eine grundlegende iptables-Konfiguration wird weiterhin als letzte Verteidigungslinie auf Ihrem Server benoetigt, aber die primaere Traffic-Filterung sollte spezialisierten Loesungen ueberlassen werden.

Die Zukunft: programmierbare Netzwerke

XDP und eBPF sind nicht nur ein iptables-Ersatz. Sie stellen einen fundamentalen Wandel in der Netzwerksicherheit dar. Statt statischer Regeln ("blockiere diese IP", "begrenze Rate auf N/s") kann man beliebige Logik direkt im Kernel mit Wire Speed ausfuehren.

Was das fuer den DDoS-Schutz bedeutet:

Adaptive Filterung. Ein eBPF-Programm kann Traffic-Muster in Echtzeit analysieren und die Filterstrategie aendern, ohne den Userspace einzubeziehen. Anstieg von SYN-Paketen aus einem bestimmten Subnetz erkannt? Wendet automatisch strengere Rate Limits dafuer an.

ML auf Kernel-Ebene. Es entstehen bereits Projekte, die einfache Machine-Learning-Modelle in eBPF fuer Traffic-Klassifizierung ausfuehren. Dies ermoeglicht das Erkennen von Paketanomalien, die statische Regeln nicht erfassen.

Hardware Offload. Manche NICs (SmartNICs) erlauben das Laden von eBPF-Programmen direkt auf die Karte. In diesem Fall werden Pakete ganz ohne Server-CPU-Beteiligung gefiltert. Filtergeschwindigkeit: 100+ Gbps auf einem einzelnen Port.

Composable Datapath. Mehrere eBPF-Programme koennen verkettet werden (Tail Calls), wodurch ein modulares Filtersystem entsteht. Ein Modul prueft IPs, ein anderes analysiert Raten, ein drittes parst das Spielprotokoll.

Fuer die Gaming-Branche bedeutet das: DDoS-Angriffe, die heute unaufhaltbar erscheinen (100M+ pps), werden in ein paar Jahren von einer einzigen SmartNIC in Bruchteilen einer Mikrosekunde gefiltert. Und komplexe Application-Level-Angriffe werden von ML-Modellen direkt im Kernel erkannt, ohne Verzoegerung durch den Transport der Daten in den Userspace.

XDP/eBPF ist keine Wunderwaffe. Es ist ein Werkzeug, das bei richtiger Anwendung eine Groessenordnung bessere Filterleistung liefert als traditionelle Methoden. Und beim DDoS-Schutz von Gaming-Servern, wo jede Mikrosekunde Verzoegerung und jedes zusaetzliche Paket zaehlt, ist diese Groessenordnung der Unterschied zwischen einem abgestuerzten Server und stabilen 20 TPS unter Angriff.