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 obsługą ruchu, który nigdy 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 koszcie przetwarzania pakietów.

To ma 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 spali czas i zasoby, które powinny należeć do prawdziwej pracy? Niektóre ataki niszczą 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 tutaj XDP staje się wart zrozumienia. Nie zastępuje 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ć resztę, 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ętrznych mechanizmach Linuksa. To tylko tyle języka, 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 miejscu, następnym krokiem jest prostsze i bardziej użyteczne pytanie: co XDP właściwie robi?

Czym XDP naprawdę jest

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ę: pozwolić pakietowi kontynuować (XDP_PASS), natychmiast go odrzucić (XDP_DROP) lub obsłużyć go w inny zdefiniowany sposób. Dla 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. Zatem XDP nie jest innym słowem dla eBPF. Jest jednym narzędziem opartym na eBPF z bardzo konkretną rolą.

Ta rola sprawia, że XDP jest użyteczny 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ą pewnego ruchu, zanim poświęci więcej wysiłku na firewalling, śledzenie połączeń, gniazda i ostatecznie samą aplikację. Dlatego prawdziwą zaletą XDP jest nie tylko filtrowanie — to filtrowanie wcześniej.

Ponadto XDP jest użyteczny nie tylko w ochronie przed DDoS. Może również wspierać kierowanie ruchem i inne zadania obsługi pakietów. Ale ochrona przed DDoS jest najłatwiejszym miejscem do dostrzeżenia jego wartości, 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 to ma tak duże znaczenie, następnym krokiem jest przyjrzenie się dokładnie temu, gdzie XDP siedzi 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ść zostaje 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 kontynuuje do bogatszego kernel networking stack, 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 native mode 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 legalnym pakietom poruszać się dalej. XDP_DROP to gwiazda ochrony przed DDoS, ponieważ kończy podróż zanim zaczyna się kosztowna część. Istnieją też inne akcje, takie jak REDIRECT, ale nie są one kluczowe dla tego wyjaśnienia.

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

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

Argument za XDP w ochronie przed DDoS jest prosty: to tani sposób na odrzucenie oczywistych śmieci, zanim Linux wyda zasoby na conntrack, obsługę gniazd i dostarczanie do user-space. Jeśli host jest bombardowany 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 mogą stać się wolne 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 demo używane w tym artykule — jest celowo proste i bezstanowe, co jest dokładnie powodem, dla którego jest użyteczne 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 demo.

Operatorzy produkcyjni używają odrzucania w stylu XDP, ponieważ wczesne odrzucanie zmniejsza pracę downstream. 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. Wsparcie NIC i sterownika, to czy XDP działa w trybie native 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 przez kilka bezpiecznych migawek operatorskich.

Jak XDP wygląda w praktyce — migawki poleceń

Ta sekcja to migawka proof-of-concept. Celem jest sprawienie, aby XDP poczuł się realnie na Ubuntu 24.04 z odpowiednim zestawem poleceń: wystarczająco, aby załadować filtr, sprawdzić co zostało dołączone, dodać jedną regułę niskiego ryzyka i odczytać liczniki, które mają znaczenie.

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 potrzebne do uruchomienia demo.

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

Aby sprawdzić, czy program faktycznie się dołączył, 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 testowym hoście 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 generic XDP jest aktywny na tym interfejsie.

⚠️ Ostrzeżenie: Nie testuj polityk deny-default ani szerokich reguł odrzucania na żywym 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ź odkrywanie możliwości. Mówi ci to, co NIC i sterownik udostępniają w 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 wsparcie redirect, są użyteczne, ale nie są wymagane dla prostego proof of concept ochrony przed DDoS.

Następnie sprawdź, jak XDP loader 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ła, ale ważna kontrola operatorska. Potwierdza, że XDP to nie tylko koncepcja reguły żyjąca w user space — 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ą 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, gdzie 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 mieć widok na żywo, sudo xdp-filter poll -i 2000 jest rozsądnym 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 bezpiecznego demo sprawia, że idea staje się konkretna. Prawdziwa decyzja jednak nie polega na tym, 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 XDP warto rozważyć dla VPS i serwerów dedykowanych

XDP staje się interesujący, gdy publicznie dostępne obciążenie traci znaczący czas CPU na niepożądane pakiety, 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ć prawdziwy zapas zasobów serwera.

Istnieje też wiele przypadków, gdzie 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 tworzyć 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 staje się wart oceny, 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 wolumenem, zanim pakiety w ogóle dotrą do twojego serwera.

Użytkownicy VPS powinni pamiętać o jednym zastrzeżeniu: wirtualne ścieżki NIC i abstrakcja dostawcy mogą ograniczać oczekiwania dotyczące native mode, nawet gdy tryb skb działa dobrze w demo. Serwery dedykowane zazwyczaj dają ci większą kontrolę nad sterownikami, sprzętem i obserwowalnością, więc szanse na znaczące wsparcie native mode są tam lepsze — ale nawet na bare metal, XDP nadal jest jedną warstwą, a nie całą odpowiedzią. Jeśli oceniasz AlexHost lub jakiegokolwiek innego dostawcę, zadaj trzy oddzielne pytania zamiast łączyć je razem: jakie upstream DDoS handling istnieje, ile zapasu 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.

Zatem zasada kciuka jest 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łby follow-up na temat pisania niestandardowych programów XDP lub budowania bogatszej warstwowej obrony wokół tej samej idei wczesnego odrzucania.