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

Въведение в XDP и как може да помогне за изграждане на Anti-DDoS защита?

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

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

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

XDP ключови думи, от които се нуждаете за 2 минути

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реалните резултати зависят силно от средата. Поддръжката на NIC и драйвера, дали XDP работи в native или 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 избягва предположението за native 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 потвърждават, че generic XDP е активен на този интерфейс.

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

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

sudo xdp-loader features <ifname>

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

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

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

sudo xdp-loader status

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

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

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

sudo xdp-filter ip -s -m src 192.0.2.1

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

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

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

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

sudo xdp-filter status

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

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

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

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

Кога XDP си заслужава да се обмисли за VPS и dedicated сървъри

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

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

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

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

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

Заключение: XDP е слой за ранно отхвърляне, а не целият щит

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

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