Що таке XDP і як він може допомогти у побудові захисту від DDoS-атак?

Вступ до XDP та як він може допомогти побудувати захист від DDoS?

Якщо ви запускаєте публічний API, зворотний проксі, ігровий сервіс або будь-яке інше навантаження, доступне з інтернету, ви можете зіткнутися з болючою ситуацією, коли сервер зайнятий трафіком, який спочатку не мав жодної корисності. Застосунок не обов’язково виходить з ладу через те, що не може обслуговувати реальних користувачів. Він виходить з ладу тому, що хост витрачає час CPU на отримання, розбір, класифікацію та просування сміттєвих пакетів глибше в Linux, перш ніж щось скаже «ні». Багато проблем із захистом від DDoS починаються саме там: не як проблема пропускної здатності, а як проблема вартості обробки пакетів.

Це важливо не лише для фахівців із ядра. Розробники, самостійні хостери, оператори VPS і виділених серверів, а також бізнес-читачі, які порівнюють варіанти стійкості, стикаються з одним і тим самим базовим питанням: наскільки рано можна відхилити поганий трафік, перш ніж він витратить час і ресурси, які мають належати реальній роботі? Деякі атаки перевантажують сам канал зв’язку, але багато шкідливих ситуацій виникають раніше — як тиск пакетів на секунду на хост задовго до повного насичення лінії.

Саме тут XDP стає вартим розуміння. Він не замінює upstream-мітигацію, брандмауер або контроль на рівні застосунку. Що він пропонує — це значно ранішу контрольну точку в шляху пакетів Linux. Ця стаття пояснює, що таке XDP, чому ця «рання» позиція важлива для захисту від 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 корисним для захисту від DDoS. XDP виконується до того, як пакети проходять через звичайні, більш важкі частини мережевого шляху Linux. Таким чином, Linux може прийняти рішення щодо певного трафіку до того, як витратить більше зусиль на брандмауер, відстеження з’єднань, сокети та врешті-решт сам застосунок. Ось чому реальна перевага XDP — це не лише фільтрація, а фільтрація раніше.

Крім того, XDP корисний не лише для захисту від DDoS. Він також може підтримувати керування трафіком та інші завдання обробки пакетів. Але захист від DDoS — найлегше місце, де можна побачити його цінність, оскільки перевага зводиться до однієї практичної ідеї: чим раніше відхиляється поганий трафік, тим менше марної роботи доводиться виконувати серверу. А щоб зрозуміти, чому це так важливо, наступний крок — розглянути, де саме XDP знаходиться в шляху отримання пакетів.

Ментальна модель: XDP — це ворота, а не стійка реєстрації

Найпростіший спосіб уявити XDP — це охоронець на воротах, а не адміністратор глибше всередині будівлі. Якщо явно небажаного відвідувача розвертають на воротах, будівля уникає довгого ланцюжка безглуздої роботи. Ніхто не відчиняє внутрішні двері, не реєструє його в системі та не проводить коридором. Якщо чекати до стійки реєстрації, щоб відмовити, будівля вже витратила час і увагу на не ту людину.

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

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

У native mode XDP може діяти до того, як Linux виділить і заповнить звичайну структуру sk_buff — більш насичений об’єкт пакету ядра, якого очікує решта стеку. Ця деталь звучить незначно, але вона є серцем історії про продуктивність. Якщо пакет явно небажаний, його скидання до того, як Linux побудує цю звичайну структуру, означає менше роботи CPU, менше навантаження на пам’ять і менший тиск на подальші етапи. XDP_PASS існує тому, що не кожен пакет є поганим; це дія «продовжуй», яка дозволяє легітимному трафіку рухатися далі. XDP_DROP — зірка захисту від DDoS, оскільки він завершує подорож до початку дорогої частини. Інші дії, такі як REDIRECT, також існують, але вони не є ключовими для цього пояснення.

Коли розміщення стає зрозумілим, цінність для захисту від DDoS — і обмеження — стають набагато легшими для реалістичної оцінки.

Як XDP допомагає захисту від DDoS — і де починаються його обмеження

Аргумент на користь XDP для захисту від DDoS простий: це дешевий спосіб відхилити очевидне сміття до того, як Linux витратить ресурси на conntrack, обробку сокетів і доставку до простору користувача. Якщо хост зазнає бомбардування високошвидкісним трафіком, який ніколи не повинен досягати застосунку, кожен рано скинутий пакет — це робота, яку серверу більше не потрібно виконувати пізніше. Ось чому XDP найсильніший на межі L3/L4 проблеми: вихідні адреси, яким ви вже не довіряєте, протоколи, які вам не потрібні, або шаблони трафіку, які явно не є легітимними для навантаження.

Це найбільш важливо під час сміттєвих флудів, де болюча частина — не сирий обсяг даних, а повторна обробка пакетів. Зворотний проксі, UDP-важкий сервіс або публічний API можуть стати повільними задовго до повного насичення каналу, якщо хост зайнятий класифікацією нісенітниці. XDP дає вам спосіб відсікти частину цих витрат близько до входу.

📝 Примітка: XDP краще захищає ресурси хоста, ніж насичений upstream-канал. Якщо канал до провайдера вже повний, раннє скидання на рівні хоста запізнюється для самостійного виправлення мережевого шляху.

Ця відмінність є головною причиною, чому XDP належить до багаторівневого дизайну, а не на п’єдестал. Наступна таблиця — практична версія порівняння XDP vs nftables vs upstream/provider mitigation:

Іншими словами, 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 активний на цьому інтерфейсі.

⚠️ Попередження: Не тестуйте політики deny-default або широкі правила скидання на живому віддаленому інтерфейсі, який несе ваш 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 як простий, stateless інструмент підтвердження концепції, а не як заміну nftables. Також майте на увазі, що пакети, скинуті на рівні XDP, можуть ніколи не з’явитися у звичайному шляху tcpdump, що робить власний вивід статусу XDP та лічильники більш надійним методом перевірки. Якщо ви хочете живий перегляд пізніше, sudo xdp-filter poll -i 2000 є розумним необов’язковим наступним кроком — але лише тоді, коли інтерфейс вже має достатньо цікавого трафіку, щоб зробити цей вивід корисним.

Перегляд безпечної демонстрації робить ідею конкретною. Реальне рішення, однак, полягає не в тому, чи виконуються команди. Воно в тому, чи вартий цей додатковий рівень операційної складності на тому типі інфраструктури, яким ви фактично керуєте.

Коли XDP варто розглядати для VPS та виділених серверів

XDP стає цікавим, коли публічне навантаження втрачає значний час CPU на небажані пакети до того, як застосунок може відповідати нормально. Хорошими кандидатами є публічні API, зворотні проксі, шлюзи, UDP-важкі сервіси, доступні з інтернету, та хости, які регулярно бачать достатньо сміттєвого трафіку, щоб навантажити мережевий шлях, навіть коли сам застосунок не є вузьким місцем. У таких середовищах більш раннє відхилення може повернути реальний резерв сервера.

Є також багато випадків, коли простішої фільтрації достатньо. Веб-сайт із низьким трафіком, внутрішній інструмент, тестовий сервер або сервіс, реальна вимога якого — stateful-брандмауер хоста, а не полегшення тиску пакетів, зазвичай не потребує XDP в першу чергу. Якщо nftables вже покриває ризик без помітного тиску на шлях пакетів, додавання ще одного рівня може створити більше рухомих частин, ніж цінності.

Як швидка система прийняття рішень:

• Брандмауера зазвичай достатньо, коли трафік невеликий, політика потребує стану або більш насиченої логіки сервісу, і хост явно не спалює CPU на сміттєвих пакетах.
• XDP варто оцінювати, коли небажаний трафік досягає хоста достатньо часто, щоб раннє скидання могло захистити CPU, conntrack та ємність сокетів.
• Upstream-мітигація залишається обов’язковою, коли реальний режим відмови — насичення каналу провайдера або більші об’ємні флуди до того, як пакети навіть досягнуть вашого сервера.

Користувачі VPS повинні мати на увазі одне застереження: шляхи віртуальних NIC та абстракція провайдера можуть обмежити очікування native-режиму, навіть коли режим skb добре працює для демонстрації. Виділені сервери зазвичай дають вам більше контролю над драйверами, апаратним забезпеченням та спостережуваністю, тому шанси на значущу підтримку native-режиму там кращі — але навіть на bare metal XDP все ще є одним рівнем, а не повною відповіддю. Якщо ви оцінюєте AlexHost або будь-якого іншого провайдера, задайте три окремих питання замість того, щоб об’єднувати їх: яка upstream-обробка DDoS існує, скільки резерву хоста дає план, і які засоби контролю на рівні хоста є реалістичними на цій платформі?

Висновок: XDP — це рівень раннього скидання, а не весь щит

Найчистіший спосіб думати про XDP такий: він дає Linux швидку першу контрольну точку для очевидного поганого трафіку та пакетних флудів, що означає, що він краще захищає ресурси сервера, ніж насичений upstream-канал. Ось чому XDP важливий у розмовах про захист від DDoS. Він не замінює upstream-мітигацію, stateful-брандмауер або засоби контролю на рівні застосунку. Він допомагає, змушуючи хост виконувати менше безглуздої роботи.

Тому практичне правило просте. Якщо небажаний трафік марно витрачає CPU хоста до того, як реальні навантаження можуть відповідати, XDP варто оцінити як рівень раннього скидання. Якщо основна проблема — повний канал або політика, що залежить від стану та логіки застосунку, XDP належить за upstream-мітигацією та більш глибокою фільтрацією, а не перед ними як повна відповідь. Природним наступним кроком звідси може бути продовження про написання власних програм XDP або побудову більш насиченого багаторівневого захисту навколо тієї ж ідеї раннього скидання.