Какво е XDP и как може да помогне при изграждането на защита срещу DDoS?

XDP Introduction, and How Can It Help Build Anti-DDoS Protection?

Ако управлявате публичен API, обратен прокси, игрова услуга или всяко друго интернет-ориентирано натоварване, можете да попаднете в болезнена точка, където сървърът е зает с трафик, който никога не е бил полезен. Приложението не е задължително да се отказва, защото не може да обработи реални потребители. То се отказва, защото хостът прекарва CPU време в получаване, анализиране, класифициране и пренасяне на боклук пакети по-дълбоко в Linux, преди нещо да каже “не”. Много проблеми с анти-DDoS защитата започват там: не като история за честотна лента, а като история за разходите на обработката на пакети.

Това е важно за повече от специалистите по ядро. Разработчици, самостоятелни хостери, VPS и оператори на дедицирани сървъри, и дори бизнес читатели, които сравняват опции за устойчивост, всички попадат в един и същ основен въпрос: колко рано могат лошите трафик да бъдат отхвърлени, преди да изгорят време и ресурси, които трябва да принадлежат на реалната работа? Някои атаки разрушават самия uplink, но много вредни ситуации се появяват по-рано като налягане на пакети в секунда на хоста, много преди линията да бъде напълно насищена.

Там XDP става достойна за разбиране. Тя не замества upstream смекчаване, firewall или контроли, осведомени за приложението. Това, което предлага, е много по-ранна контролна точка в пътя на пакетите на Linux. Тази статия обяснява какво е XDP, защо тази “по-ранна” позиция е важна за работата на анти-DDoS защитата, и където тя се вписва в реалистичен стек. За да следите останалото, имате нужда само от много малък набор от речник първо.

XDP ключови думи, които трябва да знаете за 2 минути

Няколко от термините около XDP се припокриват и на първо място звучат по-плашещо, отколкото наистина са. Това е нормално. Целта на този речник не е да превърне статията в урок по Linux вътрешности. Това е просто достатъчно език, за да помогне останалото обяснение да бъде ясно.

Ако запазите само един мисловен преход от тази таблица, нека е този: eBPF е програмируемият механизъм, а XDP е едно конкретно място, където този механизъм може да работи. С това на място, следващата стъпка е по-проста и по-полезна въпрос: какво всъщност прави XDP?

Какво всъщност е XDP

XDP е ранен hook за обработка на пакети в Linux. Позволява на системата да изпълни малка eBPF програма на пакет веднага след като този пакет пристигне на мрежов интерфейс. В този момент Linux може да вземе бързо решение: позволи на пакета да продължи (XDP_PASS), отхвърли го веднага (XDP_DROP), или го обработи по друг определен начин. За тази статия важната част е проста: XDP може да каже “пропусни го” или “спри го тук” много рано.

Linux използва eBPF в няколко контекста, не само за мрежи. XDP е версията, фокусирана върху мрежи, изградена за много ранна обработка на входящи пакети. Така че XDP не е друго име за eBPF. Това е един eBPF-базиран инструмент с много специфична роля.

Тази роля е това, което прави XDP полезен за анти-DDoS работа. XDP работи преди пакетите да преминат през нормалните, по-тежки части на пътя на мрежата на Linux. По този начин Linux може да вземе решение за някакъв трафик преди да похарчи повече усилия на firewall, проследяване на връзки, сокети и в крайна сметка самото приложение. Ето защо реалното предимство на XDP е не само филтриране — то е филтриране по-рано.

Освен това XDP е полезен за повече от анти-DDoS. Може също да поддържа управление на трафик и други задачи за обработка на пакети. Но анти-DDoS е най-лесното място, където да се види неговата стойност, защото преимуществото се свежда до една практическа идея: колкото по-рано е отхвърлен лошия трафик, толкова по-малко безполезна работа трябва да направи сървърът. И за да разберем защо това е толкова важно, следващата стъпка е да разгледаме точно къде XDP се намира в пътя на получаване на пакети.

Менталният модел: XDP е портата, не рецепцията

Най-лесният начин да си представите XDP е като охранител на портата, не като рецепционист по-дълбоко в сградата. Ако очевидно нежелан посетител бъде отхвърлен на портата, сградата избягва дълга верига от безполезна работа. Никой не отваря вътрешната врата, не го регистрира в система, нито го води през коридора. Ако чакате до рецепцията да го отхвърлите, сградата вече е похарчила време и внимание на грешния човек.

Обработката на пакети в Linux работи по същия начин. В опростена пътека на приемане пакетът пристига от NIC и драйвера, достига XDP, и само тогава продължава в по-богатия kernel networking stack, който хранва conntrack, firewalling, sockets и накрая приложението. Визуално пътеката изглежда така:

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

В native режим XDP може да действа преди Linux да разпредели и попълни обичайната структура sk_buff — по-богатия kernel packet обект, който останалата част на stack очаква. Този детайл звучи малък, но е сърцето на историята за производителност. Ако пакетът е очевидно нежелан, отхвърлянето му преди Linux да построи тази нормална структура означава по-малко CPU работа, по-малко memory churn и по-малко downstream натиск. XDP_PASS съществува, защото не всеки пакет е лош; това е действието “продължи напред”, което позволява на легитимния трафик да продължи. XDP_DROP е звездата против DDoS, защото завършва пътеката преди скъпата част да започне. Други действия като REDIRECT също съществуват, но те не са критични за това обяснение.

Когато разположението е ясно, стойността против DDoS — и ограниченията — стават много по-лесни за реалистична преценка.

Как XDP помага при защита от DDoS — и където начват неговите ограничения

Случаят за XDP при защита от DDoS е ясен: това е евтин начин да отхвърлите очевидния боклук преди Linux да похарчи ресурси на conntrack, обработка на сокети и доставка в потребителското пространство. Ако хост е бомбардиран с висок трафик, който никога не трябва да достигне приложението, всеки пакет отхвърлен рано е работа, която сървърът вече не трябва да прави по-късно. Затова XDP е най-силен на L3/L4 ръба на проблема: адреси на източници, които вече не доверявате, протоколи, които не искате, или трафик модели, които явно не са легитимни за работното натоварване.

Това е най-важно при наводнения със боклук, където болезненият момент не е сурово количество данни, а повторена обработка на пакети. Обратен прокси, UDP-тежка услуга или публичен API могат да станат бавни много преди връзката да е напълно насичена, ако хостът е зает с класифициране на глупости. XDP ви дава начин да отрежете част от това разхищение близо до вратата.

📝 Забележка: XDP защитава ресурсите на хоста по-добре, отколкото защитава насичена възходяща връзка. Ако връзката към доставчика вече е пълна, отхвърляне на ранна фаза на ниво хост е твърде късно, за да поправи мрежовия път сам по себе си.

Това разграничение е основната причина XDP да принадлежи на многослойна архитектура, а не на пиедестал. Следната таблица е практичната версия на XDP срещу nftables срещу upstream/provider mitigation:

С други думи, XDP и nftables не са враги. Те решават различни части на пътя. nftables е по-богат и държавен. xdp-filter — демонстрационният инструмент, използван в тази статия — е намерено прост и без състояние, което е точно защо е полезен за показване на XDP модела без да се преструва, че замества пълен firewall. Ако имате нужда от проследяване на връзки, многослойни списъци за разрешаване, обработка на състояние на отговор или правила, осведомени за приложението, вече описвате проблеми, които принадлежат по-дълбоко от тази демонстрационна утилита.

Операторите в производство използват XDP-стилно отхвърляне, защото ранното отхвърляне намалява последващата работа. Историята на Cloudflare L4Drop е добре известен пример за това защо този модел стана привлекателен в реални операции. Но важният урок не е само числото на пакетите в секунда. Това е логиката на проектирането: отхвърлете лошия трафик по-рано, така че останалата машина да може да продължи да обслужва реален трафик по-дълго.

Резултатите в реалния свят зависят силно от средата. Поддържката на NIC и драйвер, дали XDP работи в нативен или skb режим, и формата на входящия трафик всички влияят на това колко полза всъщност получавате. Затова числата на пакетите в секунда от доставчици или хипермащабни оператори се третират най-добре като доказателство, че моделът на ранна отпадане работи, а не като числа, които всеки VPS трябва да очаква. Имайки това предвид, следващият раздел показва как изглежда XDP на реален Ubuntu хост чрез няколко безопасни снимки на оператора.

Как изглежда XDP на практика — Снимки на команди

Този раздел е снимка на доказателство на концепция. Целта е да направи XDP реален на Ubuntu 24.04 със съответния набор от команди: достатъчно, за да заредите филтър, да проверите какво е прикачено, да добавите едно правило с нисък риск и да прочетете важните броячи.

Преди да продължите със настройката на XDP, трябва първо да откриете и изберете името на интерфейса.

ip -br link

Инсталирайте предварителните условия.

sudo apt update
sudo apt install -y xdp-tools

В командата по-долу замените <ifname> с действителното име на вашия мрежов интерфейс, като eth0 или ens3.

sudo xdp-filter load -m skb <ifname>

Първите две команди са отговорни за инсталирането на необходимите инструменти, като гарантират, че средата има всичко необходимо за стартиране на демото.

Третата команда след това зарежда xdp-filter в режим skb със стандартната политика allow. На хоста на Ubuntu, използван за тази статия, това произведе варианта xdpfilt_alw_all с пълния набор от функции tcp,udp,ipv6,ipv4,ethernet,allow. Избирането на -m skb избягва предположението за поддръжка на собствен XDP във вашия NIC или драйвер, което го прави по-безопасния път за първо доказателство на концепция.

За да проверите, че програмата действително е прикачена, стартирайте:

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

В xdp-filter status искате да видите вашия интерфейс в списъка с режим skb mode; на тестовия хост тук активният набор от функции показа tcp,udp,ipv6,ipv4,ethernet,allow. В ip -details link show прикачването на xdpgeneric и програмата xdp_dispatcher потвърждават, че генеричният XDP е активен на този интерфейс.

⚠️ Внимание: Не тествайте политики по подразбиране на отказ или широки правила за отпадане на живия отдалечен интерфейс, който носи вашата SSH сесия, освен ако нямате възстановяване на конзола. Тази статия остава със политика allow и едно правило за адрес на документация точно по тази причина.

След това проверете откритието на възможностите. Това ви казва какво разкриват NIC и драйверът в XDP повърхността, а не каква ще бъде вашата крайна производителност.

sudo xdp-loader features <ifname>

Точният резултат варира в зависимост от хардуера, но представителен резултат често съдържа редове като тези:

Най-важното тук е NETDEV_XDP_ACT_BASIC, защото това ви казва, че пътят разкрива основния модел на действие на XDP. Допълнителни флагове като поддръжка на пренасочване са полезни, но не са необходими за просто доказателство на концепция против DDoS.

След това проверете как XDP зарядчикът управлява програмата и в какъв режим работи.

sudo xdp-loader status

На работеща система изглед на статуса може да изглежда така:

Това е малка, но важна проверка на оператора. Потвърждава, че XDP не е просто концепция за правило, живееща в потребителското пространство — има заредена програма на интерфейса и колоната на режима ви казва дали разглеждате native или skb.

Сега добавете едно безопасно примерно правило, използвайки адрес на документация IP. Флагът -s е полезен, защото отпечатва получаващото се състояние на правилото веднага, вместо да ви остави с мълчаливия успех.

sudo xdp-filter ip -s -m src 192.0.2.1

Представителен отговор може да изглежда така:

📝 Забележка: xdp-filter по подразбиране използва политика allow. С други думи, пакетите, които съответстват на правилото, се отпадат, а пакетите, които не съответстват на правилото, продължават през нормалния път.

Този пример е намерено скучен. В термини против DDoS той също показва най-простата възможна версия на правило за ранно отпадане: трафикът от източник, който не искате, може да бъде отхвърлен, преди останалата част на хоста да инвестира много работа в него.

Накрая проверете общото състояние на едно място.

sudo xdp-filter status

На типична система моделът на резултата е най-информативният.

Този изглед на статуса е където доказателството на концепция става оперативно полезно. Можете да видите заредения интерфейс, активния режим, активния вариант на xdp-filter, ефективния набор от функции и състоянието на брояча на правилото в една команда. XDP_ABORTED, ако се появи, е главно кофа за грешки/отладка, а не действието, което планирате. По-важното е, че ако броячът на отпадане остане на 0, това не означава, че филтърът е неуспешен. Това означава само, че нито един съответстващ пакет не е попаднал на правилото по време на прозореца на улавяне.

💡 Извод: Третирайте xdp-filter като прост, без състояние инструмент за доказателство на концепция, а не като замяна на nftables. Също имайте предвид, че пакетите, отпаднали на слоя XDP, може никога да не се появят в обичайния път на tcpdump, което прави резултата на XDP-родния статус и броячите по-надежден метод на валидиране. Ако искате живо изглед по-късно, sudo xdp-filter poll -i 2000 е разумна опционална следваща стъпка — но само когато интерфейсът вече има достатъчно интересен трафик, за да направи този резултат полезен.

Виждането на безопасно демо прави идеята конкретна. Реалното решение обаче не е дали командите работят. Това е дали този допълнителен слой си струва оперативната сложност на вида инфраструктура, която действително управлявате.

Кога XDP е достойно да се разгледа за VPS и Dedicated Servers

XDP става интересен, когато публично достъпна работна натовареност губи значително CPU време на нежелани пакети, преди приложението да може да отговори нормално. Добрите кандидати включват публични API, обратни прокси, шлюзове, интернет-експозирани UDP-тежки услуги и хостове, които редовно виждат достатъчно боклив трафик, за да натоварят мрежовия път, дори когато самото приложение не е тясното място. В тези среди по-ранното отхвърляне може да върне реално място на сървъра.

Има също много случаи, когато по-простото филтриране е достатъчно. Уебсайт с нисък трафик, вътрешен инструмент, staging box или услуга, чието реално изискване е stateful host firewalling, а не облекчение на пакетния процент, обикновено не се нуждаят от XDP първо. Ако nftables вече покрива риска без забележимо налягане на пакетния път, добавянето на още един слой може да създаде повече движещи се части, отколкото стойност.

Като бърза рамка за вземане на решение:

• Firewalling обикновено е достатъчен, когато трафикът е лек, политиката се нуждае от state или по-богата логика на услугата, и хостът не гори видимо CPU на боклив пакети.
• XDP става достойно да се оцени, когато нежеланият трафик достига хоста достатъчно често, че ранното отхвърляне може да защити CPU, conntrack и socket капацитета.
• Upstream митигирането остава задължително, когато реалният режим на отказ е насищане на provider-link или по-голямо обемно наводнение, преди пакетите дори да достигнат вашия сървър.

VPS потребителите трябва да имат предвид един предупредител: виртуални NIC пътища и provider абстракция могат да ограничат очакванията на native-mode, дори когато skb mode работи добре за демонстрация. Dedicated servers обикновено ви дават повече контрол над драйверите, хардуера и наблюдаемостта, така че шансовете за значима native-mode поддръжка са по-добри там — но дори на bare metal, XDP все още е един слой, не целия отговор. Ако оценявате AlexHost или всеки друг provider, задайте три отделни въпроса вместо да ги събирате заедно: какво upstream DDoS обработване съществува, колко host headroom дава плана вам, и какви host-level контроли са реалистични на тази платформа?

Заключение: XDP е ранна отпадаща слой, не целия щит

Най-чистият начин да мислим за XDP е следният: той дава на Linux бърза първа контролна точка за очевидно лош трафик и наводнения с пакети, което означава, че защитава ресурсите на сървъра по-добре, отколкото защитава насищена възходяща връзка. Ето защо XDP е важен в разговорите за противодействие на DDoS. Той не замества възходящото смекчаване, stateful firewalling или контроли, осведомени за приложенията. Той помага, като прави хостът да върши по-малко безполезна работа.

Така че правилото е просто. Ако нежеланият трафик разхищва CPU на хоста, преди реалните работни натоварвания да могат да отговорят, XDP си струва да се оцени като ранна отпадаща слой. Ако основният проблем е пълна възходяща връзка или политика, която зависи от състояние и логика на приложението, XDP трябва да бъде зад възходящото смекчаване и по-дълбокото филтриране, а не пред тях като пълен отговор. Естествен следващ етап от тук би бил последващ материал за писане на персонализирани XDP програми или изграждане на по-богата многослойна защита около същата идея за ранна отпадаща слой.