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 Game-Service oder eine andere internetfähige Workload betreiben, können Sie an einen schmerzhaften Punkt gelangen, an dem der Server mit Traffic beschäftigt ist, der von Anfang an nicht nützlich war. Die Anwendung schlägt nicht unbedingt fehl, weil sie echte Benutzer nicht verarbeiten kann. Sie schlägt fehl, weil der Host CPU-Zeit damit verbringt, nutzlose Pakete zu empfangen, zu analysieren, zu klassifizieren und tiefer in Linux zu transportieren, bevor etwas „Nein” sagt. Viele Anti-DDoS-Probleme beginnen dort: nicht als Bandbreitenproblem, sondern als Paketverarbeitungskostenproblem.

Das ist wichtig für mehr als nur Kernel-Spezialisten. Entwickler, Self-Hoster, VPS- und Dedicated-Server-Betreiber und sogar Business-Leser, die Resilienz-Optionen vergleichen, stoßen alle auf die gleiche grundlegende Frage: Wie früh kann schlechter Traffic abgelehnt werden, bevor er Zeit und Ressourcen verschlingt, die echte Arbeit gehören? Einige Angriffe zerstören 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.

Hier wird XDP verständlich. Es ersetzt keine Upstream-Mitigation, keine Firewall oder anwendungsspezifische 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 einen realistischen Stack passt. Um dem Rest zu folgen, benötigen Sie zunächst nur einen sehr kleinen Vokabelsatz.

XDP-Schlüsselbegriffe in 2 Minuten

Mehrere der Begriffe rund um XDP überlappen sich, und zunächst klingen sie einschüchternder, als sie wirklich sind. Das ist normal. Der Zweck dieses Glossars ist nicht, den Artikel in eine Linux-Internals-Lektion zu verwandeln. Es ist nur genug Sprache, um die restliche Erklärung sauber zu vermitteln.

Wenn Sie nur eine mentale Abkürzung aus dieser Tabelle behalten, 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ühes Packet-Processing-Hook in Linux. Es ermöglicht dem System, ein kleines eBPF-Programm auf ein Paket auszuführen, sobald dieses Paket auf einer Netzwerkschnittstelle ankommt. In diesem Moment kann Linux eine schnelle Entscheidung treffen: das Paket weiterlassen (XDP_PASS), es sofort verwerfen (XDP_DROP) oder es auf andere definierte Weise handhaben. Für diesen Artikel ist der wichtige Teil einfach: XDP kann sehr früh sagen „lass es durch” oder „stoppe es hier”.

Linux verwendet eBPF in mehreren Kontexten, nicht nur beim Networking. XDP ist die Networking-fokussierte Version, die für sehr frühe Handhabung eingehender Pakete entwickelt wurde. XDP ist also nicht ein anderes Wort für eBPF. Es ist ein eBPF-basiertes Tool mit einer sehr spezifischen Rolle.

Diese Rolle ist es, die XDP für Anti-DDoS-Arbeiten nützlich macht. 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 aufwendet. Deshalb ist der echte Vorteil von XDP nicht nur Filterung — es ist Filterung früher.

Darüber hinaus ist XDP für mehr als Anti-DDoS nützlich. Es kann auch Traffic Steering und andere Packet-Handling-Aufgaben unterstützen. Aber Anti-DDoS ist der einfachste Ort, um seinen Wert zu sehen, denn der Vorteil läuft auf eine praktische Idee hinaus: Je früher schlechter Traffic abgelehnt wird, desto weniger nutzlose Arbeit muss der Server leisten. Und um zu verstehen, warum das so wichtig ist, besteht der nächste Schritt darin, genau zu schauen, wo XDP im Packet-Receive-Pfad sitzt.

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

Die einfachste Vorstellung von XDP ist die eines Sicherheitsbeamten am Tor und nicht eines Empfangsmitarbeiters tiefer im Gebäude. Wenn ein offensichtlich unerwünschter Besucher am Tor abgewiesen wird, spart sich 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 wartet, bis zum Empfangstresen, um ihn abzulehnen, hat das Gebäude bereits Zeit und Aufmerksamkeit auf die falsche Person verwendet.

Die Linux-Paketverarbeitung funktioniert genauso. In einem vereinfachten Empfangspfad kommt das Paket von der NIC und dem Treiber an, erreicht XDP und setzt dann seinen Weg in den reichhaltigeren Kernel-Netzwerk-Stack fort, der conntrack, Firewalling, Sockets und schließlich die Anwendung speist. Visuell dargestellt sieht der Pfad so aus:

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

Im nativen Modus kann XDP handeln, bevor Linux die übliche sk_buff-Struktur zuweist und füllt — das reichhaltigere Kernel-Paketobjekt, das der Rest des Stacks erwartet. Dieses Detail klingt klein, ist aber das Herz der Performance-Geschichte. Wenn das Paket offensichtlich unerwünscht ist, bedeutet das Verwerfen vor dem Aufbau dieser normalen Struktur weniger CPU-Arbeit, weniger Speicherchurn und weniger Druck auf nachgelagerte Systeme. XDP_PASS existiert, weil nicht jedes Paket schlecht ist; es ist die „weitermachen”-Aktion, die legitimen Datenverkehr in Bewegung hält. XDP_DROP ist der Anti-DDoS-Star, weil es die Reise beendet, bevor der teure Teil beginnt. Andere Aktionen wie REDIRECT existieren auch, sind aber für diese Erklärung nicht tragend.

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

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

Der Anti-DDoS-Fall für XDP ist unkompliziert: Es ist eine kostengünstige Möglichkeit, offensichtliche Müllpakete abzulehnen, bevor Linux Ressourcen für conntrack, Socket-Handling und User-Space-Zustellung aufwendet. Wenn ein Host mit hochfrequentem Traffic bombardiert wird, der die Anwendung ohnehin nie erreichen sollte, ist jedes Paket, das früh verworfen wird, Arbeit, die der Server später nicht mehr leisten muss. Deshalb ist XDP am stärksten am L3/L4-Rand des Problems: Quelladressen, denen Sie bereits misstrauen, Protokolle, die Sie nicht möchten, oder Traffic-Muster, die für die Workload eindeutig nicht legitim sind.

Dies ist am wichtigsten bei Junk-Floods, bei denen der schmerzhafteste Teil nicht das rohe Datenvolumen ist, sondern die wiederholte Paketverarbeitung. Ein Reverse Proxy, ein UDP-lastiger Service oder eine öffentliche API können lange vor der vollständigen Auslastung des Uplinks langsam werden, wenn der Host damit beschäftigt ist, Unsinn zu klassifizieren. XDP bietet Ihnen eine Möglichkeit, einen Teil dieser Verschwendung nahe der Tür abzuschneiden.

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

Diese Unterscheidung ist der Hauptgrund, warum XDP in ein geschichtetes Design gehört und nicht auf ein Podest. 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 Pfads. nftables ist umfassender 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 so zu tun, als würde es eine vollständige Firewall ersetzen. Wenn Sie Connection Tracking, geschichtete Allowlists, Reply-State-Handling oder anwendungsorientierte Regeln benötigen, beschreiben Sie bereits Probleme, die tiefer als dieses Demo-Utility gehören.

Produktionsoperatoren verwenden XDP-ähnliches Verwerfen, weil frühes Verwerfen die nachgelagerte Arbeit reduziert. Cloudflares L4Drop-Geschichte ist ein bekanntes Beispiel dafür, warum dieses Modell in echten Operationen attraktiv wurde. Aber die wichtigste Lektion ist nicht nur die Schlagzahl-Paketanzahl pro Sekunde. Es ist die Designlogik: Lehnen Sie schlechten Traffic früher ab, damit der Rest der Maschine echten Traffic länger bedienen kann.

Die Ergebnisse in der Praxis hängen stark von der Umgebung ab. NIC- und Treiberunterstützung, ob XDP im nativen oder skb-Modus läuft, und die Form des eingehenden Traffics beeinflussen alle, wie viel Nutzen Sie tatsächlich erhalten. Deshalb sollten Schlagzahl-Paketanzahl-pro-Sekunde-Zahlen von Anbietern oder Hyperscalern am besten als Beweis behandelt werden, dass das Early-Drop-Modell funktioniert, nicht als Zahlen, die jeder VPS erwarten sollte. Vor 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 — Command-Snapshots

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

Bevor Sie mit dem XDP-Setup fortfahren, müssen Sie zuerst den Schnittstellennamen entdecken 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 Netzwerkschnittstellennamen, 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 erforderlich ist.

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

Um zu überprüfen, dass 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 Ihre Schnittstelle mit skb mode aufgelistet sehen; auf dem Test-Host hier zeigte das geladene Feature-Set tcp,udp,ipv6,ipv4,ethernet,allow. In ip -details link show bestätigen eine xdpgeneric-Anhängung und das Programm xdp_dispatcher, dass generisches XDP auf dieser Schnittstelle aktiv ist.

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

Überprüfen Sie anschließend die Funktionserkennung. Dies zeigt Ihnen, was die NIC und der Treiber in der XDP-Oberfläche verfügbar machen, nicht welche endgültige Leistung Sie erhalten.

sudo xdp-loader features <ifname>

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

Das Wichtigste hier ist NETDEV_XDP_ACT_BASIC, da dies anzeigt, dass der Pfad das Core-XDP-Action-Modell verfügbar macht. Zusätzliche Flags wie Redirect-Unterstützung sind nützlich, aber nicht erforderlich für einen einfachen Anti-DDoS-Proof of Concept.

Überprüfen Sie anschließend, wie der XDP-Loader das Programm verwaltet und in welchem Modus es ausgeführt wird.

sudo xdp-loader status

Auf einem funktionierenden System kann eine Statusansicht wie folgt aussehen:

Dies ist eine kleine, aber wichtige Operator-Überprüfung. Sie bestätigt, dass XDP nicht nur ein Regelkonzept ist, das im Benutzerbereich lebt — es gibt ein geladenes Programm auf der Schnittstelle, und die Mode-Spalte zeigt Ihnen, ob Sie native oder skb betrachten.

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

sudo xdp-filter ip -s -m src 192.0.2.1

Eine repräsentative Antwort kann wie folgt aussehen:

📝 Hinweis: xdp-filter verwendet standardmäßig eine allow-Richtlinie. Mit anderen Worten, Pakete, die der Regel entsprechen, werden gelöscht, und Pakete, die nicht der Regel entsprechen, werden über den normalen Pfad fortgesetzt.

Dieses Beispiel ist absichtlich langweilig. In Anti-DDoS-Begriffen zeigt es auch die einfachste mögliche Version einer frühen Drop-Regel: Datenverkehr von einer Quelle, die Sie nicht mögen, kann abgelehnt werden, bevor der Rest des Hosts viel Arbeit darin investiert.

Überprüfen Sie abschließend den Gesamtzustand an einer Stelle.

sudo xdp-filter status

Auf einem typischen System ist das Ausgabemuster das informativste.

Diese Statusansicht ist, wo der Proof of Concept operativ nützlich wird. Sie können die geladene Schnittstelle, den aktiven Modus, die aktive xdp-filter-Variante, das effektive Feature-Set und den Pro-Regel-Zählerzustand in einem Befehl sehen. XDP_ABORTED ist, falls es angezeigt wird, hauptsächlich ein Fehler-/Debug-Bucket und nicht die Aktion, die Sie planen. Wichtiger ist, dass wenn der Drop-Zähler bei 0 bleibt, das nicht bedeutet, dass der Filter fehlgeschlagen ist. Es bedeutet nur, dass während des Erfassungsfensters kein passendes Paket die Regel 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-Ebene gelöscht werden, möglicherweise nie im üblichen tcpdump-Pfad angezeigt werden, was 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 die Schnittstelle bereits genug interessanten Datenverkehr hat, um diese Ausgabe nützlich zu machen.

Ein sicheres Demo zu sehen macht die Idee konkret. Die echte Entscheidung ist jedoch nicht, ob die Befehle ausgeführt werden. Es ist, ob diese zusätzliche Ebene die operationale 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 Workload bedeutsame CPU-Zeit durch unerwünschte Pakete verliert, bevor die Anwendung normal reagieren kann. Gute Kandidaten sind öffentliche APIs, Reverse Proxies, Gateways, internetexponierte UDP-lastige Services und Hosts, die regelmäßig genug Junk-Traffic sehen, um den Netzwerkpfad zu belasten, auch wenn die Anwendung selbst nicht der Engpass ist. In solchen Umgebungen kann frühes Verwerfen echten Server-Headroom zurückgewinnen.

Es gibt auch viele Fälle, in denen einfachere Filterung ausreicht. Eine Website mit geringem Traffic, ein internes Tool, eine Staging-Box oder ein Service, dessen echte Anforderung eher stateful Host-Firewalling als Paketrate-Entlastung ist, benötigt normalerweise nicht zuerst XDP. Wenn nftables das Risiko bereits ohne spürbaren Paketpfad-Druck abdeckt, kann das Hinzufügen einer weiteren Schicht mehr bewegliche Teile als Wert schaffen.

Als schnelles Entscheidungsframework:

• Firewalling ist normalerweise ausreichend, wenn der Traffic gering ist, die Policy State oder reichere Service-Logik benötigt, und der Host nicht sichtbar CPU bei Junk-Paketen verschwendet.
• XDP wird zur Evaluierung wert, wenn unerwünschter Traffic den Host oft genug erreicht, dass frühes Verwerfen CPU, conntrack und Socket-Kapazität schützen könnte.
• Upstream-Mitigation bleibt obligatorisch, wenn der echte Fehlermodus Provider-Link-Sättigung oder größere volumetrische Flooding ist, bevor die Pakete überhaupt Ihren Server erreichen.

VPS-Benutzer sollten eine Einschränkung beachten: virtuelle NIC-Pfade und Provider-Abstraktion können native-mode-Erwartungen begrenzen, auch wenn skb-Modus für eine Demo gut funktioniert. Dedicated Server geben Ihnen normalerweise mehr Kontrolle über Treiber, Hardware und Observability, daher sind die Chancen auf aussagekräftige native-mode-Unterstützung dort besser — aber auch auf Bare Metal ist XDP immer noch eine Schicht, nicht die ganze Antwort. Wenn Sie AlexHost oder einen anderen Provider evaluieren, stellen Sie stattdessen drei separate Fragen: Welches Upstream-DDoS-Handling existiert, wie viel Host-Headroom gibt der Plan Ihnen, und welche Host-Level-Kontrollen sind auf dieser Plattform realistisch?

Fazit: XDP ist eine Early-Drop-Schicht, nicht der komplette Schutz

Die sauberste Art, über XDP nachzudenken, ist diese: Es gibt Linux einen schnellen ersten Kontrollpunkt für offensichtlich schlechten Traffic und Paketfluten, was bedeutet, dass es Serverressourcen besser schützt als einen gesättigten Upstream-Link. Deshalb ist XDP in Anti-DDoS-Gesprächen wichtig. Es ersetzt keine Upstream-Mitigation, stateful Firewalling oder anwendungsorientierte Kontrollen. Es hilft, indem es den Host weniger sinnlose Arbeit verrichten lässt.

Die Faustregel ist also einfach. Wenn unerwünschter Traffic Host-CPU verschwendet, bevor echte Workloads reagieren können, ist XDP eine Evaluierung als Early-Drop-Schicht wert. Wenn das Hauptproblem ein voller Uplink oder eine Richtlinie ist, die von State und Anwendungslogik abhängt, gehört XDP hinter Upstream-Mitigation und tiefere Filterung statt davor als vollständige Lösung. Ein natürlicher nächster Schritt wäre eine Folge zum Schreiben von benutzerdefinierten XDP-Programmen oder zum Aufbau einer umfassenderen geschichteten Verteidigung rund um die gleiche Early-Drop-Idee.