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 você executa uma API pública, proxy reverso, serviço de jogos ou qualquer outra carga de trabalho voltada para a internet, pode chegar a um ponto difícil onde o servidor está ocupado com tráfego que nunca foi útil em primeiro lugar. A aplicação não está necessariamente falhando porque não consegue lidar com usuários reais. Está falhando porque o host está gastando tempo de CPU recebendo, analisando, classificando e levando pacotes inúteis mais profundamente no Linux antes de algo dizer “não”. Muitos problemas anti-DDoS começam ali: não como uma história de largura de banda, mas como uma história de custo de processamento de pacotes.

Isso importa para mais do que especialistas em kernel. Desenvolvedores, auto-hospedadores, operadores de VPS e servidores dedicados, e até leitores de negócios comparando opções de resiliência, todos se deparam com a mesma pergunta básica: com que antecedência o tráfego ruim pode ser rejeitado antes de queimar tempo e recursos que deveriam pertencer ao trabalho real? Alguns ataques esmagam o próprio uplink, mas muitas situações prejudiciais aparecem mais cedo como pressão de pacotes por segundo no host muito antes da linha estar completamente saturada.

É aí que XDP se torna digno de compreensão. Não substitui mitigação upstream, firewall ou controles cientes de aplicação. O que oferece é um ponto de verificação muito mais antecipado no caminho de pacotes do Linux. Este artigo explica o que é XDP, por que essa posição “mais antecipada” importa para o trabalho anti-DDoS e onde se encaixa em uma pilha realista. Para seguir o resto, você só precisa de um conjunto de vocabulário muito pequeno primeiro.

Palavras-chave XDP que Precisa em 2 Minutos

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

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

O Que XDP Realmente É

XDP é um hook de processamento de pacotes inicial no Linux. Permite que o sistema execute um pequeno programa eBPF em um pacote assim que esse pacote chega em 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: XDP pode dizer “deixe passar” ou “pare aqui” muito cedo.

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

Esse papel é o que torna XDP útil para trabalho anti-DDoS. XDP é executado antes dos pacotes passarem 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 firewall, rastreamento de conexão, sockets e eventualmente a aplicação em si. É por isso que a vantagem real do XDP não é apenas filtragem — é filtragem mais cedo.

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

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

A maneira mais fácil de visualizar XDP é como um segurança na porta, não um recepcionista mais dentro do edifício. Se um visitante obviamente indesejado é rejeitado na porta, o edifício evita uma longa cadeia de trabalho inútil. Ninguém abre a porta interna, o registra num sistema, ou o leva pelo corredor. Se você esperar até a recepção para rejeitá-lo, o edifício já gastou tempo e atenção na pessoa errada.

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

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

Em modo nativo, XDP pode agir antes de Linux alocar e preencher a estrutura sk_buff usual — o objeto de pacote do kernel mais rico que o resto da pilha espera. Esse detalhe parece pequeno, mas é o coração da história de desempenho. Se o pacote é obviamente indesejado, descartá-lo antes de Linux construir essa estrutura normal significa menos trabalho de CPU, menos churn de memória e menos pressão a jusante. XDP_PASS existe porque nem todo pacote é ruim; é a ação “continuar” que deixa o tráfego legítimo seguir em frente. XDP_DROP é a estrela anti-DDoS porque encerra a jornada antes da parte cara começar. Outras ações como REDIRECT também existem, mas não são essenciais para este explicador.

Uma vez que o posicionamento fica claro, o valor anti-DDoS — e as limitações — ficam muito mais fáceis de julgar realisticamente.

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

O caso anti-DDoS para XDP é direto: é uma forma barata de rejeitar lixo óbvio antes que Linux gaste recursos em conntrack, manipulação de socket e entrega em user-space. Se um host está sendo bombardeado com tráfego de alta taxa que nunca deveria chegar à aplicação de qualquer forma, cada pacote descartado no início é trabalho que o servidor não precisa fazer depois. É por isso que XDP é mais forte na borda L3/L4 do problema: endereços de origem que você já desconfia, protocolos que você 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 a manipulação repetida de pacotes. Um proxy reverso, serviço pesado em UDP ou API pública pode ficar lento muito antes do uplink estar totalmente saturado se o host está ocupado classificando disparates. XDP oferece uma forma de cortar parte desse desperdício perto da porta.

📝 Nota: XDP protege recursos do host melhor do que protege um link upstream saturado. Se o link voltado para o provedor já está cheio, o descarte antecipado em nível de host é tarde demais para corrigir o caminho de rede por si só.

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

Em outras palavras, XDP e nftables não são inimigos. Eles 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, que é exatamente por que é útil para mostrar o modelo XDP sem fingir substituir um firewall completo. Se você precisa de rastreamento de conexão, listas de permissão em camadas, manipulação de estado de resposta ou regras cientes de aplicação, você já está descrevendo problemas que pertencem mais profundamente do que este utilitário de demonstração.

Operadores de produção usam descarte em estilo XDP porque o descarte antecipado reduz o trabalho downstream. A história L4Drop da Cloudflare é um exemplo bem conhecido de por que esse modelo se tornou atraente 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 ruim mais cedo para que o resto da máquina possa continuar servindo tráfego real por mais tempo.

Os resultados do mundo real dependem muito do ambiente. Suporte de NIC e driver, se XDP é executado em modo nativo ou skb, e a forma do tráfego recebido afetam quanto benefício você realmente obtém. É por isso que números de pacotes por segundo da manchete de fornecedores ou hiperscalers são melhor tratados como prova de que o modelo de descarte antecipado funciona, não como números que cada VPS deveria esperar. Com isso em mente, a próxima seção mostra como XDP se parece em um host Ubuntu real através de alguns snapshots de operador seguro.

Como XDP Fica na Prática — Snapshots de Comando

Esta seção é um snapshot de prova de conceito. O objetivo é tornar XDP real no Ubuntu 24.04 com o conjunto relevante de comandos: o 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 com a configuração de XDP, você precisa descobrir e selecionar o nome da interface primeiro.

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 dois primeiros comandos são responsáveis por instalar as ferramentas necessárias, garantindo que o ambiente tenha tudo o que é necessário para executar a demonstração.

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

Para verificar que o programa realmente foi anexado, execute:

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

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

⚠️ Aviso: Não teste políticas de negação padrão ou regras de drop amplas em uma interface remota ativa que está carregando sua sessão SSH, a menos que você tenha recuperação de console. Este artigo mantém uma política allow e uma regra de endereço de documentação exatamente por essa razão.

A seguir, inspecione a descoberta de capacidade. Isso informa o que a NIC e o driver expõem na superfície XDP, não qual será o seu desempenho final.

sudo xdp-loader features <ifname>

A saída exata varia de acordo com o hardware, mas um resultado representativo geralmente contém linhas como estas:

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

A seguir, verifique como o carregador XDP está gerenciando o programa e em qual modo ele está sendo executado.

sudo xdp-loader status

Em um sistema funcionando, uma visualização de status pode parecer assim:

Este é um pequeno mas importante controle do operador. Confirma que XDP não é apenas um conceito de regra vivendo no espaço do usuário — há um programa carregado na interface, e a coluna de modo informa se você está olhando para native ou skb.

Agora adicione uma regra de exemplo segura usando um endereço IP de documentação. O sinalizador -s é útil porque imprime o estado da regra resultante imediatamente, em vez de deixá-lo 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 como padrão uma política allow. Em outras palavras, pacotes que correspondem à regra são descartados, e 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 drop antecipado: o tráfego de uma fonte que você não deseja pode ser rejeitado antes que o resto do host invista muito trabalho nela.

Por fim, inspecione o estado geral em um único lugar.

sudo xdp-filter status

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

Esta visualização de status é onde a prova de conceito se torna operacionalmente útil. Você pode ver a interface carregada, o modo ativo, a variante xdp-filter ativa, o conjunto de recursos efetivo e o estado do contador por regra em um comando. XDP_ABORTED, se aparecer, é principalmente um bucket de erro/debug em vez da ação que você planeja. Mais importante, se o contador de drop permanecer 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 xdp-filter como uma ferramenta simples e sem estado de prova de conceito, não como um substituto para nftables. Também tenha em mente que pacotes descartados na camada XDP podem nunca aparecer no caminho usual de tcpdump, o que torna a saída de status nativa de XDP e contadores o método de validação mais confiável. Se você quiser uma visualização ao vivo 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 essa camada extra vale a complexidade operacional no tipo de infraestrutura que você realmente gerencia.

Quando XDP Vale a Pena Considerar para VPS e Servidores Dedicados

XDP torna-se interessante quando uma carga de trabalho exposta ao público está perdendo tempo de CPU significativo para pacotes indesejados antes que a aplicação possa responder normalmente. Bons candidatos incluem APIs públicas, proxies reversos, gateways, serviços UDP expostos à internet e hosts que regularmente veem tráfego suficiente de lixo para estressar o caminho de rede mesmo quando a aplicação em si não é o gargalo. Nesses ambientes, a rejeição antecipada pode recuperar espaço real do servidor.

Há também muitos casos em que filtragem mais simples é suficiente. Um site com pouco tráfego, uma ferramenta interna, uma caixa de staging, ou um serviço cujo requisito real é firewall 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 visível no caminho de pacotes, adicionar outra camada pode criar mais partes móveis do que valor.

Como um framework rápido de decisão:

• Firewall 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 queimando CPU em pacotes de lixo.
• XDP torna-se digno de avaliação quando tráfego indesejado está chegando ao host com frequência suficiente para que a queda antecipada pudesse proteger CPU, conntrack e capacidade de socket.
• Mitigação upstream permanece obrigatória quando o modo de falha real é saturação do link do provedor ou inundação volumétrica maior antes mesmo dos pacotes chegarem ao seu servidor.

Usuários de VPS devem manter uma ressalva em mente: caminhos de NIC virtual e abstração do provedor podem limitar expectativas de modo nativo mesmo quando modo skb funciona bem para uma demonstração. Servidores dedicados geralmente lhe dão mais controle sobre drivers, hardware e observabilidade, então as chances de suporte significativo de modo nativo são melhores lá — mas mesmo em metal nu, XDP ainda é uma camada, não a resposta completa. Se você está avaliando AlexHost ou qualquer outro provedor, faça três perguntas separadas em vez de agrupá-las: qual tratamento DDoS upstream existe, quanto espaço de host o plano oferece, e quais controles de nível de host são realistas nessa plataforma?

Conclusão: XDP é uma Camada de Eliminação Antecipada, Não o Escudo Completo

A forma mais clara de pensar sobre XDP é esta: oferece ao Linux um ponto de verificação rápido para tráfego obviamente malicioso 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 XDP é importante em conversas anti-DDoS. Não substitui mitigação upstream, firewalling com estado ou controles cientes de aplicação. Ajuda fazendo o host fazer menos trabalho inútil.

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