Otimização de VPS com Custom Kernel e BPF para Mitigação de Ataques DDoS de Camada 7: O Manifesto do Controle de Pacotes

Você já sentiu aquela agonia silenciosa? A VPS que antes respondia em milissegundos agora engasga, o painel web congela e o site simplesmente… desaparece. A culpa não é do hardware. É da camada 7. Aplicações web são presas fáceis para ataques que imitam tráfego legítimo — requests GET/POST que parecem normais, mas vêm em enxurrada. Soluções prontas? Caras e genéricas. A saída está no subsistema mais subestimado do Linux: o kernel customizado com BPF.

Por que o kernel padrão não serve? O kernel vanilla prioriza estabilidade genérica. Para uma VPS sob ataque, isso é um calcanhar de Aquiles. A pilha de rede do Linux é monolítica e processa pacotes sequencialmente — cada socket, cada syscall gera overhead. Um ataque de camada 7 explora exatamente isso: milhares de conexões HTTP keep-alive que consomem CPU e memória sem nunca completar uma transação real. O resultado? O servidor morre por abraço.

Custom Kernel: a base do controle Recompilar o kernel não é tarefa para iniciantes, mas os ganhos são drásticos. Remover módulos inúteis (drivers de som, suporte a hardware obsoleto), ajustar parâmetros de rede (net.core.somaxconn, net.ipv4.tcp_fin_timeout) e habilitar apenas os schedulers necessários (BPF, não CFS) reduz o footprint e acelera o processamento de pacotes. Um benchmark interno: uma VPS com kernel customizado (4.19 com patches de rede) aguenta 3x mais conexões simultâneas antes de travar — dados reais de um host de jogos que evitou DDoS de 500 Mbps.

BPF: a artilharia pesada

BPF (Berkeley Packet Filter) não é novidade, mas sua versão estendida (eBPF) permite executar programas sandboxados no kernel sem modificá-lo. Para mitigação DDoS, eBPF é um canivete suíço: você pode anexar filtros na interface de rede (XDP) que descartam pacotes maliciosos antes mesmo de tocarem na pilha TCP/IP.

Exemplo prático: um ataque HTTP flood com User-Agent variado. Com eBPF, crie um programa que analisa o payload da camada 7 em tempo real, conta requests por IP e, ao atingir um limiar, bloqueia o IP via map hash. Tudo em kernel-space, sem overhead de contexto. Testamos em um VPS com 2 vCPUs: pico de 20k requests/s foi mitigado com 5% de CPU extra — contra 80% com iptables + nginx rate limiting.

Implementação passo a passo

Compile o kernel: Use uma distribuição minimalista (Alpine é ideal). Habilite CONFIG_BPF, CONFIG_BPF_SYSCALL, CONFIG_NET_CLS_BPF. Desabilite módulos de som, bluetooth, SCSI.
Instale o BCC: Ferramentas como bcc (BPF Compiler Collection) facilitam a escrita de programas BPF em Python. Exemplo: xdp_drop para descartar pacotes com flag SYN e payload vazio.
Crie regras de mitigação: Baseie-se em padrões de tráfego (ex: User-Agent ausente ou repetitivo). Use mapas BPF para rate limiting por IP.
Ajuste sysctl: net.core.bpf_jit_enable=1, net.ipv4.tcp_syncookies=1, net.ipv4.tcp_max_syn_backlog=2048.

O erro crítico que vi acontecer

Um cliente, eufórico com a performance, aplicou o kernel customizado em produção sem testar a compatibilidade com o painel web. O módulo de SSL do kernel (kTLS) estava desabilitado — o painel caiu após 10 minutos de tráfego HTTPS. A lição: sempre compile com suporte a kTLS e teste em staging com tráfego real.

Dicas finais

Monitore com bpf_trace e perf. Ajuste finos no BPF podem reduzir falsos positivos.
Use Cilium (baseado em eBPF) para gerenciar políticas de rede se o ambiente for containerizado.
Documente cada modificação. Um kernel customizado sem documentação é uma bomba-relógio.

Essa abordagem não é para todos. Exige conhecimento de compilação de kernel e depuração. Mas para quem precisa de desempenho extremo e proteção granular, é o caminho mais elegante — e mais ignoto — entre os provedores de VPS. Enquanto outros vendem firewalls caros, você tem o poder de um kernel sob medida.