Что такое 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, sockets и наконец приложение. Визуально путь выглядит так:

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, обработку сокетов и доставку в пользовательское пространство. Если хост засыпан высокоскоростным трафиком, который в любом случае не должен достичь приложения, каждый пакет, отброшенный на ранней стадии — это работа, которую серверу больше не нужно выполнять. Вот почему XDP наиболее эффективен на краю L3/L4: исходные адреса, которым вы уже не доверяете, протоколы, которые вам не нужны, или паттерны трафика, которые явно не являются легитимными для вашей нагрузки.

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

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

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

Другими словами, XDP и nftables — не враги. Они решают разные части пути. nftables богаче и stateful. xdp-filter — демонстрационный инструмент, используемый в этой статье — намеренно простой и stateless, что именно поэтому полезно для демонстрации модели XDP без претензии на замену полноценного файерволла. Если вам нужна отслеживание соединений, многоуровневые списки разрешений, обработка состояния ответов или правила с учётом приложения, вы уже описываете проблемы, которые принадлежат более глубоким уровням, чем эта демонстрационная утилита.

Операторы в production используют отброс в стиле 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 позволяет избежать предположений о встроенной поддержке XDP в вашей сетевой карте или драйвере, что делает это более безопасным путем для первого доказательства концепции.

Чтобы убедиться, что программа действительно подключена, выполните:

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 активен на этом интерфейсе.

⚠️ Предупреждение: Не тестируйте политики deny-default или широкие правила drop на живом удаленном интерфейсе, который несет вашу сессию SSH, если у вас нет доступа к консоли восстановления. Эта статья придерживается политики allow и одного правила для адреса документации именно по этой причине.

Далее проверьте обнаружение возможностей. Это показывает, что сетевая карта и драйвер предоставляют на поверхности 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, он также показывает самую простую версию раннего правила drop: трафик из источника, который вам не нужен, может быть отклонен до того, как остальная часть хоста потратит на него много работы.

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

sudo xdp-filter status

На типичной системе шаблон вывода является наиболее информативным.

Это представление статуса — это место, где доказательство концепции становится операционно полезным. Вы можете увидеть загруженный интерфейс, активный режим, активный вариант xdp-filter, эффективный набор функций и состояние счетчика для каждого правила в одной команде. XDP_ABORTED, если он появляется, в основном является ошибкой/отладочным бакетом, а не действием, которое вы планируете. Что еще более важно, если счетчик drop остается на 0, это не означает, что фильтр не сработал. Это только означает, что ни один соответствующий пакет не попал в правило во время окна захвата.

💡 Вывод: рассматривайте xdp-filter как простой, без состояния инструмент доказательства концепции, а не замену nftables. Также помните, что пакеты, отброшенные на уровне XDP, могут никогда не появиться в обычном пути tcpdump, что делает вывод статуса и счетчики, встроенные в XDP, более надежным методом проверки. Если вы хотите живой вид позже, sudo xdp-filter poll -i 2000 — это разумный дополнительный шаг — но только когда интерфейс уже имеет достаточно интересного трафика, чтобы сделать этот вывод полезным.

Просмотр безопасной демонстрации делает идею конкретной. Однако реальное решение — это не то, работают ли команды. Это то, стоит ли этот дополнительный уровень операционной сложности на типе инфраструктуры, которой вы действительно управляете.

Когда XDP стоит рассмотреть для VPS и выделенных серверов

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

Есть также много случаев, когда достаточно более простой фильтрации. Веб-сайт с низким трафиком, внутренний инструмент, staging-сервер или сервис, чьё реальное требование — это stateful host-фаерволл, а не облегчение нагрузки на пакеты, обычно не нуждаются в XDP в первую очередь. Если nftables уже покрывает риск без заметного давления на пакетный путь, добавление ещё одного слоя может создать больше движущихся частей, чем ценности.

Как быстрая схема принятия решения:

• Фаерволл обычно достаточен, когда трафик лёгкий, политика требует состояния или более богатой логики сервиса, и хост не видимо не сжигает CPU на мусорных пакетах.
• XDP становится стоит оценивать, когда нежелательный трафик достигает хоста достаточно часто, чтобы ранний отказ мог защитить CPU, conntrack и ёмкость сокетов.
• Upstream-смягчение остаётся обязательным, когда реальный режим отказа — это насыщение provider-канала или более крупное объёмное наводнение до того, как пакеты вообще достигнут вашего сервера.

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

Заключение: XDP — это ранний уровень отсева, а не полная защита

Самый простой способ думать об XDP — это то, что он дает Linux быструю первую контрольную точку для очевидного плохого трафика и наводнений пакетов, что означает, что он лучше защищает ресурсы сервера, чем защищает насыщенный восходящий канал. Вот почему XDP имеет значение в разговорах о защите от DDoS. Он не заменяет восходящую смягчение, stateful firewalling или элементы управления, зависящие от приложения. Он помогает, заставляя хост выполнять меньше бесполезной работы.

Итак, правило простое. Если нежелательный трафик тратит впустую CPU хоста до того, как реальные рабочие нагрузки смогут ответить, XDP стоит оценить как ранний уровень отсева. Если основная проблема — полная восходящая линия или политика, которая зависит от состояния и логики приложения, XDP должен находиться позади восходящей смягчения и более глубокой фильтрации, а не впереди них как полный ответ. Естественным следующим шагом отсюда было бы дополнительное обсуждение написания пользовательских программ XDP или построения более богатой многоуровневой защиты вокруг той же идеи раннего отсева.