Sobrevivendo a um Ataque DDoS no Seu VPS

Há dois momentos em que as pessoas descobrem como a mitigação de DDoS realmente funciona. O primeiro é tranquilo, no momento da compra, ao ler uma lista de recursos que diz "proteção contra DDoS incluída" e presumir, sem pensar muito, que a frase cobre tudo. O segundo é às três da manhã, quando o site está fora do ar, os gráficos parecem errados de um jeito que não faz sentido, e aquela proteção incluída está — corretamente, e por design — sem fazer absolutamente nada.

Os dois momentos envolvem o mesmo produto e a mesma verdade: um provedor de hospedagem filtra os ataques que chegam como volume bruto, porque é ele quem é dono do link por onde esses pacotes trafegam, e você não. Ele não consegue filtrar os ataques que chegam como requisições de aparência comum, porque do ponto de vista da rede elas são requisições de aparência comum. Essa linha — entre a inundação que o seu host absorve e a inundação que você precisa sobreviver sozinho — é o assunto inteiro. Tudo o que vem a seguir é sobre descobrir de que lado dela você está, e o que fazer em cada um.

Dois ataques diferentes que compartilham um nome

"DDoS" é uma única palavra cobrindo dois problemas que não têm quase nada em comum além do resultado. Eles são interrompidos em lugares diferentes, por pessoas diferentes, com ferramentas diferentes, e confundi-los é o motivo de tanto esforço de mitigação cair na camada errada.

Leia as duas últimas linhas de novo, porque é nelas que está o ponto prático. Se a interface está saturada, nada que você digitar no servidor vai ajudar: os pacotes já consumiram a porta, e a única parte capaz de descartá-los é quem é dono do roteador a montante. Se a interface está tranquila mas o site continua fora do ar, o oposto é verdade — o seu host não vê nada de errado porque, na camada dele, nada está errado, e o conserto é inteiramente seu.

O que a "proteção contra DDoS incluída" realmente compra

A proteção em nível de rede é real, valiosa, e quase sempre mal interpretada. Quando um provedor anuncia filtragem L3/L4, quer dizer que a rede dele monitora o tráfego destinado ao seu endereço, e quando uma inundação é detectada, o tráfego é desviado por hardware de limpeza que descarta a parte maliciosa e encaminha o que parece legítimo. Isso acontece sem chamado de suporte, e geralmente sem que você perceba mais do que uma breve oscilação.

Essa única frase está fazendo muito trabalho, então vale a pena destrinchar o que ela cobre e o que não cobre:

• Ela cobre os ataques que você não sobreviveria sozinho. Uma inundação de amplificação de 200 Gbps contra um servidor com uma porta de 1 Gbps não é um problema de configuração. É aritmética. A limpeza a montante é a única resposta que existe.
• Ela é alheia ao estado da sua aplicação. O filtro não sabe quais das suas URLs são caras, quais visitantes estão logados, ou que uma requisição ao seu endpoint de busca custa quatrocentas vezes uma requisição ao seu logo.
• Ela reage a um limiar, não ao seu sofrimento. A detecção é disparada pelo volume de tráfego. Um ataque que nunca ultrapassa o limiar nunca a dispara, não importa o quão completamente ele tenha derrubado o seu site.
• Ela pode fazer um null-route breve em casos extremos. Toda rede tem um teto. Se um ataque ameaça a infraestrutura compartilhada, o endereço pode ser descartado por um período — isso é padrão, universal, e vale a pena saber antes de acontecer, não durante.

Primeiro, decida se isto é mesmo um ataque

Uma fração impressionante dos incidentes suspeitos de DDoS é outra coisa vestindo essa fantasia, e os consertos não são intercambiáveis. Antes de limitar a taxa de qualquer coisa, gaste dois minutos descartando os impostores — um diagnóstico errado aqui custa uma hora e, ocasionalmente, os seus usuários de verdade.

• Você ficou popular. Um link em um grande agregador produz um formato de tráfego que parece exatamente uma inundação de camada 7, exceto que os referrers são reais e as requisições são por páginas que um humano gostaria de ver. É um problema de capacidade com uma causa feliz; limitar a taxa disso é se autoprejudicar.
• Um crawler perdeu as boas maneiras. Scrapers agressivos e bots de treinamento de IA conseguem facilmente superar um servidor pequeno. O user-agent geralmente confessa, e o conserto é robots.txt mais um limite direcionado, não um geral.
• Você quebrou alguma coisa. Uma implantação que desativou o cache, um cron job fora de controle, um banco de dados que perdeu um índice — tudo isso se apresenta como "carga repentina, sem causa óbvia". Se o momento coincide com uma mudança que você fez, acredite na mudança.
• O seu próprio monitoramento é a inundação. Raro, embaraçoso, e muito mais comum do que qualquer um admite. Um loop de health-check que tenta de novo sem backoff pode gerar uma taxa de requisições genuinamente impressionante.

A pergunta que separa um caso do outro é simples: o tráfego quer alguma coisa? Carga real — mesmo carga real de aparência hostil — tem um formato. Ela atinge páginas que existem, segue links, carrega os assets, e vem de uma distribuição plausível de redes. Um ataque geralmente nem se dá ao trabalho.

Lendo o ataque a partir do próprio servidor

Você não precisa de um painel para classificar o que está acontecendo. Quatro comandos, executados em ordem, dizem em menos de um minuto em qual camada você está lutando — e saber isso determina tudo o que você faz a seguir.

O link está cheio? Observe os contadores da interface. Se o throughput está preso perto do teto da porta, você está em um ataque volumétrico, e o seu trabalho é abrir um chamado, não mudar uma configuração:

• vnstat -tr 10 — throughput médio ao longo de dez segundos, a leitura honesta mais rápida sobre saturação.
• cat /proc/net/dev duas vezes, com um segundo de intervalo — deltas de pacotes e bytes por interface, sem precisar de ferramenta nenhuma.

É um SYN flood? Conexões meio abertas se acumulam em SYN-RECV. Um punhado é normal; milhares não é:

• ss -s — a linha de resumo, contagens de conexões por estado em uma olhada.
• ss -tn state syn-recv | wc -l — o número específico que importa.

É camada 7? Se a largura de banda não chama atenção mas tudo está lento, conte as requisições por cliente no seu access log. Um único endereço com dezenas de milhares de acessos é amador; cem mil endereços com três acessos cada é a coisa real:

• tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30
• Troque $1 por $7 para classificar os caminhos requisitados em vez disso. Se um endpoint caro domina, você encontrou o alvo e metade do conserto.

O que está realmente esgotado? A load average por si só diz pouco. Procure o teto específico que você atingiu: todos os children do PHP-FPM ocupados, conexões de banco de dados no limite, descritores de arquivo esgotados, ou workers presos em estado D esperando o disco. Esse teto — não o tráfego — é o que derrubou o site, e aumentá-lo costuma ser mais rápido do que filtrar qualquer coisa.

Os primeiros dez minutos

Sob pressão, as pessoas recorrem à maior alavanca disponível, e a maior alavanca geralmente é a errada. Esta é a ordem que limita o dano, começando, a grosso modo, pela opção mais rápida e mais segura:

1. Classifique antes de agir. Interface saturada significa volumétrico; interface tranquila com workers ocupados significa camada 7. Trinta segundos gastos aqui evitam que você conserte a camada errada durante uma hora.
2. Se for volumétrico, abra um chamado imediatamente e inclua o endereço de destino, o horário de início, e os seus contadores de interface. Depois pare de digitar no servidor — você não consegue consertar isso de dentro dele.
3. Se for camada 7, faça cache primeiro. Ativar cache agressivo de página inteira para visitantes anônimos é a forma mais rápida de converter uma indisponibilidade em um detalhe sem importância, e é a única medida que também ajuda contra tráfego real.
4. Depois limite a taxa — primeiro o endpoint visado, o resto depois. Comece conservador. Um limite que derruba os seus próprios usuários é uma continuação autoinfligida do ataque.
5. Bloqueie só o que for inequívoco. Uma dúzia de endereços com cem mil requisições cada, um user-agent obviamente falso, um país onde você não tem usuários. Resista ao impulso de escrever regras elaboradas debaixo de fogo; você não vai lembrar delas no mês que vem.
6. Descarte carga deliberadamente se precisar. Servir uma página estática de "em manutenção" para visitantes não autenticados mantém a máquina viva, mantém a sua API no ar, e compra tempo para pensar. Decidir o que sacrificar é melhor do que deixar que decidam por você.
7. Anote o que você fez. Toda regra temporária que você adicionou é uma mina terrestre para o seu eu futuro. As regras que ajudaram se tornam permanentes; o resto sai amanhã.

Limites de taxa que seguram, e o erro que todo mundo comete

A limitação de taxa é o instrumento principal para a camada 7, e o nginx faz isso bem, com duas diretivas que resolvem dois problemas genuinamente diferentes. limit_req limita a taxa de requisições — com que frequência um cliente pode pedir. limit_conn limita a concorrência — quantas conexões um cliente pode manter abertas ao mesmo tempo. Inundações precisam do primeiro; ataques slow-loris, que mantêm milhares de conexões quase ociosas para esgotar o seu pool de workers, precisam do segundo. Implante só um e você está coberto contra metade do problema.

Três detalhes separam um limite que funciona de um que é decorativo:

• Use um burst, e use nodelay. Navegadores reais vêm em rajadas — a visualização de uma única página dispara uma dezena de requisições de assets quase simultâneas. Um limite sem folga estrangula visitantes genuínos enquanto um atacante que se controla bem abaixo do limiar passa direto.
• Limite os endpoints caros separadamente. A sua página de busca, o formulário de login, a redefinição de senha e qualquer endpoint que escreve no banco de dados merecem um orçamento muito mais apertado do que os seus assets estáticos. Atacantes encontram esses endpoints sem esforço, porque são os que doem.
• Devolva 429, não 503. O código de status é um sinal para clientes bem-comportados e para os mecanismos de busca de que isto é limitação, não falha — e evita que uma tarde ruim vire um problema de ranqueamento.

Cache é a mitigação mais barata que você vai implantar

Um limite de taxa rejeita trabalho. Um cache faz o trabalho deixar de existir. Para tudo o que um visitante anônimo vê, o cache de página inteira muda a economia do ataque inteiro: uma requisição que custaria uma ida e volta ao banco de dados, a renderização de um template e um worker de PHP vira uma leitura de arquivo medida em microssegundos. O mesmo servidor que travava com quatrocentas requisições dinâmicas por segundo vai servir dezenas de milhares de requisições em cache sem nem perceber.

O que importa quando você ativa isso com urgência:

• Cache só para visitantes anônimos. Faça bypass com base em um cookie de sessão. Servir a página de um usuário logado para outro é um incidente muito pior do que a indisponibilidade que você estava consertando.
• Sirva conteúdo obsoleto de propósito. O proxy_cache_use_stale do nginx com updating error timeout faz com que, quando o seu backend está com dificuldade, os visitantes recebam uma página um pouco desatualizada em vez de um erro. Durante um ataque, isso é a diferença entre um site que parece bem e um que parece morto.
• Colapse misses duplicados. O proxy_cache_lock garante que mil requisições simultâneas pela mesma página sem cache produzam uma única requisição ao backend, não mil. Sem isso, um ataque que quebra o cache passa direto por ele e chega ao seu banco de dados com força total.
• Neutralize query strings que quebram o cache. O truque padrão é acrescentar um ? e um valor aleatório para que toda requisição seja uma chave única e sempre dê miss. Normalize a sua chave de cache para ignorar parâmetros de query que a sua aplicação não usa de verdade.

Existe uma assimetria agradável aqui que vale a pena internalizar: toda hora que você gasta em cache também deixa o site mais rápido no seu melhor dia, mais barato de rodar, e melhor em sobreviver ao próprio sucesso. Quase nenhuma outra linha de defesa paga um dividendo quando nada está errado.

Os tetos que decidem se você vai cair

A maioria dos servidores não morre porque ficou sem CPU. Eles morrem porque bateram em um teto invisível que ninguém definiu de propósito — um padrão de uma década atrás que fazia sentido em hardware que ninguém mais usa. Sob ataque, é isto que costuma quebrar primeiro:

• Workers da aplicação. O pm.max_children do PHP-FPM, a sua contagem de workers Python, o tamanho do seu cluster Node. Esse é o verdadeiro limite de concorrência do seu site. Quando todos estão ocupados, todo visitante adicional entra na fila, e o site fica fora do ar independente do quão ociosa a CPU pareça. Aumente só até onde a memória permitir — fazer swap é pior do que enfileirar.
• A fila de accept. O net.core.somaxconn e o seu listen backlog decidem quantas conexões podem esperar para ser aceitas. Um backlog pequeno transforma uma rajada sobrevivível em conexões recusadas.
• SYN cookies. O net.ipv4.tcp_syncookies permite que o kernel responda a um SYN flood sem alocar estado para conexões que nunca vão se completar. Kernels modernos ativam isso por padrão; verifique em vez de presumir, porque não custa nada e evita a inundação mais comum que existe.
• Descritores de arquivo. Toda conexão é um descritor. O limite padrão de nofile costuma ser mais baixo do que o número de conexões que você está tentando servir, e o modo de falha — accepts falhando enquanto tudo parece saudável — é genuinamente confuso às três da manhã.
• Conexões de banco de dados. Aumentar a contagem de workers sem aumentar o pool de conexões só move a fila para um lugar mais difícil de ver. Esses dois números precisam ser ajustados juntos.

Ajuste isso em um dia tranquilo, não durante um incidente. A vantagem de conhecê-los é que, quando o site cai, você consegue nomear o teto que ele atingiu em vez de adivinhar — e um teto nomeado é um teto resolvido.

Colocando algo na frente da origem

Tudo o que foi dito até aqui acontece no servidor. O próximo passo é decidir se o servidor deve sequer ser a coisa que recebe o tráfego diretamente. Existem três opções honestas, e a resposta certa depende muito mais do que você hospeda do que do que você pode pagar.

O nó frontal autogerenciado merece mais atenção do que costuma receber, particularmente para quem escolheu hospedagem offshore por motivos com os quais um grande CDN talvez não simpatize. O padrão não tem nada de glamouroso: nós de proxy baratos na frente, origem protegida por firewall para aceitar conexões apenas desses nós, DNS apontando para as frentes. Se uma frente é atacada, você a substitui por um endereço novo em minutos e a origem nem percebe. A versão completa dessa arquitetura — incluindo as seis formas pelas quais um endereço de origem vaza de qualquer jeito — é o tema do nosso guia sobre ocultar o IP do servidor de origem.

Uma origem oculta vale mais do que qualquer filtro

Vale a pena dizer isso sem rodeios, porque inverte a prioridade habitual: a mitigação de DDoS mais barata disponível para você é um endereço que o atacante não tem. Filtrar é o que você faz quando isso já falhou.

Isso importa mais do que parece, porque endereços de origem vazam constantemente e silenciosamente. Registros de DNS históricos de antes de você colocar um proxy na frente sobrevivem à mudança por anos. E-mails enviados diretamente pela aplicação carregam o endereço nos seus cabeçalhos. Um certificado TLS emitido para o endereço bruto é publicado permanentemente em logs de certificate transparency. Uma página de erro, um redirecionamento, ou um subdomínio obscuro que nunca passou pelo proxy — todos entregam o endereço. Se você colocou um CDN na frente de um servidor que costumava ficar exposto, presuma que o endereço antigo é conhecido até que você o tenha trocado.

Escolhendo hardware e localização para que ataques continuem sendo chatos

Parte disso é decidida antes mesmo de um ataque acontecer, no momento em que você escolhe um plano. Três propriedades importam muito mais do que a ficha técnica sugere:

• Largura de banda ilimitada. Em um plano medido, um ataque não é só uma indisponibilidade — é uma fatura. Tráfego que você nunca pediu e não conseguiu recusar ainda assim conta contra uma franquia. Transferência ilimitada converte um risco financeiro em um risco puramente técnico, o que é uma classe de problema muito melhor.
• Se a porta é só sua. Em um host virtualizado compartilhado, um vizinho sob ataque pode degradar você, e o seu próprio teto de proteção é compartilhado. Hardware dedicado com porta própria elimina os dois efeitos. Para um projeto que espera atenção hostil, esse é o motivo mais claro para subir de um VPS — mais do que núcleos ou RAM.
• Onde a rede fica. Uma rede europeia bem conectada, com capacidade de trânsito real, absorve uma inundação que uma rede mal peerada não absorve, e a jurisdição que você escolheu por motivos legais também tem características de rede. Vale a pena checar as duas coisas ao escolher entre as localizações disponíveis.

Também existe um argumento de escala que silenciosamente favorece a simplicidade. Um site estático atrás de um cache em um servidor modesto é extraordinariamente difícil de derrubar; o mesmo conteúdo em um CMS pesado com um endpoint de busca sem cache pode ser quebrado por uma única pessoa determinada com um script. Reduzir o que é dinâmico é uma mitigação, e é de graça. Se o seu projeto realmente vive sob carga sustentada, as nossas notas sobre hospedagem de alto tráfego cobrem o lado do dimensionamento da mesma questão.

Cinco coisas para não fazer

Os modos de falha aqui são consistentes o bastante para listar, e cada um já custou um fim de semana de alguém:

• Não faça null-route de si mesmo. Colocar o próprio endereço em blackhole encerra o ataque da forma mais literal possível — ninguém consegue chegar até você, incluindo os seus usuários. É um recurso de último caso para o seu provedor, não uma ação que você toma voluntariamente.
• Não trate o fail2ban como proteção contra DDoS. É uma ótima ferramenta contra tentativas de força bruta vindas de poucos endereços. Contra uma inundação distribuída, ele reage em minutos a algo que chega em segundos, e uma regra que bane milhares de endereços pode custar mais em processamento de firewall do que o ataque custou a você.
• Não pague resgate. A esmagadora maioria dos e-mails de extorsão ameaçando um ataque devastador vem de gente sem capacidade nenhuma, que envia milhares de mensagens idênticas. A pequena minoria que consegue cumprir a ameaça vai voltar, porque você provou que paga.
• Não revide. Além de ser ilegal em praticamente todo lugar, as origens são terceiros comprometidos. Você estaria atacando vítimas, e fazendo isso a partir de um endereço que é inequivocamente seu.
• Não migre em pânico. Trocar de host no meio de um ataque significa que o endereço novo fica público em minutos e você não tem nenhuma configuração funcionando. Estabilize primeiro, mude deliberadamente depois — e se for mudar, o nosso guia sobre migrar sem downtime existe exatamente para que a mudança não seja um segundo incidente.

A versão curta

Sem o raciocínio, o modelo prático cabe em oito linhas:

1. Classifique primeiro. Interface saturada significa volumétrico e pertence ao seu host. Interface tranquila com workers esgotados significa camada 7 e pertence a você.
2. Para volumétrico, abra um chamado com o endereço, o horário e os seus contadores — depois pare de mexer no servidor.
3. Faça cache agressivo para visitantes anônimos, sirva conteúdo obsoleto sob estresse, e colapse misses duplicados. Essa é a mudança de maior alavancagem que você pode fazer.
4. Limite a taxa por requisição e por concorrência, mais apertado nos endpoints que custam mais, e devolva 429.
5. Corrija a sua configuração de IP real antes de tudo isso, ou todo limite por cliente atrás de um proxy é inútil ou catastrófico.
6. Conheça os seus tetos — workers, backlog, descritores, conexões de banco de dados — e aumente-os deliberadamente em um dia tranquilo.
7. Mantenha o endereço de origem secreto e protegido por firewall só para os seus nós frontais. Isso vale mais do que todo filtro combinado.
8. Compre largura de banda ilimitada para que o tráfego que você não pediu nunca seja também uma fatura.

Nada disso torna você imune, e quem vende imunidade está vendendo outra coisa. O que isso faz é tirar você da população que é derrubada por um adolescente entediado e colocar você na que exige recursos genuínos e intenção genuína para incomodar — o que, para a esmagadora maioria dos projetos, é indistinguível de estar seguro. O resto é o mesmo trabalho nada glamouroso que torna um servidor bom em tudo o mais: com hardening desde o primeiro dia, restaurável no pior deles, e rodando em algum lugar que trata o seu tráfego como o seu próprio negócio.