O que é XDP e como pode ajudar a construir proteção Anti-DDoS?

Introdução ao XDP e Como Pode Ajudar a Construir Proteção Anti-DDoS?

Se gere uma API pública, proxy reverso, serviço de jogos ou qualquer outra carga de trabalho voltada para a internet, pode atingir um ponto doloroso em que o servidor está ocupado com tráfego que nunca foi útil. A aplicação não está necessariamente a falhar porque não consegue lidar com utilizadores reais. Está a falhar porque o host está a gastar tempo de CPU a receber, analisar, classificar e transportar pacotes inúteis mais fundo no Linux antes que algo diga “não.” Muitos problemas anti-DDoS começam aí: não como uma questão de largura de banda, mas como uma questão de custo de processamento de pacotes.

Isso importa para mais do que especialistas em kernel. Programadores, self-hosters, operadores de VPS e servidores dedicados, e até leitores empresariais que comparam opções de resiliência deparam-se todos com a mesma questão básica: quão cedo pode o tráfego mau ser rejeitado antes de consumir tempo e recursos que deveriam pertencer ao trabalho real? Alguns ataques destroem o próprio uplink, mas muitas situações prejudiciais surgem mais cedo como pressão de pacotes-por-segundo no host muito antes de a linha estar totalmente saturada.

É aí que o XDP se torna digno de compreensão. Não substitui a mitigação upstream, uma firewall ou controlos conscientes da aplicação. O que oferece é um ponto de verificação muito mais antecipado no caminho de pacotes do Linux. Este artigo explica o que é o XDP, por que essa posição “mais cedo” importa para o trabalho anti-DDoS, e onde se encaixa numa stack realista. Para acompanhar o resto, precisa apenas de um conjunto muito pequeno de vocabulário primeiro.

Palavras-Chave do XDP que Precisa em 2 Minutos

Vários dos termos em torno do XDP sobrepõem-se, e à primeira vista soam mais intimidantes do que realmente são. Isso é normal. O objetivo deste glossário não é transformar o artigo numa lição de internos do Linux. É apenas linguagem suficiente para ajudar o resto da explicação a assentar claramente.

Se guardar apenas um atalho mental dessa tabela, que seja este: eBPF é o mecanismo programável, e XDP é um lugar específico onde esse mecanismo pode ser executado. Com isso em mente, o próximo passo é uma questão mais simples e mais útil: o que está o XDP realmente a fazer?

O que o XDP Realmente É

O XDP é um hook de processamento de pacotes antecipado no Linux. Permite ao sistema executar um pequeno programa eBPF num pacote assim que esse pacote chega a uma interface de rede. Nesse momento, o Linux pode tomar uma decisão rápida: deixar o pacote continuar (XDP_PASS), descartá-lo imediatamente (XDP_DROP), ou tratá-lo de outra forma definida. Para este artigo, a parte importante é simples: o XDP pode dizer “deixa passar” ou “para aqui” muito cedo.

O Linux usa eBPF em vários contextos, não apenas em redes. O XDP é a versão focada em redes construída para o tratamento muito antecipado de pacotes recebidos. Portanto, XDP não é outra palavra para eBPF. É uma ferramenta baseada em eBPF com um papel muito específico.

Esse papel é o que torna o XDP útil para o trabalho anti-DDoS. O XDP é executado antes que os pacotes passem pelas partes normais e mais pesadas do caminho de rede do Linux. Assim, o Linux pode decidir sobre algum tráfego antes de gastar mais esforço em firewalling, rastreamento de conexões, sockets e, eventualmente, a própria aplicação. É por isso que a vantagem real do XDP não é apenas a filtragem — é a filtragem mais cedo.

Adicionalmente, o XDP é útil para mais do que anti-DDoS. Também pode suportar direcionamento de tráfego e outras tarefas de tratamento de pacotes. Mas o anti-DDoS é o lugar mais fácil para ver o seu valor, porque o benefício resume-se a uma ideia prática: quanto mais cedo o tráfego mau for rejeitado, menos trabalho inútil o servidor tem de fazer. E para entender por que isso importa tanto, o próximo passo é olhar exatamente para onde o XDP se situa no caminho de receção de pacotes.

O Modelo Mental: O XDP É o Portão, Não a Receção

A forma mais fácil de visualizar o XDP é como um segurança no portão, não um rececionista mais dentro do edifício. Se um visitante obviamente indesejado for rejeitado no portão, o edifício evita uma longa cadeia de trabalho inútil. Ninguém abre a porta interior, regista-o num sistema, ou o acompanha pelo corredor. Se esperar até à receção para o rejeitar, o edifício já gastou tempo e atenção na pessoa errada.

O tratamento de pacotes do Linux funciona da mesma forma. Num caminho de receção simplificado, o pacote chega do NIC e do driver, alcança o XDP, e só então continua para a stack de rede do kernel mais rica que alimenta conntrack, firewalling, sockets e finalmente a aplicação. Visualmente, o caminho parece assim:

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

No modo nativo, o XDP pode agir antes que o Linux aloque e preencha a estrutura habitual sk_buff — o objeto de pacote do kernel mais rico que o resto da stack espera. Esse detalhe parece pequeno, mas é o coração da história de desempenho. Se o pacote é obviamente indesejado, descartá-lo antes que o Linux construa essa estrutura normal significa menos trabalho de CPU, menos pressão de memória e menos pressão a jusante. XDP_PASS existe porque nem todo o pacote é mau; é a ação “continua” que permite que o tráfego legítimo continue a mover-se. XDP_DROP é a estrela anti-DDoS porque termina a jornada antes que a parte cara comece. Outras ações como REDIRECT também existem, mas não são essenciais para este explicador.

Uma vez que o posicionamento está claro, o valor anti-DDoS — e as limitações — tornam-se muito mais fáceis de avaliar realisticamente.

Como o XDP Ajuda no Anti-DDoS — e Onde Começam os Seus Limites

O caso anti-DDoS para o XDP é direto: é uma forma barata de rejeitar lixo óbvio antes que o Linux gaste recursos em conntrack, tratamento de sockets e entrega ao espaço de utilizador. Se um host está a ser bombardeado com tráfego de alta taxa que nunca deveria alcançar a aplicação de qualquer forma, cada pacote descartado cedo é trabalho que o servidor já não tem de fazer mais tarde. É por isso que o XDP é mais forte na extremidade L3/L4 do problema: endereços de origem em que já não confia, protocolos que não quer, ou padrões de tráfego que claramente não são legítimos para a carga de trabalho.

Isso importa mais durante inundações de lixo onde a parte dolorosa não é o volume bruto de dados, mas o tratamento repetido de pacotes. Um proxy reverso, serviço pesado em UDP, ou API pública pode tornar-se lento muito antes de o uplink estar totalmente saturado se o host estiver ocupado a classificar disparates. O XDP dá-lhe uma forma de cortar parte desse desperdício perto da porta.

📝 Nota: O XDP protege melhor os recursos do host do que protege um link upstream saturado. Se o link voltado para o fornecedor já estiver cheio, o descarte antecipado ao nível do host é demasiado tarde para corrigir o caminho de rede por si só.

Essa distinção é a principal razão pela qual o XDP pertence a um design em camadas em vez de num pedestal. A tabela seguinte é a versão prática de XDP vs nftables vs mitigação upstream/fornecedor:

Por outras palavras, XDP e nftables não são inimigos. Resolvem partes diferentes do caminho. nftables é mais rico e com estado. xdp-filter — a ferramenta de demonstração usada neste artigo — é intencionalmente simples e sem estado, o que é exatamente por que é útil para mostrar o modelo XDP sem fingir substituir uma firewall completa. Se precisar de rastreamento de conexões, listas de permissões em camadas, tratamento de estado de resposta, ou regras conscientes da aplicação, já está a descrever problemas que pertencem mais fundo do que este utilitário de demonstração.

Operadores de produção usam descarte no estilo XDP porque o descarte antecipado reduz o trabalho a jusante. A história L4Drop da Cloudflare é um exemplo bem conhecido de por que esse modelo se tornou atrativo em operações reais. Mas a lição importante não é apenas o número de pacotes-por-segundo da manchete. É a lógica de design: rejeitar tráfego mau mais cedo para que o resto da máquina possa continuar a servir tráfego real por mais tempo.

Os resultados do mundo real dependem muito do ambiente. O suporte de NIC e driver, se o XDP é executado em modo nativo ou skb, e a forma do tráfego recebido afetam todos o benefício que realmente obtém. É por isso que os números de pacotes-por-segundo de manchete de fornecedores ou hyperscalers são melhor tratados como prova de que o modelo de descarte antecipado funciona, não como números que cada VPS deve esperar. Com isso em mente, a próxima secção mostra como o XDP parece num host Ubuntu real através de alguns snapshots seguros de operador.

Como o XDP Parece na Prática — Snapshots de Comandos

Esta secção é um snapshot de prova de conceito. O objetivo é tornar o XDP real no Ubuntu 24.04 com o conjunto relevante de comandos: suficiente para carregar um filtro, inspecionar o que foi anexado, adicionar uma regra de baixo risco, e ler os contadores que importam.

Antes de prosseguir para a configuração do XDP, precisa primeiro de descobrir e selecionar o nome da interface.

ip -br link

Instale os pré-requisitos.

sudo apt update
sudo apt install -y xdp-tools

No comando abaixo, substitua <ifname> pelo nome real da sua interface de rede, como eth0 ou ens3.

sudo xdp-filter load -m skb <ifname>

Os primeiros dois comandos são responsáveis por instalar as ferramentas necessárias, garantindo que o ambiente tem tudo o que é necessário para executar a demonstração.

O terceiro comando carrega então xdp-filter no modo skb com a política allow padrão. No host Ubuntu usado para este artigo, isso produziu a variante xdpfilt_alw_all com o conjunto completo de funcionalidades tcp,udp,ipv6,ipv4,ethernet,allow. Escolher -m skb evita assumir suporte nativo de XDP no seu NIC ou driver, tornando-o o caminho mais seguro para uma primeira prova de conceito.

Para verificar que o programa foi realmente anexado, execute:

sudo xdp-filter status
ip -details link show dev <ifname>

Em xdp-filter status, quer ver a sua interface listada com skb mode; no host de teste aqui, o conjunto de funcionalidades carregado mostrou tcp,udp,ipv6,ipv4,ethernet,allow. Em ip -details link show, um anexo xdpgeneric e o programa xdp_dispatcher confirmam que o XDP genérico está ativo nessa interface.

⚠️ Aviso: Não teste políticas de negação padrão ou regras de descarte amplas numa interface remota ativa que está a transportar a sua sessão SSH a menos que tenha recuperação por consola. Este artigo mantém-se com uma política allow e uma regra de endereço de documentação exatamente por essa razão.

A seguir, inspecione a descoberta de capacidades. Isto diz-lhe o que o NIC e o driver expõem na superfície XDP, não qual será o seu desempenho final.

sudo xdp-loader features <ifname>

O resultado exato varia por hardware, mas um resultado representativo contém frequentemente linhas como estas:

O que mais importa aqui é NETDEV_XDP_ACT_BASIC, porque isso diz-lhe que o caminho expõe o modelo de ação XDP principal. Flags extra como suporte a redirect são úteis, mas não são necessários para uma simples prova de conceito anti-DDoS.

A seguir, verifique como o loader XDP está a gerir o programa e em que modo está a ser executado.

sudo xdp-loader status

Num sistema a funcionar, uma vista de estado pode parecer assim:

Esta é uma verificação de operador pequena mas importante. Confirma que o XDP não é apenas um conceito de regra a viver no espaço de utilizador — há um programa carregado na interface, e a coluna de modo diz-lhe se está a olhar para native ou skb.

Agora adicione uma regra de exemplo segura usando um endereço IP de documentação. A flag -s é útil porque imprime o estado da regra resultante imediatamente em vez de o deixar com um sucesso silencioso.

sudo xdp-filter ip -s -m src 192.0.2.1

Uma resposta representativa pode parecer assim:

📝 Nota: xdp-filter usa por padrão uma política allow. Por outras palavras, os pacotes que correspondem à regra são descartados, e os pacotes que não correspondem à regra continuam pelo caminho normal.

Este exemplo é intencionalmente simples. Em termos anti-DDoS, também mostra a versão mais simples possível de uma regra de descarte antecipado: o tráfego de uma origem que não quer pode ser rejeitado antes que o resto do host invista muito trabalho nele.

Finalmente, inspecione o estado geral num só lugar.

sudo xdp-filter status

Num sistema típico, o padrão de saída é o mais informativo.

Esta vista de estado é onde a prova de conceito se torna operacionalmente útil. Pode ver a interface carregada, o modo ativo, a variante xdp-filter ativa, o conjunto de funcionalidades efetivo, e o estado do contador por regra num único comando. XDP_ABORTED, se aparecer, é principalmente um bucket de erro/depuração em vez da ação que planeia. Mais importante, se o contador de descarte ficar em 0, isso não significa que o filtro falhou. Significa apenas que nenhum pacote correspondente atingiu a regra durante a janela de captura.

💡 Conclusão: Trate o xdp-filter como uma ferramenta simples e sem estado de prova de conceito, não como um substituto para nftables. Tenha também em mente que os pacotes descartados na camada XDP podem nunca aparecer no caminho habitual do tcpdump, o que torna a saída de estado nativo do XDP e os contadores o método de validação mais fiável. Se quiser uma vista em tempo real mais tarde, sudo xdp-filter poll -i 2000 é um próximo passo opcional sensato — mas apenas quando a interface já tem tráfego interessante suficiente para tornar essa saída útil.

Ver uma demonstração segura torna a ideia concreta. A decisão real, porém, não é se os comandos são executados. É se esta camada extra vale a complexidade operacional no tipo de infraestrutura que realmente gere.

Quando o XDP Vale a Pena Considerar para VPS e Servidores Dedicados

O XDP torna-se interessante quando uma carga de trabalho voltada para o público está a perder tempo de CPU significativo para pacotes indesejados antes que a aplicação possa responder normalmente. Os bons candidatos incluem APIs públicas, proxies reversos, gateways, serviços UDP pesados expostos à internet, e hosts que regularmente veem tráfego de lixo suficiente para stressar o caminho de rede mesmo quando a própria aplicação não é o bottleneck. Nesses ambientes, a rejeição mais antecipada pode recuperar espaço real no servidor.

Há também muitos casos onde a filtragem mais simples é suficiente. Um website de baixo tráfego, uma ferramenta interna, uma caixa de staging, ou um serviço cujo requisito real é firewalling de host com estado em vez de alívio de taxa de pacotes geralmente não precisa de XDP primeiro. Se nftables já cobre o risco sem pressão notável no caminho de pacotes, adicionar outra camada pode criar mais partes móveis do que valor.

Como um framework de decisão rápida:

• O firewalling geralmente é suficiente quando o tráfego é leve, a política precisa de estado ou lógica de serviço mais rica, e o host não está visivelmente a queimar CPU em pacotes de lixo.
• O XDP vale a pena avaliar quando o tráfego indesejado está a alcançar o host com frequência suficiente para que o descarte antecipado possa proteger a capacidade de CPU, conntrack e socket.
• A mitigação upstream permanece obrigatória quando o modo de falha real é a saturação do link do fornecedor ou inundações volumétricas maiores antes que os pacotes sequer alcancem o seu servidor.

Os utilizadores de VPS devem ter em mente uma ressalva: os caminhos de NIC virtual e a abstração do fornecedor podem limitar as expectativas do modo nativo mesmo quando o modo skb funciona bem para uma demonstração. Os servidores dedicados geralmente dão-lhe mais controlo sobre drivers, hardware e observabilidade, por isso as probabilidades de suporte significativo ao modo nativo são melhores aí — mas mesmo em bare metal, o XDP ainda é uma camada, não a resposta completa. Se está a avaliar o AlexHost ou qualquer outro fornecedor, faça três perguntas separadas em vez de as juntar: que tratamento de DDoS upstream existe, quanto espaço de host o plano lhe dá, e que controlos ao nível do host são realistas nessa plataforma?

Conclusão: O XDP É uma Camada de Descarte Antecipado, Não o Escudo Completo

A forma mais clara de pensar sobre o XDP é esta: dá ao Linux um primeiro ponto de verificação rápido para tráfego mau óbvio e inundações de pacotes, o que significa que protege melhor os recursos do servidor do que protege um link upstream saturado. É por isso que o XDP importa nas conversas anti-DDoS. Não substitui a mitigação upstream, firewalling com estado, ou controlos conscientes da aplicação. Ajuda fazendo com que o host faça menos trabalho inútil.

Portanto, a regra geral é simples. Se o tráfego indesejado está a desperdiçar CPU do host antes que as cargas de trabalho reais possam responder, o XDP vale a pena avaliar como uma camada de descarte antecipado. Se o problema principal é um uplink cheio ou política que depende de estado e lógica de aplicação, o XDP pertence atrás da mitigação upstream e filtragem mais profunda em vez de à frente delas como uma resposta completa. Um próximo passo natural a partir daqui seria um acompanhamento sobre a escrita de programas XDP personalizados ou a construção de uma defesa em camadas mais rica em torno da mesma ideia de descarte antecipado.