O Som de um Martelo Quebrando a Peça Errada
Você já ouviu um servidor gritar? Não gritar no sentido literal, mas o zumbido agudo dos ventoinhas a 100%, o travamento do SSH, aquele delay de 30 segundos para um simples ls. Eu já. Era 3h da manhã, o pager do Slack explodindo, o cliente – um e-commerce de nicho de discos de vinil raros – ligando aos berros. O ataque DDoS não era volumétrico; era um ataque de camada 7, caprichado, mirando um endpoint de busca elástico que consumia 4GB de RAM por request.
O problema? A VPS era um burrinho de carga: 1 vCPU, 1GB de RAM, SSD básico. E, claro, o cliente não queria pagar um centavo a mais por proteção DDoS gerenciada. Era o fim da linha. Ou não.
O Vértice Esquecido: Painéis Web e o Elo Fraco
A maioria dos tutoriais de proteção DDoS pressupõe orçamento infinito. Cloudflare, AWS Shield, balanceadores elásticos… Mas e quando o orçamento é de hipster dev? A verdade suja é que 90% dos sites rodam em painéis compartilhados ou VPS mínimas, e a proteção DDoS real é deixada de lado.
O ataque? Slowloris modificado, misturado com requests HTTP POST com cabeçalhos maliciosos. O nginx, configurado no padrão, deixava cada conexão aberta por 60 segundos. Em 5 minutos, o connection pool estourou. O site foi abaixo.
A Estratégia de Defesa com CrowdSec e IPtables
Sem verba extra, a saída foi o CrowdSec. Um firewall colaborativo open source que detecta comportamentos anômalos. Instalei, cofigurei para o nginx, e criei uma blacklist de IPs suspeitos. Mas logo percebi: o CrowdSec sozinho não segura um ataque de 10k IPs únicos.
A chave estava no kernel tuning. Modifiquei o syn backlog, tcp_tw_reuse, e reduzi o timeout do nginx para 5 segundos. Usei iptables com connlimit para limitar conexões por IP e por porta. Resultado: em 3 minutos, o tráfego malicioso era filtrado, e o servidor voltou a responder.
O Dossiê Investigativo: Por que o Controle de Conexões é Seu Melhor Amigo
A proteção DDoS não precisa de hardware caro. Precisa de conceitos. O ataque Slowloris morre quando você limita conexões simultâneas por IP. Ataques volumétricos (L3/L4) são mitigados com iptables e rate-limiting no kernel. Já ataques de camada 7 exigem inspeção de payload e Web Application Firewall – mesmo que simples como o mod_security ou naxsi.
Exercício de estresse: submeta o servidor a um ataque simulado com slowloris ou hping3. Veja onde quebra. Ajuste os parâmetros. Repita. É o método científico da sobrevivência digital.
A Micro-Anedota: O Erro que Salvou o Servidor
Horas antes do ataque, eu havia configurado um fail2ban com uma regra maluca: banir IPs que fizessem mais de 10 requests em 3 segundos em qualquer página administrativa. Achava que era exagero. Quando o ataque veio, o fail2ban baniu 80% dos IPs atacantes automaticamente, reduzindo a carga para o CrowdSec. O erro? A regra estava desativada em produção. Se eu não tivesse ativado por acaso naquela manhã… bem, não estaríamos aqui conversando.
Lições Aprendidas e Como Reproduzir
- Invista em monitoramento: Netdata ou Collectd para visualizar conexões ativas e uso de RAM.
- Hardening de nginx/apache: Reduza timeouts, limite tamanho de cabeçalhos, desative métodos HTTP desnecessários (TRACE, DELETE).
- CrowdSec é vida: Muito melhor que fail2ban para cenários modernos. Use com as listas de reputação.
- Nunca subestime o kernel: Ajustes em
/etc/sysctl.confpodem fazer uma VPS de 1GB parecer um servidor dedicado.
O segredo não está no hardware, está na configuração. E na disposição para errar, aprender e ajustar antes que a próxima onda de pacotes te engula.