O que é um ataque DDoS e como proteger um site

O que é um ataque DDoS e por que é perigoso para um site

Um ataque DDoS é uma inundação maciça de solicitações que sobrecarrega um site, servidor ou conexão de rede. Um visitante não causará problemas. 10.000 solicitações por segundo é uma história muito diferente.

A ideia é simples: o atacante não “invade” o site diretamente, mas o sobrecarrega até que não consiga lidar, e às vezes o alvo é a página inicial, às vezes a API, às vezes o formulário de login. Também acontece que um serviço específico é atacado e todo o site fica fora do ar porque compartilha um banco de dados ou um único servidor sem separação de carga.

As consequências aparecem rapidamente. As páginas carregam lentamente, o carrinho de compras para de funcionar, o painel da conta do usuário gera erros, o bot de busca recebe respostas 5xx, e os usuários vão para um concorrente. O dano reputacional muitas vezes dura mais do que o próprio ataque, especialmente se o site ficou indisponível por 20 a 30 minutos durante o horário comercial.

Um ataque DDoS é perigoso não apenas por causa do tempo de inatividade, mas também aumenta os custos de infraestrutura, aciona alertas de análise falsos e faz com que o suporte perca solicitações reais de clientes. Se o site vende serviços, cada hora de inatividade prejudica leads e consultas, e se é mídia ou SaaS, o consumo regular de conteúdo e a confiança no produto sofrem.

Proteção DDoS para um site: quais métodos realmente funcionam

Não existe um único botão para proteção contra DDoS. Uma configuração funcional quase sempre combina várias camadas: CDN, WAF, limitação de taxa, filtragem de tráfego, Anycast e restrições do lado do host. Se você está interessado em proteção prática de sites contra ataques DDoS, também vale a pena olhar o material sobre segurança do site, porque DDoS é quase sempre acompanhado por outros ataques.

Uma CDN ajuda a distribuir solicitações entre nós e alivia parte da carga do servidor de origem. Isso é especialmente perceptível para páginas estáticas e mídia: em vez de um servidor, o tráfego encontra uma rede de pontos de presença, e o anycast funciona de maneira semelhante, mas foca no roteamento — a solicitação vai para o nó mais próximo. Para um grande projeto, isso não é um luxo, mas uma forma de evitar ficar fora do ar devido a um pico local.

Um WAF filtra padrões de solicitações suspeitas. Ele não protege contra tudo, mas faz um bom trabalho ao eliminar parte do tráfego indesejado e bots. A limitação de taxa restringe com que frequência as solicitações podem vir de um IP, sub-rede ou sessão. Quando um ataque vem na forma de milhares de solicitações idênticas para um formulário, os limites rapidamente começam a ajudar.

A filtragem de tráfego do lado do provedor ou do host é importante quando a linha de conexão está saturada antes que a solicitação chegue ao seu servidor. É aqui que vale a pena perguntar com antecedência quais mecanismos a plataforma possui: um centro de limpeza, roteamento de buraco negro, redirecionamento temporário e suporte sem um plano de incidente pronto muitas vezes responde muito lentamente durante um ataque.

A proteção no nível de hospedagem e provedor é necessária não como uma opção de backup, mas como a primeira camada de resposta, e um servidor pode ser reforçado, mas se o provedor em si não consegue cortar o tráfego indesejado, o recurso ainda ficará fora do ar. Em um projeto real, a configuração usual é uma combinação: CDN na frente, WAF na entrada, limites de solicitações e hospedagem que mantém a infraestrutura operacional.

Como proteger um site de DDoS antes que um ataque comece

A preparação começa com a arquitetura. Se o site vive em um único servidor, sem cache e sem separação de funções, é mais fácil derrubá-lo. É melhor separar a camada web, o banco de dados e tarefas pesadas em segundo plano imediatamente, e bloquear a área administrativa por IP ou VPN. Para projetos com maior risco, é útil olhar para abordagens do estudo de caso S4M — infraestrutura de rede privada: VPN e proxies.

O primeiro passo é remover pontos de entrada desnecessários, e um painel de administração aberto, SSH desprotegido, subdomínios de teste extras e métodos de API antigos apenas ampliam a superfície de ataque. Se o formulário de busca e o formulário de login estiverem disponíveis sem restrições, essas são as primeiras coisas que os atacantes vão atingir.

O segundo passo é planejar um cenário de fallback. Você precisa de um plano para quando o servidor principal ficar indisponível: um espaço reservado estático, DNS de backup, o contato do provedor e a pessoa responsável pela troca. Tal plano não ocupa muito espaço na documentação, mas economiza horas assim que o tráfego começa a chegar em ondas.

O terceiro passo é monitoramento. Você precisa de métricas para RPS, CPU, RAM, tempo de resposta, o número de erros 5xx e anomalias por país ou IP, e se o site de repente receber 5.000 solicitações para a página de login em 3 minutos, isso é imediatamente visível. Sem monitoramento, um ataque muitas vezes parece apenas que 'algo está lento'.

O quarto passo é fortalecer o servidor. CPU e memória extras não vão parar DDoS, mas vão comprar tempo para ativar a proteção e evitar a perda de dados. É uma boa ideia verificar os limites do PHP-FPM, tamanhos de fila, configurações de proxy reverso e timeouts de conexão com antecedência. Um timeout errado pode transformar um pico curto em uma longa interrupção.

O quinto passo é caching. Páginas que podem ser servidas sem acessar o banco de dados devem ser armazenadas em cache, e isso reduz o número de operações caras e ajuda a suportar carga semelhante a ataques de bots. O cache não resolve o problema, mas suaviza o impacto.

Sinais de um ataque DDoS e como identificá-lo a tempo

O primeiro sinal é um pico de tráfego acentuado sem uma razão clara. Se, às 2 da manhã, o tráfego salta de 30 países ao mesmo tempo e não há campanha publicitária no site, isso é um sinal de alerta. É especialmente suspeito se o pico estiver concentrado em uma página ou em um método de API.

O segundo sinal é o carregamento lento. O site pode ainda abrir, mas com um atraso de 8 a 15 segundos, e às vezes até mais. Os usuários não vão esperar. Eles fecharão a aba.

O terceiro sinal são os erros 5xx. Estes podem ser 500, 502, 503 e 504. O servidor está sobrecarregado, o proxy não está respondendo, a aplicação não consegue acompanhar as solicitações, e se tais erros aumentam junto com o tráfego, em vez de após um lançamento, vale a pena investigar um ataque DDoS.

O quarto sinal são problemas com autenticação e o painel de administração. O site pode ainda ser visível do lado de fora, mas fazer login na conta do usuário, na área administrativa ou no módulo de pagamento começa a falhar. Para as empresas, isso é especialmente desagradável: o cliente vê “o site está funcionando”, mas não consegue completar a ação.

O quinto sinal são padrões incomuns nos logs, e agentes de usuário repetidos, URLs idênticas, muitas solicitações sem um referenciador, faixas de IP estranhas. Se um log de 10 minutos parece cópia e colagem, é hora de verificar a proteção em vez de esperar que “passe por conta própria.”

O que fazer durante um ataque DDoS a um site

A primeira ação é ativar todos os mecanismos de proteção preparados. Ative o perfil WAF, limites de solicitações, modo de desafio se disponível, e cache no nível máximo sem arriscar a lógica de negócios. Se de sites contra ataques DDoS foi configurado com antecedência, isso é uma questão de minutos. Se não, a situação é muito pior.

A segunda ação é entrar em contato imediatamente com o provedor de hospedagem ou provedor de infraestrutura. Não envie apenas uma mensagem de chat — forneça detalhes: a hora de início do ataque, URLs afetadas, padrão de tráfego, capturas de tela de gráficos e endereços IP dos logs. Quanto mais precisa for a descrição, mais rápido o suporte pode ativar o filtro correto.

A terceira ação é restringir temporariamente os pontos de entrada vulneráveis. Você pode bloquear a área administrativa por IP, desativar formulários pesados, mudar parte do site para modo somente leitura, reduzir a funcionalidade da API ou remover temporariamente integrações desnecessárias. Sim, isso é inconveniente. Mas funcionalidade reduzida é melhor do que um site completamente fora do ar.

A quarta ação é analisar as fontes de tráfego, e você precisa de logs, geografia, padrões de solicitação, cabeçalhos idênticos e frequência de solicitações — não suposições. Se o ataque estiver vindo através de um ponto de extremidade, você pode isolá-lo, e se o ataque for distribuído, o foco muda para o provedor e filtragem em nível de rede.

A quinta ação é manter um cronograma curto. Quem ativou a proteção, quando o suporte foi contatado, o que foi alterado e qual efeito foi observado após 5, 15 e 30 minutos. Após o ataque, esse registro ajuda você a entender o que funcionou e o que fez o site quebrar ainda mais do que o próprio ataque.

Como escolher um serviço ou hospedagem para proteção DDoS

A escolha começa com o filtragem de tráfego. Pergunte quais níveis de proteção estão disponíveis: na camada de link, na camada de rede e na camada de aplicação, e se o provedor pode apenas “bloquear por IP”, isso não é suficiente para ataques complexos. Você precisa de mecanismos que vejam não apenas o endereço, mas também o comportamento da solicitação.

Verifique o SLA. O contrato deve especificar os tempos de resposta, a disponibilidade do serviço e os procedimentos de escalonamento. Sem essas linhas, você só descobrirá sobre o “suporte 24/7” após o primeiro ataque, quando a resposta chegar 40 minutos depois.

A geografia dos nós também importa. Se sua base de usuários está em 3 regiões, mas o filtragem está disponível em apenas um data center, a latência e a perda de pacotes aumentarão. Para um site internacional, é melhor escolher uma infraestrutura distribuída em vários pontos de presença.

A compatibilidade com o CMS e a pilha do projeto deve ser verificada com antecedência. WordPress, Laravel, Bitrix, Node.js, arquitetura headless — cada opção tem suas próprias limitações em torno de cache, proxies e cabeçalhos, e um bom serviço de proteção ainda pode ser uma má escolha para um site específico se quebrar a autenticação ou o carrinho de compras.

O suporte deve ser capaz não apenas de responder, mas de agir. Durante um ataque, é importante que um engenheiro possa aplicar rapidamente uma regra em vez de passar o ticket entre departamentos. Para um site corporativo, também é útil ler sobre estrutura de site corporativo, porque a proteção também depende de como as páginas de login, formulários de consulta e contas de usuário estão organizados.

Erros que enfraquecem a proteção DDoS de um site

O primeiro erro é a falta de monitoramento. Se os gráficos não estiverem configurados, o ataque é percebido tarde demais. O site já está caindo, e a equipe só está começando a procurar a causa no código, cache ou atualização de plugin.

O segundo erro são senhas fracas e painéis de administração abertos, e o dDoS muitas vezes vem acompanhado de tentativas de adivinhar o acesso ou distrair a equipe. Um painel de controle sem restrições de IP é uma má ideia, mesmo para um projeto pequeno.

O terceiro erro são configurações de cache incorretas, e às vezes, após ativar o cache, o site se torna rápido, mas o carrinho, a autenticação ou a conta do usuário falham. Isso cria uma falsa sensação de segurança, e sob ataque o problema volta, em um momento mais inconveniente.

O quarto erro é confiar em apenas uma ferramenta. Um CDN sem um WAF, um WAF sem limites, um host sem suporte — todos esses são mais fracos do que uma combinação de várias camadas. Um ataque DDoS raramente se parece com o mesmo duas vezes.

O quinto erro é ignorar testes de carga. Se o site nunca foi verificado sob um pico, ninguém sabe onde ele falhará primeiro, e um teste com 1.000 requisições não é o mesmo que um ataque, mas fornece um ponto de referência útil e revela pontos fracos.

O sexto erro é manter todos os serviços críticos em um só lugar. Quando o site, banco de dados, e-mail e análises estão todos em um único nó, um problema arrasta os outros para baixo também. Aqui vale a pena olhar com antecedência o material sobre suporte ao site após o lançamento, porque a proteção e o suporte pós-lançamento estão intimamente conectados.

Conclusão: um plano básico para proteção de sites contra ataques DDoS

Comece com 3 passos: habilite o monitoramento, feche pontos de entrada desnecessários e concorde com seu provedor de hospedagem sobre o processo de resposta em caso de ataque, e se o site já estiver funcionando sob carga, adicione um CDN, WAF e limites de requisições. Se o projeto for crítico para vendas, mantenha um cenário de fallback e os detalhes de contato do seu provedor à mão.

Depois, verifique os logs, timeouts, cache e áreas administrativas, e a proteção configurada uma vez não o salva para sempre, mas compra tempo quando um ataque já começou. E esse tempo muitas vezes importa mais do que toda a infraestrutura ao redor.

Se o projeto estiver crescendo, a proteção do site deve ser revisada após cada grande lançamento e após cada mudança no tráfego, e um novo módulo, um formulário, um método de API pode abrir carga extra, e um ataque DDoS rapidamente encontrará esse ponto fraco.