Co to jest XDP i jak może pomóc w budowaniu ochrony przed atakami DDoS?

Wprowadzenie do XDP i jak może pomóc w budowaniu ochrony przed DDoS?

Jeśli prowadzisz publiczne API, reverse proxy, usługę gamingową lub inne obciążenie dostępne z internetu, możesz natknąć się na bolesny punkt, w którym serwer jest zajęty ruchem, który od samego początku nie był użyteczny. Aplikacja niekoniecznie zawodzi dlatego, że nie może obsłużyć prawdziwych użytkowników. Zawodzi, ponieważ host spędza czas CPU na odbieraniu, parsowaniu, klasyfikowaniu i przenoszeniu śmieciowych pakietów głębiej do Linuksa, zanim cokolwiek powie „nie”. Wiele problemów z ochroną przed DDoS zaczyna się właśnie tam: nie jako historia o przepustowości, ale jako historia o kosztach przetwarzania pakietów.

Ma to znaczenie nie tylko dla specjalistów od jądra systemu. Deweloperzy, osoby hostujące własne usługi, operatorzy VPS i serwerów dedykowanych, a nawet czytelnicy biznesowi porównujący opcje odporności — wszyscy napotykają to samo podstawowe pytanie: jak wcześnie można odrzucić zły ruch, zanim pochłonie czas i zasoby, które powinny należeć do prawdziwej pracy? Niektóre ataki przeciążają samo łącze, ale wiele szkodliwych sytuacji pojawia się wcześniej jako presja pakietów na sekundę na hoście, na długo przed pełnym nasyceniem łącza.

Właśnie dlatego warto zrozumieć XDP. Nie zastępuje on upstream mitigation, firewalla ani kontroli świadomych aplikacji. To, co oferuje, to znacznie wcześniejszy punkt kontrolny w ścieżce pakietów Linuksa. Ten artykuł wyjaśnia, czym jest XDP, dlaczego ta „wcześniejsza” pozycja ma znaczenie dla ochrony przed DDoS i gdzie pasuje do realistycznego stosu. Aby śledzić dalszą część, potrzebujesz najpierw tylko bardzo małego zestawu słownictwa.

Słowa kluczowe XDP, które musisz znać w 2 minuty

Kilka terminów związanych z XDP nakłada się na siebie i na początku brzmią bardziej onieśmielająco niż są w rzeczywistości. To normalne. Celem tego słowniczka nie jest zamienienie artykułu w lekcję o wewnętrznościach Linuksa. To tylko tyle języka, ile potrzeba, aby reszta wyjaśnienia była zrozumiała.

Jeśli zachowasz tylko jeden skrót myślowy z tej tabeli, niech będzie to: eBPF to programowalny mechanizm, a XDP to jedno konkretne miejsce, w którym ten mechanizm może działać. Mając to na uwadze, następnym krokiem jest prostsze i bardziej użyteczne pytanie: co właściwie robi XDP?

Czym naprawdę jest XDP

XDP to wczesny hook do przetwarzania pakietów w Linuksie. Pozwala systemowi uruchomić mały program eBPF na pakiecie, gdy tylko ten pakiet dotrze do interfejsu sieciowego. W tym momencie Linux może podjąć szybką decyzję: przepuścić pakiet dalej (XDP_PASS), natychmiast go odrzucić (XDP_DROP) lub obsłużyć go w inny zdefiniowany sposób. Na potrzeby tego artykułu ważna część jest prosta: XDP może powiedzieć „przepuść” lub „zatrzymaj tutaj” bardzo wcześnie.

Linux używa eBPF w kilku kontekstach, nie tylko w sieci. XDP to wersja skoncentrowana na sieci, zbudowana do bardzo wczesnej obsługi przychodzących pakietów. Tak więc XDP nie jest inną nazwą dla eBPF. Jest to jedno narzędzie oparte na eBPF z bardzo konkretną rolą.

Ta rola sprawia, że XDP jest przydatny w ochronie przed DDoS. XDP działa zanim pakiety przejdą przez normalne, cięższe części ścieżki sieciowej Linuksa. Dzięki temu Linux może podjąć decyzję dotyczącą niektórych pakietów, zanim poświęci więcej wysiłku na firewalling, śledzenie połączeń, gniazda i ostatecznie samą aplikację. Dlatego prawdziwą zaletą XDP nie jest tylko filtrowanie — to filtrowanie wcześniej.

Ponadto XDP jest przydatny nie tylko do ochrony przed DDoS. Może również wspierać kierowanie ruchem i inne zadania obsługi pakietów. Ale ochrona przed DDoS to najłatwiejsze miejsce, w którym można dostrzec jego wartość, ponieważ korzyść sprowadza się do jednej praktycznej idei: im wcześniej zły ruch zostanie odrzucony, tym mniej bezużytecznej pracy musi wykonać serwer. A żeby zrozumieć, dlaczego ma to tak duże znaczenie, następnym krokiem jest przyjrzenie się dokładnie temu, gdzie XDP znajduje się w ścieżce odbierania pakietów.

Model mentalny: XDP to brama, nie recepcja

Najłatwiejszym sposobem wyobrażenia sobie XDP jest strażnik przy bramie, a nie recepcjonista głębiej w budynku. Jeśli oczywiście niepożądany gość zostanie odprawiony przy bramie, budynek unika długiego łańcucha bezcelowej pracy. Nikt nie otwiera wewnętrznych drzwi, nie rejestruje go w systemie ani nie prowadzi przez korytarz. Jeśli poczekasz do recepcji, żeby go odrzucić, budynek już poświęcił czas i uwagę na niewłaściwą osobę.

Obsługa pakietów w Linuksie działa tak samo. W uproszczonej ścieżce odbierania pakiet przybywa z NIC i sterownika, dociera do XDP, a dopiero potem trafia do bogatszego stosu sieciowego jądra, który zasila conntrack, firewalling, gniazda i ostatecznie aplikację. Wizualnie ścieżka wygląda tak:

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

W trybie natywnym XDP może działać zanim Linux przydzieli i wypełni zwykłą strukturę sk_buff — bogatszy obiekt pakietu jądra, którego oczekuje reszta stosu. Ten szczegół brzmi drobnie, ale jest sercem historii o wydajności. Jeśli pakiet jest oczywiście niepożądany, odrzucenie go zanim Linux zbuduje tę normalną strukturę oznacza mniej pracy CPU, mniejsze zużycie pamięci i mniejszą presję na dalsze etapy. XDP_PASS istnieje, ponieważ nie każdy pakiet jest zły; to akcja „kontynuuj”, która pozwala legalnemu ruchowi poruszać się dalej. XDP_DROP to gwiazda ochrony przed DDoS, ponieważ kończy podróż zanim zacznie się kosztowna część. Istnieją też inne akcje, takie jak REDIRECT, ale nie są one kluczowe dla tego wyjaśnienia.

Gdy rozmieszczenie jest jasne, wartość w kontekście ochrony przed DDoS — i ograniczenia — stają się znacznie łatwiejsze do realistycznej oceny.

Jak XDP pomaga w ochronie przed DDoS — i gdzie zaczynają się jego ograniczenia

Przypadek użycia XDP w ochronie przed DDoS jest prosty: to tani sposób na odrzucenie oczywistych śmieci, zanim Linux poświęci zasoby na conntrack, obsługę gniazd i dostarczanie do przestrzeni użytkownika. Jeśli host jest zasypywany ruchem o wysokiej częstotliwości, który i tak nigdy nie powinien dotrzeć do aplikacji, każdy wcześnie odrzucony pakiet to praca, której serwer nie musi już wykonywać później. Dlatego XDP jest najsilniejszy na krawędzi L3/L4 problemu: adresy źródłowe, którym już nie ufasz, protokoły, których nie chcesz, lub wzorce ruchu, które wyraźnie nie są legalne dla danego obciążenia.

Ma to największe znaczenie podczas zalewów śmieciowym ruchem, gdzie bolesną częścią nie jest surowa objętość danych, ale wielokrotna obsługa pakietów. Reverse proxy, usługa intensywnie korzystająca z UDP lub publiczne API może stać się powolne na długo przed pełnym nasyceniem łącza, jeśli host jest zajęty klasyfikowaniem nonsensów. XDP daje ci sposób na odcięcie części tego marnotrawstwa blisko drzwi.

📝 Uwaga: XDP lepiej chroni zasoby hosta niż nasycone łącze upstream. Jeśli łącze po stronie dostawcy jest już pełne, wczesne odrzucanie na poziomie hosta jest zbyt późne, aby samodzielnie naprawić ścieżkę sieciową.

To rozróżnienie jest głównym powodem, dla którego XDP należy do warstwowego projektu, a nie na piedestale. Poniższa tabela to praktyczna wersja porównania XDP vs nftables vs upstream/provider mitigation:

Innymi słowy, XDP i nftables nie są wrogami. Rozwiązują różne części ścieżki. nftables jest bogatszy i stanowy. xdp-filter — narzędzie demonstracyjne używane w tym artykule — jest celowo proste i bezstanowe, co jest dokładnie powodem, dla którego jest przydatne do pokazania modelu XDP bez udawania, że zastępuje pełny firewall. Jeśli potrzebujesz śledzenia połączeń, warstwowych list dozwolonych, obsługi stanu odpowiedzi lub reguł świadomych aplikacji, opisujesz już problemy, które należą głębiej niż to narzędzie demonstracyjne.

Operatorzy produkcyjni używają odrzucania w stylu XDP, ponieważ wczesne odrzucanie zmniejsza pracę na dalszych etapach. Historia L4Drop Cloudflare jest dobrze znany przykładem tego, dlaczego ten model stał się atrakcyjny w rzeczywistych operacjach. Ale ważna lekcja to nie tylko nagłówkowa liczba pakietów na sekundę. To logika projektowania: odrzucaj zły ruch wcześniej, aby reszta maszyny mogła dłużej obsługiwać prawdziwy ruch.

Rzeczywiste wyniki zależą w dużej mierze od środowiska. Obsługa NIC i sterownika, to czy XDP działa w trybie natywnym czy skb, oraz kształt przychodzącego ruchu — wszystko to wpływa na to, ile korzyści faktycznie uzyskasz. Dlatego nagłówkowe liczby pakietów na sekundę od dostawców lub hiperskalerów najlepiej traktować jako dowód, że model wczesnego odrzucania działa, a nie jako liczby, których każdy VPS powinien się spodziewać. Mając to na uwadze, następna sekcja pokazuje, jak XDP wygląda na prawdziwym hoście Ubuntu poprzez kilka bezpiecznych migawek operatorskich.

Jak XDP wygląda w praktyce — migawki poleceń

Ta sekcja to migawka proof-of-concept. Celem jest sprawienie, by XDP był realny na Ubuntu 24.04 z odpowiednim zestawem poleceń: wystarczającym do załadowania filtra, sprawdzenia co zostało dołączone, dodania jednej reguły niskiego ryzyka i odczytania ważnych liczników.

Przed przystąpieniem do konfiguracji XDP musisz najpierw odkryć i wybrać nazwę interfejsu.

ip -br link

Zainstaluj wymagania wstępne.

sudo apt update
sudo apt install -y xdp-tools

W poniższym poleceniu zastąp <ifname> rzeczywistą nazwą interfejsu sieciowego, taką jak eth0 lub ens3.

sudo xdp-filter load -m skb <ifname>

Pierwsze dwa polecenia są odpowiedzialne za instalację wymaganych narzędzi, zapewniając, że środowisko ma wszystko, czego potrzeba do uruchomienia demonstracji.

Trzecie polecenie ładuje następnie xdp-filter w trybie skb z domyślną polityką allow. Na hoście Ubuntu używanym w tym artykule dało to wariant xdpfilt_alw_all z pełnym zestawem funkcji tcp,udp,ipv6,ipv4,ethernet,allow. Wybór -m skb pozwala uniknąć zakładania natywnej obsługi XDP w NIC lub sterowniku, co czyni go bezpieczniejszą ścieżką dla pierwszego proof of concept.

Aby sprawdzić, czy program faktycznie został dołączony, uruchom:

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

W xdp-filter status chcesz zobaczyć swój interfejs wymieniony z skb mode; na hoście testowym tutaj załadowany zestaw funkcji pokazał tcp,udp,ipv6,ipv4,ethernet,allow. W ip -details link show, dołączenie xdpgeneric i program xdp_dispatcher potwierdzają, że generyczny XDP jest aktywny na tym interfejsie.

⚠️ Ostrzeżenie: Nie testuj polityk deny-default ani szerokich reguł odrzucania na aktywnym zdalnym interfejsie, który obsługuje twoją sesję SSH, chyba że masz odzyskiwanie przez konsolę. Ten artykuł pozostaje przy polityce allow i jednej regule adresu dokumentacyjnego właśnie z tego powodu.

Następnie sprawdź wykrywanie możliwości. Mówi to, co NIC i sterownik udostępniają na powierzchni XDP, a nie jaka będzie twoja końcowa wydajność.

sudo xdp-loader features <ifname>

Dokładne wyjście różni się w zależności od sprzętu, ale reprezentatywny wynik często zawiera takie linie:

Najważniejsze tutaj jest NETDEV_XDP_ACT_BASIC, ponieważ mówi ci, że ścieżka udostępnia podstawowy model akcji XDP. Dodatkowe flagi, takie jak obsługa przekierowania, są przydatne, ale nie są wymagane do prostego proof of concept ochrony przed DDoS.

Następnie sprawdź, jak loader XDP zarządza programem i w jakim trybie działa.

sudo xdp-loader status

Na działającym systemie widok statusu może wyglądać tak:

To małe, ale ważne sprawdzenie operatorskie. Potwierdza, że XDP to nie tylko koncepcja reguły żyjąca w przestrzeni użytkownika — na interfejsie jest załadowany program, a kolumna trybu mówi ci, czy patrzysz na native czy skb.

Teraz dodaj jedną bezpieczną przykładową regułę używając adresu IP dokumentacji. Flaga -s jest pomocna, ponieważ natychmiast drukuje wynikowy stan reguły zamiast pozostawiać cię z cichym sukcesem.

sudo xdp-filter ip -s -m src 192.0.2.1

Reprezentatywna odpowiedź może wyglądać tak:

📝 Uwaga: xdp-filter domyślnie stosuje politykę allow. Innymi słowy, pakiety pasujące do reguły są odrzucane, a pakiety niepasujące do reguły kontynuują przez normalną ścieżkę.

Ten przykład jest celowo nudny. W kategoriach ochrony przed DDoS pokazuje również najprostszą możliwą wersję reguły wczesnego odrzucania: ruch ze źródła, którego nie chcesz, może zostać odrzucony zanim reszta hosta zainwestuje w niego dużo pracy.

Na koniec sprawdź ogólny stan w jednym miejscu.

sudo xdp-filter status

Na typowym systemie wzorzec wyjścia jest najbardziej informatywny.

Ten widok statusu to miejsce, w którym proof of concept staje się operacyjnie użyteczny. Możesz zobaczyć załadowany interfejs, aktywny tryb, aktywny wariant xdp-filter, efektywny zestaw funkcji i stan licznika per-reguła w jednym poleceniu. XDP_ABORTED, jeśli się pojawi, jest głównie zasobnikiem błędów/debugowania, a nie akcją, wokół której planujesz. Co ważniejsze, jeśli licznik odrzuceń pozostaje na 0, nie oznacza to, że filtr zawiódł. Oznacza tylko, że żaden pasujący pakiet nie trafił w regułę podczas okna przechwytywania.

💡 Wniosek: Traktuj xdp-filter jako proste, bezstanowe narzędzie proof-of-concept, a nie zastępstwo dla nftables. Pamiętaj też, że pakiety odrzucone na warstwie XDP mogą nigdy nie pojawić się w zwykłej ścieżce tcpdump, co sprawia, że natywne wyjście statusu XDP i liczniki są bardziej niezawodną metodą walidacji. Jeśli chcesz później uzyskać widok na żywo, sudo xdp-filter poll -i 2000 jest sensownym opcjonalnym następnym krokiem — ale tylko wtedy, gdy interfejs ma już wystarczająco interesujący ruch, aby to wyjście było użyteczne.

Zobaczenie bezpiecznej demonstracji sprawia, że pomysł staje się konkretny. Prawdziwa decyzja jednak nie dotyczy tego, czy polecenia działają. Chodzi o to, czy ta dodatkowa warstwa jest warta złożoności operacyjnej na rodzaju infrastruktury, którą faktycznie zarządzasz.

Kiedy warto rozważyć XDP dla VPS i serwerów dedykowanych

XDP staje się interesujący, gdy obciążenie dostępne publicznie traci znaczący czas CPU na niepożądanych pakietach, zanim aplikacja może normalnie odpowiedzieć. Dobrymi kandydatami są publiczne API, reverse proxy, bramy, usługi intensywnie korzystające z UDP dostępne z internetu oraz hosty, które regularnie widzą wystarczająco dużo śmieciowego ruchu, aby obciążyć ścieżkę sieciową, nawet gdy sama aplikacja nie jest wąskim gardłem. W takich środowiskach wcześniejsze odrzucanie może odzyskać realne zasoby serwera.

Istnieje też wiele przypadków, w których prostsze filtrowanie jest wystarczające. Strona internetowa o małym ruchu, narzędzie wewnętrzne, środowisko testowe lub usługa, której prawdziwym wymaganiem jest stanowy firewalling hosta, a nie ulga od szybkości pakietów, zazwyczaj nie potrzebuje najpierw XDP. Jeśli nftables już pokrywa ryzyko bez zauważalnej presji na ścieżkę pakietów, dodanie kolejnej warstwy może stworzyć więcej ruchomych części niż wartości.

Jako szybka struktura decyzyjna:

• Firewalling jest zazwyczaj wystarczający, gdy ruch jest lekki, polityka wymaga stanu lub bogatszej logiki usług, a host nie spala widocznie CPU na śmieciowych pakietach.
• XDP warto ocenić, gdy niepożądany ruch dociera do hosta wystarczająco często, że wczesne odrzucanie mogłoby chronić CPU, conntrack i pojemność gniazd.
• Upstream mitigation pozostaje obowiązkowe, gdy prawdziwym trybem awarii jest nasycenie łącza dostawcy lub większe zalewanie wolumetryczne, zanim pakiety w ogóle dotrą do twojego serwera.

Użytkownicy VPS powinni mieć na uwadze jedno zastrzeżenie: wirtualne ścieżki NIC i abstrakcja dostawcy mogą ograniczać oczekiwania dotyczące trybu natywnego, nawet gdy tryb skb działa dobrze w demonstracji. Serwery dedykowane zazwyczaj dają ci większą kontrolę nad sterownikami, sprzętem i obserwowalnością, więc szanse na znaczącą obsługę trybu natywnego są tam lepsze — ale nawet na bare metal, XDP to nadal jedna warstwa, a nie cała odpowiedź. Jeśli oceniasz AlexHost lub innego dostawcę, zadaj trzy oddzielne pytania zamiast łączyć je razem: jaka upstream obsługa DDoS istnieje, ile zasobów hosta daje ci plan i jakie kontrole na poziomie hosta są realistyczne na tej platformie?

Podsumowanie: XDP to warstwa wczesnego odrzucania, a nie cała tarcza

Najczystszy sposób myślenia o XDP jest taki: daje Linuksowi szybki pierwszy punkt kontrolny dla oczywistego złego ruchu i zalewów pakietów, co oznacza, że lepiej chroni zasoby serwera niż nasycone łącze upstream. Dlatego XDP ma znaczenie w rozmowach o ochronie przed DDoS. Nie zastępuje upstream mitigation, stanowego firewallingu ani kontroli świadomych aplikacji. Pomaga sprawiając, że host wykonuje mniej bezcelowej pracy.

Zasada kciuka jest więc prosta. Jeśli niepożądany ruch marnuje CPU hosta, zanim prawdziwe obciążenia mogą odpowiedzieć, XDP warto ocenić jako warstwę wczesnego odrzucania. Jeśli głównym problemem jest pełne łącze lub polityka zależna od stanu i logiki aplikacji, XDP należy za upstream mitigation i głębszym filtrowaniem, a nie przed nimi jako kompletna odpowiedź. Naturalnym następnym krokiem stąd byłoby kontynuowanie tematu pisania niestandardowych programów XDP lub budowania bogatszej warstwowej obrony wokół tej samej idei wczesnego odrzucania.