Что такое XDP и как он может помочь в построении защиты от DDoS-атак?

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

Если вы запускаете публичный API, обратный прокси, игровой сервис или любую другую рабочую нагрузку, доступную из интернета, вы можете столкнуться с болезненной ситуацией, когда сервер занят обработкой трафика, который изначально не представлял никакой ценности. Приложение не обязательно выходит из строя из-за того, что не справляется с реальными пользователями. Оно выходит из строя потому, что хост тратит процессорное время на получение, разбор, классификацию и передачу мусорных пакетов глубже в 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, межсетевое экранирование, сокеты и в конечном счёте приложение. Визуально путь выглядит следующим образом:

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 лучше защищает ресурсы хоста, чем насыщенный вышестоящий канал. Если канал к провайдеру уже заполнен, раннее отбрасывание на уровне хоста слишком запоздало, чтобы самостоятельно исправить сетевой путь.

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

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

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

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

В качестве быстрой схемы принятия решений:

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

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

Заключение: XDP — это уровень раннего отбрасывания, а не весь щит

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

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