O que fazer em caso de um ataque DDoS em um site?
Recentemente, Zerlo.net foi confrontado com um ataque DDoS. Nos interessou: Como lidamos com isso, como detectamos algo assim – e como pudemos prová-lo inequivocamente? Neste artigo, mostro nossos passos, o que está por trás do DDoS e como Cloudflare ajuda como camada de proteção. Se você tiver problemas semelhantes, encontrará ferramentas práticas em nosso Zerlo-Toolseite e outros artigos no Zerlo-Blog .
Fonte: Representação própria
Explicação: O que é um DDoS?
Um Distributed-Denial-of-Service-Angriff (DDoS) é a tentativa de paralisar um serviço online através de um volume massivo de solicitações distribuídas. "Distribuído" significa: o ataque vem simultaneamente de muitas fontes, frequentemente automatizadas ( CISA-Leitfaden). ). Distingue-se grosseiramente entre ataques na camada de rede (por exemplo, UDP/ICMP-Floods) e na camada de aplicação (Layer 7), como HTTP-Floods. . OWASP também fornece uma boa introdução prática ( (Denial of Service)).
Como reconhecer?
Uma única métrica raramente é suficiente. Os padrões típicos são: carga de origem aumentando drasticamente, mas sessões/conversões reais inalteradas; de repente, muitas solicitações em endpoints "caros" (login, busca, /api, formulários); User-Agents suspeitos ou vazios; picos incomuns de novos ASNs; alta carga de CPU/IO sem alteração de código. Logs limpos são úteis, que você pode avaliar, por exemplo, via Cloudflare Logpush/Log Explorer ou no lado do servidor. Você encontrará um checklist compacto no Zerlo-Blog para incidentes semelhantes.
Reconhecimento via Cloudflare
No Cloudflare, esses padrões podem ser decompostos de forma clara:
- Segurança → Eventos/Análise: Segmentar picos por caminho, país, ASN, método, User-Agent ( Security Analytics)).
- Tráfego/Análise: Muitos Edge-Requests com alta taxa de Origem ao mesmo tempo → Indício de L7-Floods ( Traffic Analytics)).
- WAF/Firewall: "Challenged/Blocked" conta mitigações; ajustar finamente as regras ( Cloudflare WAF)).
- HTTP-DDoS/Rate Limiting: Identificar Hotspots de IP/Caminho ( Rate Limiting Rules, HTTP DDoS Managed Rules)).
Conclusão: Para sites com muitos usuários, uma camada de proteção a montante como Cloudflare Application Services é praticamente obrigatória – telemetria e ferramentas ajudam a distinguir entre carga legítima e ataque e a reagir rapidamente. Internamente, referimo-nos ao Zerlo-Blog para artigos básicos e ao Zerlo-Tools para ferramentas.
Pessoal
Nós da Zerlo tivemos que constatar uma utilização invulgarmente alta em 31/10/2025 – por vezes, o site esteve offline várias vezes. Inicialmente, presumi que fosse um problema técnico. Em seguida, verifiquei o número de visitantes: quase idêntico ao dia anterior, o que era estranho, pois nosso contador mede apenas interações humanas (JavaScript). Under-Attack-Mode (UAM) O clássico contra-teste: Iniciar tudo localmente (localhost). Resultado: 0 % de carga local – então a carga externa devia ser artificial. No Cloudflare, o aumento era claramente visível. Ativei o
Fonte: Representação própria
Resumindo: Fomos atacados por DDoS. Continuaremos a partilhar mais informações no Zerlo-Blog.
Cloudflare
Se o host da web já tiver uma boa proteção na camada de rede, isso é muitas vezes suficiente para ataques volumétricos, especialmente se o provedor mitigar. No entanto, nós operamos na Zerlo uma rede maior com vários serviços e precisamos de interfaces centrais, a montante, que terminem e filtrem o tráfego de forma inteligente antes que ele chegue às nossas origens. É exatamente aqui que uma rede Edge global como o Cloudflare ajuda: Anycast, Caching, WAF, Bot Fight Mode, Rate-Limiting e telemetria detalhada.
O Cloudflare pode ser usado gratuitamente na versão básica e pode ser "acelerado" a curto prazo em caso de ataques. Ele não reconhece perfeitamente todos os cenários automaticamente – é preciso observar padrões –, mas depois é muito eficaz com as regras certas. Para configurações e benchmarks, também documentamos as melhores práticas em zerlo.net/de/tools.
Mecanismo de Proteção do Cloudflare Explicado
Simples e engenhoso: Antes do acesso real à página, o Cloudflare pode pré-executar uma verificação baseada em JavaScript ( Challenge) ) e avaliar sinais do navegador. Para usuários reais, isso acontece uma única vez e quase imperceptivelmente; bots e scripts falham ou têm que gastar muito mais recursos. Resultado: A carga de backend diminui imediatamente e você ganha tempo para ajustes finos ( WAF, Rate-Limits, Caching)).
❝ DDoS não se previne – se gerencia. A arte é tornar os ataques invisíveis para as pessoas, mas caros para os bots. ❞Zerlo.net
Fonte: Resumo de botnets e DDoS.
O que se pode fazer contra isso?
Nada. Você não impede um DDoS – qualquer pessoa na rede pode enviar-lhe pacotes. Mas você pode minimizar o efeito para que o site permaneça disponível para usuários reais. É disso que se trata: amortecer de forma inteligente em vez de suportar passivamente.
Curto prazo: Under-Attack-Mode (UAM) ativar para amortecer imediatamente a carga da Camada 7.
Permanente: WAF-Regeln para POST/APIs/GETs caros, regras Managed-Challenges para User-Agents suspeitos, Rate-Limiting por IP. Para páginas públicas, " Cache Everything“, ", para Logins/Administradores, "Bypass on Cookie". Proteger formulários com Turnstile .
Operação: Security Analytics observar, definir alertas, Logs assegurar. Um pequeno script pode puxar UAM automaticamente se os pings falharem – e notificá-lo. Exemplos e snippets são documentados em zerlo.net/de/blog.
(len(http.user_agent) = 0
or lower(http.user_agent) contains "python"
or lower(http.user_agent) contains "curl"
or lower(http.user_agent) contains "bot"
or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge
(http.request.method eq "POST"
or starts_with(http.request.uri.path, "/api/")
or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge
# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge
# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/
#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"
# UAM EIN
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"value":"under_attack"}'
# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"value":"high"}'
# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level
# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;
server {
location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
}
}
# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html
Outros Recursos
Fundamentos e Aprofundamento: NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. Outros artigos práticos e ferramentas podem ser encontrados em zerlo.net e especificamente sob zerlo.net/de/tools.
Conclusão
DDoS não é uma exceção, mas um caso operacional. Quem reconhece anomalias rapidamente, amortece a curto prazo e depois reforça de forma direcionada, permanece online. Para sites em crescimento, o Cloudflare é altamente recomendado como camada de proteção a montante: visibilidade, medidas imediatas e módulos para uma operação contínua robusta. Para configurações individuais, checklists e snippets, referimo-nos ao Zerlo-Blog e à Zerlo-Tools.