Proteção contra DDoS: defesa em camadas

Um ataque de negação de serviço distribuída não tenta levar dados: tenta tornar o serviço indisponível, esgotando o recurso que se esgotar primeiro — largura de banda, tabela de ligações, processador ou ligações à base de dados.

Por isso, a resposta honesta a «como me protejo de um ataque DDoS» nunca é um único produto nem uma regra de firewall. Ataques diferentes esgotam recursos diferentes, e cada camada cobre uma falha diferente. O que se segue respeita a ordem em que as camadas travam um ataque; no fim há um plano para quando ele já está a decorrer.

O que um ataque DDoS esgota na realidade

Família	Exemplos	O que satura	Onde tem de ser travado
Volumétrico	Inundações UDP, amplificação DNS e NTP, varrimento de intervalos	A ligação de rede	A montante, pelo alojamento ou por uma rede de limpeza
Protocolo e esgotamento de estado	Inundações SYN e ACK, inundações de ligações	Tabelas de ligações em servidores, firewalls e balanceadores	Limites no perímetro, ajuste do kernel e SYN cookies
Camada de aplicação (L7)	Inundações HTTP, cache busting, slowloris, abuso de API	Processador, processos e ligações à base de dados	CDN e WAF, cache e limites por rota

A consequência é incómoda: se o ataque for maior do que a sua ligação, nada do que configurar no servidor resolve — quando uma regra local vê os pacotes, o ataque já ganhou. A mitigação volumétrica tem de viver a montante; o resto pode ser endurecido por si.

Camada 1: mitigação a montante, com CDN e anycast

Toda a defesa séria começa em capacidade que não é sua: uma rede de limpeza na cloud ou uma rede anycast distribui o ataque por dezenas de localizações e encaminha ao servidor só os pedidos legítimos.

Coloque o tráfego público atrás de uma CDN ou de um proxy inverso com mitigação incluída (Cloudflare, AWS CloudFront com Shield, Azure Front Door, Gcore, Bunny ou Fastly).
Pergunte ao alojamento quanta capacidade de mitigação existe à frente do seu IP e se está sempre ativa ou só arranca na deteção. A proteção a pedido deixa um buraco no minuto em que o ataque começa.
Prefira anycast: dilui as inundações volumétricas pela geografia, em vez de pedir a um único centro de dados que as absorva.

O erro mais comum é acreditar que a CDN, sozinha, chega. É a primeira de nove camadas.

Camada 2: fechar o IP de origem

É o passo que a maioria das equipas salta e o que desfaz silenciosamente a camada anterior. Se o atacante descobrir o IP real do servidor, contorna a CDN e ataca a origem — a técnica chama-se direct-to-origin (D2O).

Por onde escapam os IP de origem:

Histórico de DNS — registos A antigos, de antes de o site passar para o proxy.
Registos de transparência de certificados — certificados TLS emitidos para o nome do servidor de origem.
Subdomínios — mail., vpn., ftp. e dev. apontam muitas vezes para a mesma máquina.
Cabeçalhos de correio — a correspondência enviada pode levar o IP de origem nas linhas Received.
Registos antigos — MX, SPF e TXT a apontar para infraestrutura fora da CDN.

O que fazer: rodar o IP de origem depois de a CDN estar ativa, fechar a firewall da origem aos intervalos publicados pela CDN nas portas 80 e 443 e rever a exposição de três em três meses.

Camada 3: uma WAF para a camada 7

Uma firewall de rede vê uma ligação TCP válida e deixa-a passar; uma WAF lê o pedido HTTP, onde vive o ataque à camada de aplicação — pedidos malformados, exploração de vulnerabilidades e bots contra o início de sessão e a pesquisa.

Ative primeiro as regras geridas — OWASP e informação de ameaças do fornecedor — e só depois regras próprias: bloquear corpos de pedido excessivos nos carregamentos de ficheiros, desafiar pedidos a caminhos de administração e limitar por rota, não por site.

Camada 4: limites de pedidos em todos os níveis

A limitação de pedidos é o controlo com melhor relação entre custo e resultado e o mais mal configurado. Regras só no servidor web não travam tráfego que satura a rede primeiro; regras por IP valem pouco contra uma botnet com milhares de origens.

No perímetro: pedidos por IP, por ASN e, quando fizer sentido, por país.
Na aplicação: por sessão, por chave de API e por utilizador autenticado.
Por rota: limites apertados no início de sessão, na recuperação de palavra-passe, na pesquisa e no pagamento — as rotas caras que os atacantes escolhem.

Use limites de token bucket ou janela deslizante em vez de tetos fixos por segundo e devolva o código 429 com Retry-After, para que os clientes legítimos recuem.

Camada 5: endurecer a pilha TCP

As inundações SYN enchem a tabela de ligações antes de chegar sequer um pedido HTTP. As correções são antigas, aborrecidas e eficazes:

Ativar SYN cookies.
Aumentar a fila de escuta e ajustar somaxconn e tcp_max_syn_backlog à concorrência real.
Reduzir tcp_fin_timeout e encurtar os tempos de keepalive nos balanceadores.
Limitar no perímetro as ligações simultâneas por origem.

Meça antes de mexer: copiar valores sem medir a sua linha de base costuma piorar o desempenho.

Camada 6: deixar a cache trabalhar

Um pedido servido a partir da cache nunca chega à origem nem consome um processo ou uma ligação à base de dados. O que puder ser estático deve ser estático: imagens, CSS, JavaScript e o HTML visto por utilizadores anónimos.

Dois detalhes contam durante um ataque:

O cache busting é uma técnica de ataque. Consultas aleatórias forçam todos os pedidos a ir à origem; configure a CDN para ignorar parâmetros irrelevantes nas rotas guardáveis.
A taxa de acerto da cache é uma métrica de segurança. Se cair de 85% para 20% durante um incidente, está a pagar custo de origem por tráfego de ataque.

Camada 7: medir uma linha de base e alertar sobre desvios

Não se defende o que não se vê. Antes do ataque, registe o normal: pedidos por segundo, bytes de entrada e saída, erros 4xx e 5xx, latência no percentil 95, ligações e URLs mais pedidos.

Alerte sobre desvios, não sobre absolutos: cinco vezes mais pedidos com erros estáveis é muitas vezes uma campanha de marketing; pedidos estáveis com latência e ligações a subir apontam para esgotamento de estado. NetFlow ou IPFIX e os registos da aplicação dão as duas leituras.

Camada 8: escrever o plano de resposta antes de precisar dele

Debaixo de ataque é a pior altura para decidir quem liga ao alojamento, quem fala com os clientes e quem pode ativar o modo «sob ataque». Escreva um plano de resposta de uma página:

Quem declara o incidente e onde o anuncia.
Quem contacta o alojamento ou o suporte da CDN, com os números de conta à mão.
Que controlos são ativados, por que ordem, e quem os pode ativar.
Quem comunica com os clientes e qual é o texto de resposta inicial.
Quando se acionam vias legais ou policiais, sobretudo em casos de extorsão.

Ensaie-o uma vez por trimestre, com um exercício de mesa. Um plano que ninguém leu é decoração.

Camada 9: contratar capacidade, não esperança

Onde a indisponibilidade custa receita, a capacidade de mitigação deve estar no contrato: SLA de limpeza, limiar de limpeza definido, contactos de escalonamento com nome e um nível de suporte que responde durante o ataque.

Os planos gratuitos servem sites pequenos; quem perde milhares de euros por hora de paragem precisa de um nível acima.

Se está sob ataque neste momento

Trabalhe por esta ordem, da medida menos invasiva para a mais invasiva:

Confirme que é um ataque. Veja origens, padrão de pedidos, URLs mais pedidos e geografia; compare com uma campanha legítima antes de bloquear.
Identifique a camada. Largura de banda saturada aponta para montante; tabela de ligações cheia aponta para L3 e L4; processador e latência em rotas específicas, para L7.
Abra um ticket no fornecedor de imediato. A mitigação a montante demora a ativar-se: peça-a antes de acabar o diagnóstico.
Ative os controlos do perímetro. Modo «sob ataque», regras geridas da WAF, limites apertados e desafio em JavaScript nas rotas mais abusadas.
Proteja a origem. Confirme que só a CDN entra e bloqueie pedidos diretos ao endereço IP.
Comunique. Primeiro a página de estado, depois os canais de suporte. O silêncio faz mais estragos do que o ataque.
Preserve prova. Guarde registos, capturas de pacotes e datas com hora: contam para o fornecedor, para o seguro e para o seguimento legal.

Se o ataque vier com uma exigência de pagamento para parar, não negocie nos termos do atacante: guarde as mensagens e envolva a autoridade competente. Em Portugal, a sabotagem informática é crime previsto na Lei n.º 109/2009, com os danos enquadráveis nos artigos 193.º e 194.º do Código Penal. Havendo dados pessoais em risco, o RGPD obriga a notificar a CNPD no prazo de 72 horas.

Lista de verificação de 10 minutos

O tráfego público passa por uma CDN ou serviço de limpeza com mitigação DDoS.
O IP de origem foi rodado, fechado aos intervalos do fornecedor e não é descobrível por histórico de DNS nem por certificados.
A WAF está ativa, com regras geridas e regras próprias para administração e início de sessão.
Existem limites de pedidos no perímetro, na aplicação e nas rotas caras.
As SYN cookies estão ligadas e os limites de ligações afinados com uma linha de base medida.
Os ficheiros estáticos e o HTML anónimo são servidos com taxa de acerto elevada.
Os painéis e alertas cobrem pedidos por segundo, largura de banda, erros, latência e ligações.
Existe um plano de incidente de uma página, atualizado e com responsáveis nomeados.
O contrato de alojamento ou CDN especifica capacidade de mitigação e resposta do suporte.
Alguém correu esta lista no último trimestre.

Cada caixa vazia justifica uma avaliação externa: testar o caminho que o ataque percorreria, do perímetro ao comportamento da aplicação, e dizer o que falha primeiro.

Quanto custa, na prática, a proteção contra DDoS

Opção	Custo típico	Adequada a
Nível gratuito ou Pro de CDN (Cloudflare, Bunny)	0 a 25 USD por mês	Blogues, sites de pequenas empresas, SaaS de baixo risco
Proteção do fornecedor de cloud (AWS Shield Standard)	Incluída na infraestrutura	Cargas de trabalho que já correm nessa cloud
WAF e DDoS geridos (Gcore, Imperva, AWS Shield Advanced)	Cerca de 55 a 3 000 USD por mês	Aplicações críticas para a receita, necessidades de conformidade
Limpeza dedicada (Akamai, Radware, Link11, Myra)	Contratos empresariais, muitas vezes acima de 5 000 USD por mês	Alvos de elevado valor, videojogos, finanças

O número que importa não é o da subscrição: é o custo de uma hora de paragem vezes a frequência com que espera ser visado. Para a maioria das pequenas empresas, uma configuração de nível baixo bem feita, com um plano ensaiado, vale mais do que um equipamento caro que ninguém sabe operar.

Erros comuns que mantêm os sites em baixo

Bloquear os intervalos de IP da própria CDN. Parece eficiente durante o ataque e deixa o site inacessível.
Limites apenas por IP. As botnets rodam endereços de origem; limite também por comportamento.
Proteger a página inicial e esquecer a API. Os atacantes acham depressa a rota mais cara.
Ignorar L3 e L4. Uma inundação SYN nunca aparece nos registos HTTP.
Sem proteção da origem. A CDN absorve a inundação enquanto o atacante martela o IP real.
Plano por testar. Sob pressão, as pessoas começam sempre pela ação errada.

Perguntas frequentes

É possível evitar por completo um ataque DDoS?

Não. Qualquer pessoa pode enviar tráfego para um serviço público. O objetivo realista é absorver e filtrar esse tráfego mantendo os utilizadores legítimos online, e é isso que a defesa em camadas faz. Nenhuma configuração garante disponibilidade permanente.

Uma CDN chega para travar um ataque DDoS?

Uma CDN trata das inundações volumétricas e de muito abuso na camada 7, mas não resolve a exposição da origem, o abuso de rotas caras na aplicação nem o esgotamento de estado. É uma camada, não a defesa inteira.

Como distingo um ataque DDoS de um pico de tráfego?

Olhe para a composição, não para o volume: um pico de uma só geografia ou de um único URL, com clientes invulgares, latência a subir e conversão parada, é um ataque. Um pico distribuído pelas fontes habituais costuma ser uma campanha a resultar.

O que deve uma pequena empresa fazer primeiro?

Colocar o tráfego atrás de uma CDN com mitigação, fechar o IP de origem, ativar as regras geridas da WAF e escrever o plano de uma página. Esta ordem cobre os ataques mais comuns com o menor custo.

Preciso de um fornecedor dedicado de DDoS?

Só se a indisponibilidade custar mais do que o contrato. Comece pelo nível de CDN, meça a exposição real e suba de nível quando a conta o justificar.

Por onde continuar

A defesa em camadas é sobretudo higiene de configuração: capacidade a montante, uma origem que ninguém encontra, controlos de pedidos ajustados à aplicação e um plano ensaiado. Cruze esta lista com os dez sinais de que a sua empresa foi comprometida para os indicadores de deteção e com as estatísticas do panorama de cibersegurança para dimensionar o risco do setor. Se já houve pedido de resgate, veja o que muda com o ransomware como serviço.