Was ist XDP und wie kann es beim Aufbau von Anti-DDoS-Schutz helfen?

XDP-Einführung und wie es beim Aufbau von Anti-DDoS-Schutz helfen kann

Wenn Sie eine öffentliche API, einen Reverse-Proxy, einen Spieledienst oder eine andere internetbasierte Anwendung betreiben, können Sie an einen schmerzhaften Punkt gelangen, an dem der Server mit Traffic beschäftigt ist, der von Anfang an nutzlos war. Die Anwendung versagt nicht unbedingt, weil sie echte Nutzer nicht bewältigen kann. Sie versagt, weil der Host CPU-Zeit damit verbringt, Junk-Pakete zu empfangen, zu analysieren, zu klassifizieren und tiefer in Linux zu befördern, bevor irgendetwas „Nein” sagt. Viele Anti-DDoS-Probleme beginnen dort: nicht als Bandbreitenproblem, sondern als Problem der Paketverarbeitungskosten.

Das ist nicht nur für Kernel-Spezialisten relevant. Entwickler, Self-Hoster, VPS- und Dedicated-Server-Betreiber und sogar Geschäftsleser, die Resilienzoptionen vergleichen, stoßen alle auf dieselbe grundlegende Frage: Wie früh kann schlechter Traffic abgelehnt werden, bevor er Zeit und Ressourcen verbraucht, die eigentlich für echte Arbeit bestimmt sind? Einige Angriffe überlasten den Uplink selbst, aber viele schädliche Situationen zeigen sich früher als Pakete-pro-Sekunde-Druck auf dem Host, lange bevor die Leitung vollständig ausgelastet ist.

Genau hier lohnt es sich, XDP zu verstehen. Es ersetzt keine vorgelagerte Mitigation, keine Firewall und keine anwendungsbewussten Kontrollen. Was es bietet, ist ein viel früherer Kontrollpunkt im Linux-Paketpfad. Dieser Artikel erklärt, was XDP ist, warum diese „frühere” Position für Anti-DDoS-Arbeit wichtig ist und wo es in einem realistischen Stack passt. Um dem Rest zu folgen, benötigen Sie zunächst nur ein sehr kleines Vokabular.

XDP-Schlüsselbegriffe in 2 Minuten

Einige der Begriffe rund um XDP überschneiden sich, und auf den ersten Blick klingen sie einschüchternder als sie wirklich sind. Das ist normal. Der Zweck dieses Glossars ist nicht, den Artikel in eine Linux-Interna-Lektion zu verwandeln. Es reicht gerade aus, um den Rest der Erklärung klar zu machen.

Wenn Sie nur eine mentale Abkürzung aus dieser Tabelle mitnehmen, dann diese: eBPF ist der programmierbare Mechanismus, und XDP ist ein spezifischer Ort, an dem dieser Mechanismus ausgeführt werden kann. Mit diesem Verständnis ist der nächste Schritt eine einfachere und nützlichere Frage: Was macht XDP eigentlich?

Was XDP wirklich ist

XDP ist ein früher Paketverarbeitungs-Hook in Linux. Es ermöglicht dem System, ein kleines eBPF-Programm auf einem Paket auszuführen, sobald dieses Paket an einem Netzwerk-Interface ankommt. In diesem Moment kann Linux eine schnelle Entscheidung treffen: das Paket weiterleiten (XDP_PASS), es sofort verwerfen (XDP_DROP) oder es auf eine andere definierte Weise behandeln. Für diesen Artikel ist der wichtige Teil einfach: XDP kann sehr früh „durchlassen” oder „hier stoppen” sagen.

Linux verwendet eBPF in verschiedenen Kontexten, nicht nur im Netzwerkbereich. XDP ist die netzwerkfokussierte Version, die für die sehr frühe Verarbeitung eingehender Pakete entwickelt wurde. XDP ist also kein anderes Wort für eBPF. Es ist ein eBPF-basiertes Werkzeug mit einer sehr spezifischen Rolle.

Diese Rolle macht XDP für Anti-DDoS-Arbeit nützlich. XDP läuft, bevor Pakete durch die normalen, schwereren Teile des Linux-Netzwerkpfads gehen. Daher kann Linux über einigen Traffic entscheiden, bevor es mehr Aufwand für Firewalling, Connection-Tracking, Sockets und schließlich die Anwendung selbst betreibt. Deshalb ist der eigentliche Vorteil von XDP nicht nur das Filtern — es ist das frühere Filtern.

Darüber hinaus ist XDP für mehr als Anti-DDoS nützlich. Es kann auch Traffic-Steuerung und andere Paketverarbeitungsaufgaben unterstützen. Aber Anti-DDoS ist der einfachste Ort, um seinen Wert zu erkennen, denn der Nutzen lässt sich auf eine praktische Idee reduzieren: Je früher schlechter Traffic abgelehnt wird, desto weniger nutzlose Arbeit muss der Server leisten. Und um zu verstehen, warum das so wichtig ist, ist der nächste Schritt, genau zu betrachten, wo XDP im Paketempfangspfad sitzt.

Das mentale Modell: XDP ist das Tor, nicht der Empfang

Am einfachsten lässt sich XDP als Sicherheitsbeamter am Tor vorstellen, nicht als Empfangsdame tiefer im Gebäude. Wenn ein offensichtlich unerwünschter Besucher am Tor abgewiesen wird, vermeidet das Gebäude eine lange Kette sinnloser Arbeit. Niemand öffnet die innere Tür, trägt ihn in ein System ein oder führt ihn durch den Flur. Wenn man bis zum Empfang wartet, um ihn abzuweisen, hat das Gebäude bereits Zeit und Aufmerksamkeit für die falsche Person aufgewendet.

Die Linux-Paketverarbeitung funktioniert genauso. In einem vereinfachten Empfangspfad kommt das Paket von NIC und Treiber an, erreicht XDP und geht erst dann in den reichhaltigeren Kernel-Netzwerk-Stack weiter, der Conntrack, Firewalling, Sockets und schließlich die Anwendung versorgt. Visuell dargestellt sieht der Pfad so aus:

NIC / driver
    ↓
XDP  ← earliest checkpoint
    ↓
kernel networking stack
    ↓
conntrack / firewall
    ↓
socket
    ↓
application

Im Native-Modus kann XDP handeln, bevor Linux die übliche sk_buff-Struktur allokiert und befüllt — das reichhaltigere Kernel-Paketobjekt, das der Rest des Stacks erwartet. Dieses Detail klingt klein, ist aber das Herzstück der Performance-Geschichte. Wenn das Paket offensichtlich unerwünscht ist, bedeutet das Verwerfen, bevor Linux diese normale Struktur aufbaut, weniger CPU-Arbeit, weniger Speicher-Overhead und weniger nachgelagerten Druck. XDP_PASS existiert, weil nicht jedes Paket schlecht ist; es ist die „Weiter”-Aktion, die legitimen Traffic weiterleiten lässt. XDP_DROP ist der Anti-DDoS-Star, weil er die Reise beendet, bevor der teure Teil beginnt. Andere Aktionen wie REDIRECT existieren ebenfalls, sind aber für diese Erklärung nicht ausschlaggebend.

Sobald die Platzierung klar ist, lassen sich der Anti-DDoS-Wert — und die Einschränkungen — viel einfacher realistisch beurteilen.

Wie XDP bei Anti-DDoS hilft — und wo seine Grenzen beginnen

Das Anti-DDoS-Argument für XDP ist unkompliziert: Es ist eine kostengünstige Möglichkeit, offensichtlichen Müll abzulehnen, bevor Linux Ressourcen für Conntrack, Socket-Handling und User-Space-Zustellung aufwendet. Wenn ein Host mit hochfrequentigem Traffic überflutet wird, der die Anwendung ohnehin nie erreichen sollte, ist jedes früh verworfene Paket Arbeit, die der Server später nicht mehr erledigen muss. Deshalb ist XDP am stärksten an der L3/L4-Grenze des Problems: Quelladressen, denen Sie bereits misstrauen, Protokolle, die Sie nicht möchten, oder Traffic-Muster, die für die Arbeitslast eindeutig nicht legitim sind.

Dies ist am wichtigsten bei Junk-Floods, bei denen das Schmerzhafte nicht das rohe Datenvolumen ist, sondern die wiederholte Paketverarbeitung. Ein Reverse-Proxy, ein UDP-lastiger Dienst oder eine öffentliche API kann langsam werden, lange bevor der Uplink vollständig ausgelastet ist, wenn der Host damit beschäftigt ist, Unsinn zu klassifizieren. XDP gibt Ihnen eine Möglichkeit, einen Teil dieses Verschwendung nahe an der Tür abzuschneiden.

📝 Hinweis: XDP schützt Host-Ressourcen besser als einen gesättigten Upstream-Link. Wenn der providerseitige Link bereits voll ist, ist ein frühes Verwerfen auf Host-Ebene zu spät, um den Netzwerkpfad allein zu reparieren.

Diese Unterscheidung ist der Hauptgrund, warum XDP in ein mehrschichtiges Design gehört und nicht auf ein Podest gestellt werden sollte. Die folgende Tabelle ist die praktische Version von XDP vs. nftables vs. Upstream-/Provider-Mitigation:

Mit anderen Worten: XDP und nftables sind keine Feinde. Sie lösen verschiedene Teile des Pfades. nftables ist reichhaltiger und zustandsbehaftet. xdp-filter — das in diesem Artikel verwendete Demo-Tool — ist absichtlich einfach und zustandslos, was genau der Grund ist, warum es nützlich ist, um das XDP-Modell zu zeigen, ohne vorzugeben, eine vollständige Firewall zu ersetzen. Wenn Sie Connection-Tracking, mehrschichtige Allowlists, Antwort-Zustandsbehandlung oder anwendungsbewusste Regeln benötigen, beschreiben Sie bereits Probleme, die tiefer als dieses Demo-Dienstprogramm angesiedelt sind.

Produktionsbetreiber verwenden XDP-artiges Verwerfen, weil frühes Verwerfen die nachgelagerte Arbeit reduziert. Cloudflares L4Drop-Geschichte ist ein bekanntes Beispiel dafür, warum dieses Modell im realen Betrieb attraktiv wurde. Aber die wichtige Lektion ist nicht nur die Schlagzeilen-Pakete-pro-Sekunde-Zahl. Es ist die Designlogik: Schlechten Traffic früher ablehnen, damit der Rest der Maschine echten Traffic länger bedienen kann.

Reale Ergebnisse hängen stark von der Umgebung ab. NIC- und Treiber-Unterstützung, ob XDP im Native- oder skb-Modus läuft, und die Form des eingehenden Traffics beeinflussen alle, wie viel Nutzen Sie tatsächlich erzielen. Deshalb sind Schlagzeilen-Pakete-pro-Sekunde-Zahlen von Anbietern oder Hyperscalern am besten als Beweis zu behandeln, dass das Early-Drop-Modell funktioniert, nicht als Zahlen, die jeder VPS erwarten sollte. Mit diesem Hintergrund zeigt der nächste Abschnitt, wie XDP auf einem echten Ubuntu-Host durch einige sichere Operator-Snapshots aussieht.

Wie XDP in der Praxis aussieht — Befehls-Snapshots

Dieser Abschnitt ist ein Proof-of-Concept-Snapshot. Das Ziel ist es, XDP auf Ubuntu 24.04 mit dem relevanten Befehlssatz real erscheinen zu lassen: genug, um einen Filter zu laden, zu inspizieren, was angehängt wurde, eine risikoarme Regel hinzuzufügen und die relevanten Zähler zu lesen.

Bevor Sie mit der XDP-Einrichtung fortfahren, müssen Sie zunächst den Interface-Namen ermitteln und auswählen.

ip -br link

Installieren Sie die Voraussetzungen.

sudo apt update
sudo apt install -y xdp-tools

Ersetzen Sie im folgenden Befehl <ifname> durch Ihren tatsächlichen Netzwerk-Interface-Namen, z. B. eth0 oder ens3.

sudo xdp-filter load -m skb <ifname>

Die ersten beiden Befehle sind für die Installation der erforderlichen Tools verantwortlich und stellen sicher, dass die Umgebung alles hat, was zum Ausführen der Demo benötigt wird.

Der dritte Befehl lädt dann xdp-filter im skb-Modus mit der Standard-allow-Richtlinie. Auf dem für diesen Artikel verwendeten Ubuntu-Host erzeugte das die xdpfilt_alw_all-Variante mit dem vollständigen tcp,udp,ipv6,ipv4,ethernet,allow-Feature-Set. Die Wahl von -m skb vermeidet die Annahme nativer XDP-Unterstützung in Ihrer NIC oder Ihrem Treiber und macht es zum sichereren Pfad für einen ersten Proof of Concept.

Um zu überprüfen, ob das Programm tatsächlich angehängt wurde, führen Sie aus:

sudo xdp-filter status
ip -details link show dev <ifname>

In xdp-filter status möchten Sie Ihr Interface mit skb mode aufgelistet sehen; auf dem hier verwendeten Testhost zeigte das geladene Feature-Set tcp,udp,ipv6,ipv4,ethernet,allow. In ip -details link show bestätigen eine xdpgeneric-Anhängung und das xdp_dispatcher-Programm, dass generisches XDP auf diesem Interface aktiv ist.

⚠️ Warnung: Testen Sie keine Deny-Default-Richtlinien oder breite Drop-Regeln auf einem live Remote-Interface, das Ihre SSH-Sitzung trägt, es sei denn, Sie haben eine Konsolen-Wiederherstellung. Dieser Artikel bleibt aus genau diesem Grund bei einer allow-Richtlinie und einer Dokumentationsadress-Regel.

Inspizieren Sie als nächstes die Capability-Erkennung. Dies zeigt Ihnen, was NIC und Treiber in der XDP-Oberfläche bereitstellen, nicht was Ihre endgültige Performance sein wird.

sudo xdp-loader features <ifname>

Die genaue Ausgabe variiert je nach Hardware, aber ein repräsentatives Ergebnis enthält oft Zeilen wie diese:

Am wichtigsten hier ist NETDEV_XDP_ACT_BASIC, denn das zeigt Ihnen, dass der Pfad das grundlegende XDP-Aktionsmodell bereitstellt. Zusätzliche Flags wie Redirect-Unterstützung sind nützlich, aber für einen einfachen Anti-DDoS-Proof-of-Concept nicht erforderlich.

Überprüfen Sie als nächstes, wie der XDP-Loader das Programm verwaltet und in welchem Modus es läuft.

sudo xdp-loader status

Auf einem funktionierenden System kann eine Statusansicht so aussehen:

Dies ist eine kleine, aber wichtige Operator-Prüfung. Sie bestätigt, dass XDP nicht nur ein Regelkonzept ist, das im User-Space lebt — es gibt ein geladenes Programm auf dem Interface, und die Modusspalte zeigt Ihnen, ob Sie native oder skb betrachten.

Fügen Sie nun eine sichere Beispielregel mit einer Dokumentations-IP-Adresse hinzu. Das -s-Flag ist hilfreich, weil es den resultierenden Regelzustand sofort ausgibt, anstatt Sie mit einem stillen Erfolg zu lassen.

sudo xdp-filter ip -s -m src 192.0.2.1

Eine repräsentative Antwort kann so aussehen:

📝 Hinweis: xdp-filter verwendet standardmäßig eine allow-Richtlinie. Mit anderen Worten: Pakete, die der Regel entsprechen, werden verworfen, und Pakete, die der Regel nicht entsprechen, werden durch den normalen Pfad weitergeleitet.

Dieses Beispiel ist absichtlich unspektakulär. In Anti-DDoS-Begriffen zeigt es auch die einfachstmögliche Version einer Early-Drop-Regel: Traffic von einer Quelle, die Sie nicht möchten, kann abgelehnt werden, bevor der Rest des Hosts viel Arbeit darin investiert.

Inspizieren Sie schließlich den Gesamtzustand an einem Ort.

sudo xdp-filter status

Auf einem typischen System ist das Ausgabemuster das informativste.

Diese Statusansicht ist der Punkt, an dem der Proof of Concept operativ nützlich wird. Sie können das geladene Interface, den aktiven Modus, die aktive xdp-filter-Variante, das effektive Feature-Set und den Zählerzustand pro Regel in einem Befehl sehen. XDP_ABORTED, falls es erscheint, ist hauptsächlich ein Fehler-/Debug-Bucket und keine Aktion, um die Sie planen. Wichtiger: Wenn der Drop-Zähler bei 0 bleibt, bedeutet das nicht, dass der Filter versagt hat. Es bedeutet nur, dass kein passendes Paket die Regel während des Erfassungsfensters getroffen hat.

💡 Fazit: Behandeln Sie xdp-filter als einfaches, zustandsloses Proof-of-Concept-Tool, nicht als Ersatz für nftables. Beachten Sie auch, dass Pakete, die auf der XDP-Schicht verworfen werden, möglicherweise nie im üblichen tcpdump-Pfad erscheinen, was die XDP-native Statusausgabe und Zähler zur zuverlässigeren Validierungsmethode macht. Wenn Sie später eine Live-Ansicht möchten, ist sudo xdp-filter poll -i 2000 ein sinnvoller optionaler nächster Schritt — aber nur, wenn das Interface bereits genug interessanten Traffic hat, um diese Ausgabe nützlich zu machen.

Ein sicheres Demo zu sehen macht die Idee konkret. Die eigentliche Entscheidung ist jedoch nicht, ob die Befehle ausgeführt werden. Es ist, ob diese zusätzliche Schicht die operative Komplexität auf der Art von Infrastruktur wert ist, die Sie tatsächlich verwalten.

Wann XDP für VPS und Dedicated Server in Betracht gezogen werden sollte

XDP wird interessant, wenn eine öffentlich zugängliche Arbeitslast bedeutende CPU-Zeit durch unerwünschte Pakete verliert, bevor die Anwendung normal reagieren kann. Gute Kandidaten sind öffentliche APIs, Reverse-Proxies, Gateways, internetexponierte UDP-lastige Dienste und Hosts, die regelmäßig genug Junk-Traffic sehen, um den Netzwerkpfad zu belasten, auch wenn die Anwendung selbst nicht der Engpass ist. In diesen Umgebungen kann früheres Ablehnen echten Server-Spielraum zurückgewinnen.

Es gibt auch viele Fälle, in denen einfacheres Filtern ausreicht. Eine wenig frequentierte Website, ein internes Tool, eine Staging-Box oder ein Dienst, dessen eigentliche Anforderung zustandsbehaftetes Host-Firewalling statt Paketrate-Entlastung ist, benötigt normalerweise kein XDP zuerst. Wenn nftables das Risiko bereits ohne merklichen Paketpfad-Druck abdeckt, kann das Hinzufügen einer weiteren Schicht mehr bewegliche Teile als Wert schaffen.

Als schnelles Entscheidungsframework:

• Firewalling ist in der Regel ausreichend, wenn der Traffic gering ist, die Richtlinie Zustand oder reichhaltigere Dienstlogik benötigt und der Host nicht sichtbar CPU durch Junk-Pakete verbrennt.
• XDP wird es wert, evaluiert zu werden, wenn unerwünschter Traffic den Host häufig genug erreicht, dass frühes Verwerfen CPU, Conntrack und Socket-Kapazität schützen könnte.
• Upstream-Mitigation bleibt obligatorisch, wenn der eigentliche Ausfallmodus Provider-Link-Sättigung oder größere volumetrische Floods sind, bevor die Pakete Ihren Server überhaupt erreichen.

VPS-Nutzer sollten einen Vorbehalt im Hinterkopf behalten: Virtuelle NIC-Pfade und Provider-Abstraktion können Native-Modus-Erwartungen einschränken, auch wenn der skb-Modus für eine Demo gut funktioniert. Dedicated Server geben Ihnen in der Regel mehr Kontrolle über Treiber, Hardware und Observability, sodass die Chancen auf sinnvolle Native-Modus-Unterstützung dort besser sind — aber selbst auf Bare Metal ist XDP immer noch eine Schicht, nicht die gesamte Antwort. Wenn Sie AlexHost oder einen anderen Anbieter evaluieren, stellen Sie drei separate Fragen, anstatt sie zusammenzufassen: Welche Upstream-DDoS-Behandlung existiert, wie viel Host-Spielraum gibt der Plan Ihnen, und welche Host-Level-Kontrollen sind auf dieser Plattform realistisch?

Fazit: XDP ist eine Early-Drop-Schicht, nicht der gesamte Schutzschild

Die klarste Art, über XDP nachzudenken, ist diese: Es gibt Linux einen schnellen ersten Kontrollpunkt für offensichtlich schlechten Traffic und Paket-Floods, was bedeutet, dass es Server-Ressourcen besser schützt als einen gesättigten Upstream-Link. Deshalb ist XDP in Anti-DDoS-Gesprächen relevant. Es ersetzt keine Upstream-Mitigation, kein zustandsbehaftetes Firewalling und keine anwendungsbewussten Kontrollen. Es hilft, indem es den Host weniger sinnlose Arbeit erledigen lässt.

Die Faustregel ist also einfach. Wenn unerwünschter Traffic Host-CPU verschwendet, bevor echte Workloads reagieren können, ist XDP es wert, als Early-Drop-Schicht evaluiert zu werden. Wenn das Hauptproblem ein voller Uplink oder eine Richtlinie ist, die von Zustand und Anwendungslogik abhängt, gehört XDP hinter Upstream-Mitigation und tieferes Filtern, anstatt als vollständige Antwort davor zu stehen. Ein natürlicher nächster Schritt von hier aus wäre ein Follow-up zum Schreiben benutzerdefinierter XDP-Programme oder zum Aufbau einer reichhaltigeren mehrschichtigen Verteidigung rund um dieselbe Early-Drop-Idee.