Recebi 260 Milhões de Requests em Um Dia. Meu Servidor Morreu.
O dia que um DDoS derrubou o Find My SaaS e eu descobri que minha infra era de papelão.
Eu falo de segurança toda semana nesse canal. Mostro breach de empresa bilionária. E quando o DDoS bateu na minha porta, eu tava com o escudo desligado.
TL;DR
💀 260 milhões de requests num único dia derrubaram meu servidor. Load average bateu 88 numa máquina de 2 cores.
🛡️ O Cloudflare tava na frente, mas o modo Under Attack tava desligado. O escudo existia e eu não tinha ligado.
🐛 O Traefik atualizou sozinho pra uma versão bugada que queimava 35% de CPU parado e vazava 4.7 GB de RAM em 40 minutos.
🔧 Servidor novo subiu do zero com filosofia invertida: firewall primeiro, serviço depois.
😰 A Negação: “não pode ser DDoS”
Eu tava na academia quando o celular vibrou com alerta de instabilidade. Segundos depois, o Alcy Jones me manda mensagem perguntando se o Find My SaaS tava fora do ar. Abri o YouTube e tinha gente comentando no último vídeo perguntando se eu tava sendo hackeado.
Larguei o treino, abri o SSH no celular. Nada. O servidor não respondia.
Cheguei em casa, sentei na frente do computador e comecei o debug. E aí começa o estágio da negação, paizão. Eu me recusava a aceitar que era DDoS. Tinha firewall configurado, Cloudflare na frente de todos os domínios, proxy certinho. Na minha cabeça era impossível. Devia ser um pico de tráfego, algum processo engasgado, qualquer coisa menos um ataque.
Consegui entrar no servidor e rodei um htop. Load average de 26 numa máquina de 2 cores. Oito processos de schedule:run rodando em paralelo porque nenhum terminava a tempo e o scheduler ficava spawnando novos. Matei tudo na mão. Load caiu pra 8. Respirei. Pensei: “resolvido”.
Não tava resolvido nem a pau.
Enquanto eu matava processo, o Coolify (que gerencia meus deploys) tinha atualizado o Traefik automaticamente. E a versão nova, a v3.6.16, veio com um bug lindo: 35% de CPU constante mesmo sem nenhuma conexão. Zero tráfego e o cara lá, queimando CPU igual minerador de Bitcoin. Num servidor de 2 cores, você tira 35% de capacidade e o resto dos serviços ficam se empurrando pelo que sobra. E além da CPU, o bagulho tinha um memory leak que chegou a 4.7 gigas de RAM em 40 minutos.
💥 A Pancada Real: 70 milhões de requests de uma vez
Rodei um ss -s pra ver as conexões TCP. O resultado me gelou.
34 mil conexões TCP no estado CLOSED. 2.400 orphaned. 30 mil sockets alocados no kernel. Isso não é tráfego legítimo. Isso é SYN flood puro.
Pra quem não sabe o que é SYN flood: imagina que o seu servidor é uma portaria de prédio. Cada request que chega é uma pessoa que toca o interfone e fala “oi, vim visitar”. O servidor abre a porta e espera a pessoa entrar. O SYN flood é 70 milhões de pessoas tocando o interfone ao mesmo tempo e ninguém entrando. O servidor fica lá, de porta aberta, esperando gente que nunca vai entrar, até travar tudo.
E aí vem o número que eu não tava preparado pra ver. 260 milhões de requests. Num único dia. Pra ter uma base, num dia normal de ataque o meu SaaS recebia entre 200 e 400 mil requests. Isso já era ataque. Só que nesse dia o cara mandou 70 milhões de uma vez. É como se nos outros dias o cara tivesse jogando pedrinha na minha janela e nesse dia chegou com um caminhão de entulho e descarregou na minha sala.
Load average bateu 88. O SSH parou de responder. Perdi o acesso ao servidor. O kernel provavelmente deu um watchdog porque não aguentou. A aplicação Rails do Find My SaaS atingiu o limite de file descriptors, que é o número máximo de arquivos e conexões que um processo pode abrir ao mesmo tempo. Entrou num loop de falha. Tentei docker restart. O container nem respondeu ao comando. Game over.
E eu ali pensando: o cara que tá me atacando gastou mais dinheiro provisionando esse DDoS do que eu recebo de faturamento no Find My SaaS no mês inteiro. Da próxima vez me faz um Pix que eu tiro do ar, mano. Sai mais barato pros dois.
🛡️ A Surpresa do Cloudflare: o escudo tava desligado
Eu tinha uma hipótese forte durante o debug inteiro: o IP real do meu servidor tinha vazado. Faz sentido, né? Se o atacante sabe o IP, ele manda o tráfego direto no servidor e ignora o Cloudflare. É tipo ter um segurança na porta do bar e o cara entrar pela janela dos fundos.
Fui olhar o dashboard do Cloudflare pra confirmar. E a resposta me quebrou.
Os ataques vieram pelo Cloudflare. Passaram por dentro do Cloudflare. O tráfego não foi direto no IP. E o modo Under Attack, que é literalmente a feature que o Cloudflare tem pra esse tipo de situação, tava desativado.
Ou seja: eu tinha o escudo, o escudo tava desligado, e eu não sabia.
O Traefik bugado recebia essas conexões do Cloudflare e distribuía pras aplicações. Com o bug de CPU e o memory leak, ele não conseguia processar nem o tráfego legítimo, quanto mais 70 milhões de requests maliciosas chegando de uma vez. O servidor virou uma panela de pressão sem válvula de escape.
E o plot twist final: tentei fazer downgrade do Traefik pra versão anterior. Não resolveu. A v3.3 também apresentou memory leak naquele setup. Tentei regra de firewall no DOCKER-USER. Insuficiente contra SYN flood. Tentei reiniciar o container. Tava tão travado com EMFILE que não respondia nem ao SIGTERM.
Decisão final: provisionar uma instância nova do zero. Começar de novo.
Às vezes a melhor engenharia é aceitar que o paciente morreu e reconstruir.
💡 E daí? (O Que Fazer Com Isso)
O servidor novo subiu com uma filosofia diferente: infraestrutura defensiva primeiro, serviço depois. Se você roda qualquer coisa numa VPS, seja com Coolify, seja com Docker puro, presta atenção nesse checklist:
Auto-update de proxy em produção, nunca mais. Trava a versão do Traefik. O Coolify por padrão atualiza o Traefik toda semana. Parece conveniente até o dia que uma versão bugada sobe sozinha e derruba tudo.
Under Attack mode do Cloudflare. Precisa estar ativado ou pelo menos configurado pra ativar automaticamente. Eu tinha o escudo e não tava usando.
IP novo. Se você tá atrás do Cloudflare mas o IP real do servidor aparece em algum registro DNS histórico, o atacante acha. Tem ferramenta que faz isso em segundos.
Limites de file descriptors nos containers. O default do Docker é baixo demais. Coloca 65 mil, soft e hard.
SYN cookies habilitados no kernel. Faz o kernel não alocar memória pra conexão TCP até o handshake terminar. Se o handshake nunca termina (que é exatamente o que SYN flood faz), a memória não é alocada.
Monitoramento. Eu não tinha alerta nenhum pra RAM do proxy, pra contagem de processos acumulados, pra sockets TCP. Se eu tivesse, teria visto o problema 20 minutos antes de perder o SSH.
Segurança não é o que você sabe. É o que você configura. E eu não tinha configurado o básico no meu próprio servidor.
🔗 Referências
Hostinger VPS com instalador Coolify [CUPOM: MANODEYVIN]
🎥 Assiste o vídeo completo
📍 Continua a resenha
Lives: terça e quinta, 10h da manhã (puro suco de chorume)
Instagram: @manodeyvin
X/Twitter: @manodeyvin
LinkedIn: linkedin.com/company/chorume
Você sabe se o IP real do seu servidor tá exposto? Já rodou um check? Porque se não rodou, pode ser que alguém já sabe e você é o último a descobrir. 👇