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

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

Jeśli prowadzisz publiczny API, reverse proxy, usługę gier lub inne obciążenie skierowane do Internetu, możesz napotkać bolesny punkt, w którym serwer jest zajęty ruchem, który nigdy nie był przydatny. Aplikacja niekoniecznie zawodzi, ponieważ nie może obsługiwać rzeczywistych użytkowników. Zawodzi, ponieważ host spędza czas CPU na odbieraniu, parsowaniu, klasyfikowaniu i przesyłaniu pakietów śmieci głębiej w Linux, zanim cokolwiek powie „nie”. Wiele problemów związanych z DDoS zaczyna się tam: nie jako historia przepustowości, ale jako historia kosztów przetwarzania pakietów.

To ma znaczenie dla więcej niż tylko specjalistów jądra. Deweloperzy, osoby samodzielnie hostujące, operatorzy VPS i serwerów dedykowanych, a nawet czytelnicy biznesowi porównujący opcje odporności, 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 rzeczywistej pracy? Niektóre ataki przytłaczają samo łącze, ale wiele szkodliwych sytuacji pojawia się wcześniej jako presja pakietów na sekundę na hoście, zanim linia będzie w pełni nasycona.

To jest miejsce, gdzie XDP staje się warte zrozumienia. Nie zastępuje mitygacji upstream, zapory sieciowej ani kontroli świadomych aplikacji. To, co oferuje, to znacznie wcześniejszy punkt kontrolny w ścieżce pakietów Linux. Ten artykuł wyjaśnia, czym jest XDP, dlaczego ta „wcześniejsza” pozycja ma znaczenie dla pracy związanej z DDoS i gdzie się mieści w realistycznym stosie. Aby śledzić resztę, potrzebujesz tylko bardzo małego zestawu słownictwa na początek.

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

Kilka terminów związanych z XDP się nakłada, a na początku brzmią bardziej zastraszająco niż naprawdę są. To normalne. Celem tego słownika nie jest zamienianie artykułu w lekcję wewnętrznych mechanizmów Linux. To tylko tyle języka, ile potrzeba, aby reszta wyjaśnienia była jasna.

Jeśli zatrzymasz się na jednym skrócie myślowym z tej tabeli, niech to będzie ten: eBPF to mechanizm programowalny, a XDP to jedno konkretne miejsce, w którym ten mechanizm może działać. Mając to na miejscu, następny krok to prostsze i bardziej przydatne pytanie: co XDP naprawdę robi?

Co to jest naprawdę XDP

XDP to wczesny hook przetwarzania pakietów w Linuksie. Pozwala systemowi uruchomić mały program eBPF na pakiecie zaraz po jego przybyciu na interfejsie sieciowym. W tym momencie Linux może podjąć szybką decyzję: pozwolić pakietowi na dalszą drogę (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ć „pozwól mu przejść” lub „zatrzymaj go 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 na eBPF. To jedno narzędzie oparte na eBPF z bardzo specyficzną rolą.

Ta rola to właśnie to, co czyni XDP użytecznym w pracy przeciwko 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 firewall, śledzenie połączeń, sockety i ostatecznie samą aplikację. Dlatego właściwa zaleta XDP to nie tylko filtrowanie — to filtrowanie wcześniej.

Dodatkowo, XDP jest przydatny do czegoś więcej niż tylko obrona przed DDoS. Może również wspierać kierowanie ruchu i inne zadania związane z obsługą pakietów. Ale obrona przed DDoS to najłatwiejsze miejsce, aby zobaczyć 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 aby zrozumieć, dlaczego to ma takie znaczenie, następnym krokiem jest przyjrzenie się dokładnie, gdzie XDP znajduje się w ścieżce odbierania pakietów.

Model mentalny: XDP to brama, nie recepcja

Najłatwiej wyobrazić sobie XDP jako ochroniarza na bramie, a nie recepcjonistkę głębiej w budynku. Jeśli wyraźnie niechciany gość zostanie odprawiony na 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 czekasz z odrzuceniem go aż do recepcji, budynek już poświęcił czas i uwagę złej osobie.

Obsługa pakietów w Linuksie działa w ten sam sposób. W uproszczonej ścieżce odbierania pakiet przychodzi z karty sieciowej i sterownika, dociera do XDP, a dopiero wtedy kontynuuje się w bogatszym stosie sieciowym jądra, który zasilają conntrack, firewall, gniazda i ostatecznie aplikacja. 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 zwyczajną strukturę sk_buff — bogatszy obiekt pakietu jądra, którego oczekuje reszta stosu. Ten szczegół brzmi mało, ale jest sercem historii wydajności. Jeśli pakiet jest wyraźnie niechciany, jego porzucenie zanim Linux zbuduje tę normalną strukturę oznacza mniej pracy CPU, mniej zmian w pamięci i mniej presji na dalsze etapy. XDP_PASS istnieje, ponieważ nie każdy pakiet jest zły; to akcja „kontynuuj”, która pozwala legalnym ruchom się poruszać. XDP_DROP jest gwiazdą anti-DDoS, ponieważ kończy podróż zanim zacznie się droga część. Istnieją też inne akcje, takie jak REDIRECT, ale nie są one kluczowe dla tego wyjaśnienia.

Gdy umiejscowienie jest jasne, wartość anti-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 do ochrony przed DDoS jest prosty: to tani sposób na odrzucenie oczywistych śmieci zanim Linux wydatkuje zasoby na conntrack, obsługę gniazd i dostarczanie do przestrzeni użytkownika. Jeśli host jest bombardowany ruchem o wysokiej szybkości, który nigdy nie powinien dotrzeć do aplikacji, każdy pakiet odrzucony wcześnie to praca, którą serwer nie będzie musiał wykonać 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 obciążenia.

To ma największe znaczenie podczas zalewów śmieci, gdzie bolesna część to nie surowa ilość danych, ale powtarzana obsługa pakietów. Reverse proxy, usługa oparta na UDP lub publiczny API mogą stać się powolne na długo przed całkowitym 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ż chroni nasycone łącze upstream. Jeśli łącze skierowane do dostawcy jest już pełne, wczesne odrzucenie na poziomie hosta jest zbyt późne, aby naprawić ścieżkę sieciową samodzielnie.

To rozróżnienie jest głównym powodem, dla którego XDP należy do projektu warstwowego, a nie na piedestale. Poniższa tabela to praktyczna wersja 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 tym, dlaczego 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, już opisujesz problemy, które należą głębiej niż to narzędzie demonstracyjne.

Operatorzy produkcyjni rzeczywiście używają odrzucania w stylu XDP, ponieważ wczesne odrzucenie zmniejsza pracę downstream. Historia L4Drop Cloudflare’a to dobrze znany przykład tego, dlaczego ten model stał się atrakcyjny w rzeczywistych operacjach. Ale ważna lekcja to nie tylko liczba pakietów na sekundę w nagłówku. To logika projektowania: odrzuć zły ruch wcześniej, aby reszta maszyny mogła dłużej obsługiwać rzeczywisty ruch.

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

Jak wygląda XDP w praktyce — Migawki poleceń

Ta sekcja to migawka proof-of-concept. Celem jest uczynienie XDP rzeczywistym na Ubuntu 24.04 z odpowiednim zestawem poleceń: wystarczającym do załadowania filtru, sprawdzenia co jest dołączone, dodania jednej bezpiecznej reguły i odczytania liczników, które mają znaczenie.

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

ip -br link

Zainstaluj wymagane wstępnie.

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, co jest potrzebne do uruchomienia demonstracji.

Trzecie polecenie ładuje xdp-filter w trybie skb z domyślną polityką allow. Na hoście Ubuntu użytym do tego artykułu, to dało wariant xdpfilt_alw_all z pełnym zestawem funkcji tcp,udp,ipv6,ipv4,ethernet,allow. Wybór -m skb unika założenia natywnego wsparcia XDP w twojej karcie sieciowej lub sterowniku, co czyni to bezpieczniejszą ścieżką dla pierwszego proof of concept.

Aby zweryfikować, że program rzeczywiście się dołączył, uruchom:

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

W xdp-filter status chcesz zobaczyć twó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 generyczne XDP jest aktywne na tym interfejsie.

⚠️ Ostrzeżenie: Nie testuj polityk deny-default ani szerokich reguł drop na aktywnym zdalnym interfejsie, który przenosi twoją sesję SSH, chyba że masz dostęp do konsoli odzyskiwania. Ten artykuł pozostaje z polityką allow i jedną regułą adresu dokumentacji dokładnie z tego powodu.

Następnie sprawdź odkrycie możliwości. To mówi ci, co karta sieciowa i sterownik ujawniają w powierzchni XDP, a nie jaka będzie twoja ostateczna wydajność.

sudo xdp-loader features <ifname>

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

Najważniejsze tutaj to NETDEV_XDP_ACT_BASIC, ponieważ to mówi ci, że ścieżka ujawnia podstawowy model akcji XDP. Dodatkowe flagi, takie jak wsparcie redirect, są przydatne, ale nie są wymagane dla prostego proof of concept anti-DDoS.

Następnie zweryfikuj, jak loader XDP zarządza programem i w jakim trybie się uruchamia.

sudo xdp-loader status

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

To mała, ale ważna kontrola operatora. Potwierdza, że XDP to nie tylko koncepcja reguły żyjąca w przestrzeni użytkownika — na interfejsie załadowany jest 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 wypisuje wynikowy stan reguły zamiast zostawiać 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 ustawia politykę allow. Innymi słowy, pakiety pasujące do reguły są odrzucane, a pakiety, które nie pasują do reguły, przechodzą przez normalną ścieżkę.

Ten przykład jest celowo nudny. W kategoriach anti-DDoS, pokazuje również najprostszą możliwą wersję wczesnej reguły drop: ruch ze źródła, którego nie chcesz, może być odrzucony zanim reszta hosta zainwestuje w niego wiele pracy.

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

sudo xdp-filter status

Na typowym systemie, wzór 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, to głównie bucket błędu/debugowania, a nie akcja, którą planujesz. Co ważniejsze, jeśli licznik drop pozostaje na 0, to nie oznacza, że filtr się nie powiódł. Oznacza to tylko, że żaden pasujący pakiet nie trafił w regułę podczas okna przechwytywania.

💡 Wnioski: Traktuj xdp-filter jako proste, bezstanowe narzędzie proof-of-concept, a nie zamiennik dla nftables. Pamiętaj również, że pakiety odrzucone na warstwie XDP mogą nigdy nie pojawić się w zwykłej ścieżce tcpdump, co czyni natywny output XDP i liczniki bardziej niezawodną metodą walidacji. Jeśli chcesz widok na żywo później, sudo xdp-filter poll -i 2000 to rozsądny opcjonalny następny krok — ale tylko gdy interfejs już ma wystarczająco interesujący ruch, aby uczynić ten output użytecznym.

Zobaczenie bezpiecznej demonstracji czyni ideę konkretną. Rzeczywista decyzja jednak nie polega na tym, czy polecenia się uruchamiają. 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 niechcianych pakietach, zanim aplikacja może odpowiedzieć normalnie. Dobrymi kandydatami są publiczne API, reverse proxy, bramy, usługi UDP dostępne w internecie i hosty, które regularnie widzą wystarczającą ilość śmieci w ruchu, aby obciążyć ścieżkę sieciową, nawet gdy sama aplikacja nie jest wąskim gardłem. W takich środowiskach wcześniejsze odrzucenie może przywrócić rzeczywistą wydajność serwera.

Istnieje jednak wiele przypadków, w których wystarczy prostsze filtrowanie. Strona internetowa o niskim ruchu, narzędzie wewnętrzne, box stagingowy lub usługa, której rzeczywistym wymaganiem jest stanowe firewalling hosta, a nie zmniejszenie tempa pakietów, zwykle nie potrzebuje XDP na pierwszym miejscu. Jeśli nftables już pokrywa ryzyko bez zauważalnego obciążenia ścieżki pakietów, dodanie kolejnej warstwy może stworzyć więcej ruchomych części niż wartości.

Jako szybka rama decyzyjna:

• Firewalling zwykle wystarczy, gdy ruch jest lekki, polityka wymaga stanu lub bogatszej logiki usługi, a host nie wyraźnie nie pali CPU na śmieci w pakietach.
• XDP warto oceniać, gdy niechciany ruch dociera do hosta wystarczająco często, że wczesne odrzucenie mogłoby chronić CPU, conntrack i pojemność gniazd.
• Łagodzenie upstream pozostaje obowiązkowe, gdy rzeczywisty tryb awarii to nasycenie łącza dostawcy lub większe powodzie objętościowe, zanim pakiety w ogóle dotrą do twojego serwera.

Użytkownicy VPS powinni pamiętać o jednym zastrzeżeniu: ścieżki wirtualnych NIC i abstrakcja dostawcy mogą ograniczyć oczekiwania trybu natywnego, nawet gdy tryb skb działa dobrze na demo. Serwery dedykowane zwykle dają ci więcej kontroli nad sterownikami, sprzętem i obserwowalnością, więc szanse na znaczące wsparcie trybu natywnego są tam lepsze — ale nawet na bare metal, XDP to wciąż jedna warstwa, nie całą odpowiedź. Jeśli oceniasz AlexHost lub jakiegokolwiek innego dostawcę, zamiast łączyć je razem, zadaj trzy osobne pytania: jakie istnieje upstream DDoS handling, ile wydajności hosta daje plan, i jakie kontrole na poziomie hosta są realistyczne na tej platformie?

Podsumowanie: XDP to wczesna warstwa filtrowania, nie kompletna ochrona

Najprostszy sposób myślenia o XDP to taki: daje Linuksowi szybki pierwszy punkt kontroli dla oczywistego złego ruchu i zalew pakietów, co oznacza, że lepiej chroni zasoby serwera niż chroni nasycone łącze upstream. Dlatego XDP ma znaczenie w rozmowach o ochronie przed DDoS. Nie zastępuje mitygacji upstream, firewallingu stanowego ani kontroli świadomych aplikacji. Pomaga poprzez zmniejszenie niepotrzebnej pracy hosta.

Reguła praktyczna jest więc prosta. Jeśli niechciany ruch marnuje CPU hosta zanim rzeczywiste obciążenia mogą odpowiedzieć, XDP warto ocenić jako wczesną warstwę filtrowania. Jeśli głównym problemem jest pełne łącze lub polityka zależna od stanu i logiki aplikacji, XDP powinno znajdować się za mitygacją upstream i głębszym filtrowaniem, a nie przed nimi jako kompletne rozwiązanie. Naturalnym następnym krokiem byłby artykuł uzupełniający na temat pisania niestandardowych programów XDP lub budowania bogatszej warstwowej ochrony wokół tej samej idei wczesnego filtrowania.