O Fim do Mundo Começou com um Cron Job
Era 3h da manhã de uma terça-feira chuvosa. Eu estava monitorando um cluster de VPS dedicadas a processamento de vídeo em tempo real para um cliente de mídia. De repente, o gráfico de tráfego de entrada de uma das instâncias disparou para 12 Gbps. A Cloudflare, configurada na frente, mostrava um pico de 80 Gbps mitigado. Só que o tráfego não vinha de bots ou de um ataque volumétrico comum. Era síncrono. Milhares de requisições HTTP GET idênticas, com o mesmo User-Agent e payload, chegando a cada 500ms. Parecia um metrônomo digital. E o pior: o IP de origem era o próprio servidor atacante, em um loop de autoflagelação.
Naquele momento, eu estava diante de um ataque DDoS reflexivo de amplificação gerado por uma falha de sincronização interna – um bug em um gerenciador de tarefas (cron job) que, ao invés de executar um backup compactado, chamava um script que fazia requisições para um endpoint específico da API do próprio servidor, sem rate limiting. O servidor respondia com um pacote 50x maior que a requisição, e como o cron job estava em paralelo em 200 workers, cada worker gerava 10 requisições por segundo. O resultado: 2000 req/s amplificadas em tráfego de saída de 100 Mbps, mas que parecia um ataque externo clássico.
Se você nunca ouviu falar de ataques síncronos de manufatura, prepare-se. Este artigo é um dossiê sobre como sua própria infraestrutura pode se tornar a maior ameaça a si mesma.
O Pecado Original do Cron Job: Entendendo o Ataque Síncrono
Um ataque síncrono não precisa de botnets. Ele nasce de uma orquestração perfeita de requisições legítimas que, por uma falha de design, se alinham no tempo. No meu caso, o culpado foi um cron job que executava uma tarefa de manutenção em lote: ele fazia uma chamada HTTP para o servidor web local, processava dados e deletava logs. Sem querer, o desenvolvedor setou o intervalo de execução para cada 10 segundos com 200 processos simultâneos. O servidor web, configurado com mod_evasive apenas para IPs externos, ignorava o tráfego local.
Anatomia de um Ataque Síncrono de Manufatura
- Fonte: Processos legítimos (cron, CI/CD, agentes de monitoramento).
- Sincronia: Execução paralela no mesmo tick de tempo.
- Amplificação: Resposta do servidor maior que a requisição (ex: 500 bytes de requisição gerando 64 KB de resposta).
- Alvo: O próprio servidor ou serviços upstream (CDN, API gateway).
No meu caso, o cron job gerava uma requisição POST para /api/logs/export, que retornava um JSON com logs compactados em base64. O payload médio era de 4 KB, mas a resposta vinha com 2 MB. Com 200 workers e 10 requisições cada por minuto, o tráfego de saída totalizava 200 * 10 * 2 MB = 4000 MB/minuto, ou ~66 MB/s. Em uma VPS com uplink de 1 Gbps, isso consumia 50% da banda disponível. Mas como o tráfego era local, a Cloudflare só via o tráfego normal de entrada. Até que o servidor começou a retornar 503 para clientes reais, e o monitoramento de DDoS da Cloudflare interpretou o aumento de taxa de erro como um ataque, ativando a mitigação que, por sua vez, bloqueou o IP do servidor. O cliente ficou offline por 47 minutos.
Esse tipo de incidente é mais comum do que parece. Grandes provedores de nuvem chamam isso de “amplificação de manufatura” ou “DDoS reflexivo interno”. Empresas de segurança como a Cloudflare e a Akamai têm alertas internos sobre isso, mas raramente compartilham publicamente. Um engenheiro da AWS certa vez me contou que 15% dos “ataques DDoS” reportados por clientes são, na verdade, loops internos mal configurados.
O Estudo de Caso Reverso: Quando a Mitigação Piorou a Situação
Vamos reverter a lógica. Suponha que você seja um pentester. Como explorar essa vulnerabilidade? Simples: você não precisa invadir o servidor. Basta encontrar um endpoint que aceite requisições internas e cause amplificação. Um exemplo real: o WordPress usa wp-cron.php para agendamento. Se você injetar um comando que force execuções síncronas (via wp_remote_post para wp-cron.php?doing_wp_cron=1), pode saturar o servidor. Eu presenciei um caso em que um plugin de cache mal escrito gerava 500 requisições por segundo para o próprio servidor, derrubando um site com tráfego legítimo de 10 req/s.
A ironia é que as ferramentas de mitigação de DDoS tradicionais, como mod_evasive, falham nesse cenário. Elas são baseadas em frequência de requisições por IP. Mas se o IP for 127.0.0.1 ou localhost, o módulo ignora (padrão). O mesmo vale para firewalls: iptables rules que bloqueiam tráfego externo não se aplicam a loopback.
A Solução que Ninguém Ensina: Isolamento de Fluxo Interno
A única forma de evitar ataques síncronos de manufatura é tratar o tráfego interno como perigoso. Medidas práticas:
- Rate limiting em localhost: Configure limites de requisições para bibliotecas como
curloufile_get_contentsquando o destino for127.0.0.1. Use ferramentas comoiptablescom regras específicas para loopback:iptables -A INPUT -i lo -m limit --limit 100/s -j ACCEPT(e depois DROP). - Tokenização de tarefas: Tasks agendadas devem usar um token único e expirável para evitar chamadas repetitivas. Cada execução do cron job deve consumir um token do banco de dados, e se o token já foi usado, a tarefa é ignorada.
- Monitoramento de tráfego loopback: Ative logs de tráfego na interface lo. Ferramentas como
vnstatouiftoppodem mostrar picos anormais. No meu caso, o pico de 66 MB/s em lo era 10x maior que o normal, mas ninguém olhava.
Uma história que ilustra bem isso: em 2022, um cliente de e-commerce teve sua loja derrubada por 3 horas durante a Black Friday. O pico de tráfego chegou a 40 Gbps, e a Cloudflare ativou mitigação total. O problema? Um script de backup que sincronizava arquivos via rsync para o próprio servidor, usando um cron job a cada minuto. O rsync gerava tráfego de 1 GB por execução, e como o servidor estava ocupado com vendas, o buffer de rede encheu, causando perda de pacotes e retransmissões. O resultado: tráfego ampliado para 40 Gbps de saída. A Cloudflare viu o aumento de tráfego e interpretou como ataque, bloqueando o IP. O cliente só descobriu o problema depois de 3 horas, quando um engenheiro olhou os logs do rsync.
Manifesto Técnico: Repensando a Segurança de Servidores
O ataque síncrono de manufatura expõe uma lacuna fundamental na segurança de servidores: a confiança cega no tráfego interno. Precisamos adotar uma postura de “least privilege for loopback”. Isso significa:
- Não permitir que processos sem autenticação chamem endpoints críticos, mesmo via localhost.
- Implementar circuit breakers para requisições internas, com thresholds baseados em threads e memória.
- Usar namespaces de rede (containers) para isolar tarefas de manutenção do serviço principal. No Docker, por exemplo, coloque o cron em um container separado com sua própria interface loopback.
No meu caso, a solução foi mover o cron job para uma VPS separada, que fazia chamadas para o servidor principal via HTTPS com autenticação JWT. O rate limit foi configurado para 1 requisição por segundo. Funcionou.
Agora, quando vejo um pico de tráfego suspeito, minha primeira pergunta não é “Quem está me atacando?”, mas “O que eu estou fazendo comigo mesmo?”. Essa mudança de perspectiva é o que separa um sysadmin mediano de um especialista em resiliência.
E você, já verificou seus cron jobs hoje?