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

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

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

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

Саме тут XDP стає варто розуміти. Він не замінює вищестоящу мітигацію, брандмауер або елементи управління, що розуміють додаток. Те, що він пропонує, — це набагато раніша контрольна точка в шляху пакетів 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, firewalling, сокети та, нарешті, додаток. Візуально шлях виглядає так:

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

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

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

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

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

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

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

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

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

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

Результати в реальному світі сильно залежать від середовища. Підтримка NIC та драйвера, чи XDP працює в native або skb режимі, та форма вхідного трафіку — все це впливає на те, скільки користі ви насправді отримаєте. Ось чому цифри пакетів за секунду в заголовках від постачальників або гіперскейлерів краще розглядати як доказ того, що модель раннього відкиду працює, а не як цифри, які повинен очікувати кожен VPS. З цим на увазі, наступний розділ показує, як виглядає XDP на реальному хості Ubuntu через кілька безпечних знімків оператора.

Як виглядає XDP на практиці — знімки команд

Цей розділ — це снімок proof-of-concept. Мета — зробити 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 або драйвері, що робить це безпечнішим шляхом для першого proof of concept.

Щоб перевірити, що програма насправді прикріпилась, запустіть:

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 або широкі правила drop на живому віддаленому інтерфейсі, який переносить вашу SSH-сесію, якщо у вас немає доступу до консолі для відновлення. Ця стаття залишається з політикою allow та однією правилою для адреси документації саме з цієї причини.

Далі перевірте виявлення можливостей. Це розповідає вам, що NIC та драйвер виявляють на поверхні XDP, а не яка буде ваша остаточна продуктивність.

sudo xdp-loader features <ifname>

Точний результат залежить від обладнання, але репрезентативний результат часто містить рядки на кшталт:

Найважливіше тут — NETDEV_XDP_ACT_BASIC, оскільки це говорить вам, що шлях виявляє основну модель дій XDP. Додаткові прапори, такі як підтримка redirect, корисні, але вони не потрібні для простого proof of concept проти 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. Іншими словами, пакети, які відповідають правилу, відкидаються, а пакети, які не відповідають правилу, продовжують звичайний шлях.

Цей приклад навмисне нудний. З точки зору anti-DDoS, він також показує найпростішу можливу версію ранньої правила drop: трафік від джерела, яке вам не потрібно, може бути відхилено до того, як решта хосту вкладе в нього багато роботи.

Нарешті, перевірте загальний стан в одному місці.

sudo xdp-filter status

На типовій системі шаблон результату є найбільш інформативним.

Це представлення статусу робить proof of concept операційно корисним. Ви можете побачити завантажений інтерфейс, активний режим, активний варіант xdp-filter, ефективний набір функцій та стан лічильника для кожної правила в одній команді. XDP_ABORTED, якщо він з’являється, — це переважно помилка/debug bucket, а не дія, яку ви плануєте. Що ще важливіше, якщо лічильник drop залишається на 0, це не означає, що фільтр не вдався. Це означає лише, що жоден пакет, який відповідає правилу, не потрапив під час вікна захоплення.

💡 Висновок: Розглядайте xdp-filter як простий, без стану proof-of-concept інструмент, а не як заміну nftables. Також пам’ятайте, що пакети, відкинуті на рівні XDP, можуть ніколи не з’явитися на звичайному шляху tcpdump, що робить вихід статусу та лічильники, власні XDP, більш надійним методом перевірки. Якщо ви хочете живий вид пізніше, sudo xdp-filter poll -i 2000 — це розумний необов’язковий наступний крок — але тільки коли інтерфейс уже має достатньо цікавого трафіку, щоб зробити цей результат корисним.

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

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

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

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

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

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

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

Висновок: XDP — це ранній рівень фільтрації, а не повний щит

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

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