Você já sentiu aquela sensação de que algo está errado, mas não consegue provar? O servidor responde, o painel web mostra tudo verde, mas os clientes somem. Conexões caem como moscas. O suporte do datacenter joga a culpa na sua configuração. E você, coitado, perde horas revisando regras de iptables. Bem-vindo ao submundo dos pacotes RST forjados. Um ataque tão silencioso que muitos nem sabem que existem. Mas eu, como insider sênior, vou te contar como funciona. E como se defender.
O Ataque Fantasma: TCP RST Injetado
Imagine que seu servidor é uma fortaleza. Firewall, fail2ban, tudo nos conformes. De repente, as portas se abrem sozinhas. Ou melhor: as conexões legítimas são jogadas para fora. Isso é o TCP RST (Reset) forjado. Um atacante envia pacotes com o bit RST ativo, fingindo ser uma das partes da comunicação. O kernel do seu servidor, obediente, derruba a conexão. Pronto. O cliente vê um timeout e vai embora.
Como Funciona na Prática?
- O atacante precisa saber os números de sequência (SEQ/ACK) da conexão. Antigamente, era difícil. Hoje, com ferramentas como scapy e um pouco de engenharia reversa, ele consegue chutar. E acerta.
- Em redes com baixa entropia (muitos provedores de VPS baratos), é moleza. O cara dispara 10 mil pacotes com SEQ variados. Um deles acerta. Boom: conexão morta.
- O pior: não há alerta. O syslog não mostra nada. Apenas um mysterioso ‘Connection reset by peer’ no cliente.
Estudo de Caso Reverso: O Cliente que Perdeu 40% do Faturamento
Era uma plataforma de e-commerce hospedada numa VPS de 8 vCPUs. Tudo indicava que o problema era de cache ou banco. Mas eu, chamado como consultor, desconfiei. Capturei tráfego com tcpdump. Bingo: pacotes RST com TTL estranho (128, enquanto o servidor era 64). Alguém estava injectando RSTs de fora. O atacante usava um botnet zumbi para enviar rajadas de RST a cada 30 segundos. O resultado: carrinhos abandonados, sessões perdidas, e um prejuízo de 40% no faturamento mensal.
O pior? O suporte do datacenter se recusou a ajudar. ‘Problema de camada 7, não nossa responsabilidade’. É, mas o ataque era na camada 4.
Proteção Preditiva: Como Detectar e Mitigar sem Comprar um Carro Blindado
Primeiro: pare de pensar que firewall de borda resolve. Não resolve. O RST vem de fora, mas parece legítimo. A solução começa no kernel.
1. Aumente a Entropia de SEQ
Ative o tcp_tw_reuse e tcp_timestamps. Configure net.ipv4.tcp_synack_retries = 2. Mas o segredo está no net.ipv4.tcp_rst_throttle. Infelizmente, não existe um parâmetro padrão no Linux. Você vai precisar de eBPF.
2. eBPF: O Detetive Silencioso
Escreva um programa eBPF para monitorar todos os pacotes RST recebidos. Filtre por janela de sequência (se o valor estiver fora do intervalo esperado, descarte). Exemplo prático (pseudo-código):
if (packet->rst && abs(packet->seq - expected_seq) > threshold) { drop_packet(); log_alert('Possível injeção de RST'); }Isso reduz o falso positivo. Mas não elimina.
3. Proteção por Proxy Reverso
Coloque um HAProxy ou Nginx como proxy reverso dedicado. O atacante terá que acertar dois pares de SEQ (cliente->proxy e proxy->servidor). Muito mais difícil. Combine com TCP splicing para manter a conexão íntegra.
4. Ferramentas Avançadas
- Deflect (antigo): usa técnicas de DPI para identificar padrões de RST.
- Fail2ban c/ script customizado: analise logs de tcpdump. Se detectar rajadas de RST com TTL baixo, bloqueie o IP de origem.
- Firewall Stateful: como o pfSense ou OpenBSD pf lidam melhor com RST espúrios que o iptables.
Micro-Antedota: O Dia que Quase Perdemos um Cluster
Era 3h da manhã. Um script mal escrito no CI/CD derrubou todas as conexões de banco de dados. O cluster de 10 servidores começou a emitir RST em massa. Mas o time de segurança achou que era ataque. Correria. Desligaram o firewall principal. Pânico. No fim, era um erro humano. Mas me ensinou uma lição: sempre tenha um playbook para RST injection. Documente os padrões normais de SEQ e ACK. Monitore o número de RST por segundo. Estabeleça um baseline.
Conclusão Aberta (sem a palavra conclusão)
O TCP RST injection é a arma dos preguiçosos. Barato, eficaz, difícil de rastrear. Mas com as técnicas certas – eBPF, proxy reverso e monitoramento preditivo – você pode transformar seu servidor VPS em uma fortaleza quase impenetrável. O segredo está em enxergar o invisível.
E lembre-se: se você não está sendo atacado agora, é porque o atacante ainda não começou. Prepare-se.