Como verificar se um host ou CDN realmente protege contra DDoS (guia prático)

Seu time vê dashboards brilhantes e a promessa de "proteção DDoS" no painel do provedor, mas o que importa para o negócio é saber se isso segura o checkout durante um pico malicioso, se preserva sessões de login e se evita perder chamadas críticas da API de faturamento. Este guia mostra como você, sem pedir privilégios administrativos ao provedor, pode obter evidências operacionais replicáveis e decidir entre confiar na borda (CDN/edge) ou contratar mitigação DDoS gerenciada.

A tese prática: não confie em slogans; valide com sinais observáveis — headers de borda, padrões de erro, tempos de failover, e comportamento de rate limiting. Quando esses sinais falham, a mitigação gerenciada deve ser considerada. A seguir detalho cenários, testes executáveis, interpretação de evidências, limites e um checklist para negociar SLAs e cláusulas contratuais.

Quais jornadas críticas testar primeiro e por quê

Priorize fluxos que, quando interrompidos, geram impacto financeiro ou reputacional imediato: checkout de e‑commerce, login e autenticação, APIs de faturamento e endpoints de webhook. Esses caminhos combinam sessões de usuário, autenticação e chamadas stateful que tendem a falhar sob estratégias de bloqueio genérico aplicadas na borda.

• Checkout: fracasso causa abandono de carrinho e chargebacks.
• Login/autenticação: bloqueio quebra UX e fluxo de recuperação de senhas.
• APIs de faturamento e webhooks: perda de confirmações impacta reconciliações.

O que uma CDN pública normalmente cobre e o que fica pendente

Uma CDN ou serviço de borda reduz a exposição direta da origem, fornece rate limiting básico, e aplica regras estáticas/behaviorais. Isso cobre muitas investidas simples, mas tem limites operacionais: ataques L7 sofisticados que simulam usuários legítimos, saturação de conectividade L3/L4 antes da borda, e tentativas de descobrir ou contornar cabeçalhos e caches.

Em contraste, uma mitigação gerenciada agrega visibilidade do tráfego global, playbooks operacionais e capacidade de reescalonamento humano durante eventos complexos — elementos que nem todo painel de CDN mostra claramente.

Testes que você pode executar sem acesso root ao provedor

Execute testes controlados apontando para endpoints públicos e coletando respostas do cliente. Nunca realize testes que violem políticas do provedor ou leis locais; os passos abaixo servem como diagnóstico básico em ambiente controlado.

1. Synthetic checks: faça requisições periódicas simulando o fluxo de checkout e capture status, latência e headers.
2. Rate tests progressivos: aumente a taxa de requisições por IP ou por sessão em incrementos pequenos e observe o ponto em que latência e erros disparam.
3. Failover e origem: provoque cenários simulados mudando temporariamente um DNS local ou um proxy para avaliar tempo de failover e caminhos de recuperação.
4. Validação de origem direta: quando possível, faça requests via IP direto (apenas em ambientes de teste autorizados) para ver se a origem responde sem passar pela borda.

Como executar um rate test seguro

Defina um alvo de teste curto e controlado, usando IPs de teste e janelas curtas. Registre timestamps, headers e códigos de erro. Não aumente volume até ter logs que permitam distinguir 429 (too many requests) de 5xx (falha do servidor/origem) — cada código aponta para ações diferentes.

Como coletar e interpretar evidências: headers, logs e padrões de erro

Sem acesso aos logs do provedor, concentre-se em evidências que o cliente pode coletar: headers HTTP, códigos de status, tempo de resposta e padrões de repetição. Peça ao provedor logs detalhados após o teste — sugestões de quais campos solicitar aparecem mais abaixo.

Headers úteis e o que eles indicam

• X-Edge-Request-ID / analogous: confirma que a requisição passou pela borda.
• X-RateLimit-Remaining e X-RateLimit-Reset: indicam políticas de rate limiting ativas.
• X-Cache-Status: mostra se conteúdo foi servido do cache ou repassado à origem.
• Server / Via: mudanças nesses headers podem indicar proxies intermediários ou reencaminhamento.

Esses nomes são ilustrativos — o importante é procurar headers que mostrem presença da borda, políticas de limite e cache. Ausência desses sinais não prova falta de mitigação, mas aumenta a necessidade de evidência adicional.

Erros 4xx vs 5xx e o que cada um revela

Requisições que recebem 4xx (especialmente 429) durante um aumento controlado tendem a indicar filtragem ativa ou rate limiting. Erros 5xx contínuos apontam para saturação de origem ou falhas internas. Em ataques reais, uma combinação de 429 seguida de 5xx conforme a origem satura é um padrão clássico.

Sinais que sugerem a borda está sendo contornada

Procure estes sinais durante e após testes:

• Resposta direta da origem ao fazer requisição por IP ou via cabeçalho Host manipulado em ambiente de teste.
• Headers inconsistentes entre regiões geográficas (ex.: uma região recebe X-Edge mas outra não).
• Latência que aumenta na origem enquanto a borda mantém latência baixa — sinal de que tráfego malicioso está atingindo a origem por outro caminho.
• Logs de origem mostrando tráfego de IPs que deveriam estar sendo filtrados.

Se algum desses sinais aparecer, peça ao provedor evidências correlacionadas por timestamp e, se necessário, encaminhe para um time de resposta a incidentes.

Critérios para concluir se a proteção cobre L7 e L3

Use critérios objetivos ao avaliar:

• Mitigação L7: presença de rate limiting por sessão, bloqueio por fingerprinting de bot e métricas de sucesso do fluxo (porcentagem de checkouts completados sob teste); evidência: 4xx de filtragem aplicada na borda e logs de borda com assinatura do evento.
• Mitigação L3/L4: capacidade de absorção de tráfego volumétrico e failover de rede; evidência: métricas de throughput na borda, rotas BGP controladas e logs de mitigação de conectividade — normalmente fornecidos pelo provedor em post‑mortem.

Na ausência de logs BGP ou métricas volumétricas fornecidas pelo provedor, a conclusão exige cautela: você pode observar sintomas mas não provar números absolutos.

Trade-offs: quando a CDN basta e quando contratar mitigação gerenciada

Escolha CDN quando: tráfego é majoritariamente estático, os fluxos críticos toleram rate limiting simples, e sua equipe tem acesso para validar headers e comportamentos. Considere mitigação gerenciada quando: jornadas críticas exigem disponibilidade ininterrupta, ataques anteriores mostraram evasão da borda, ou você precisa de playbooks operacionais e correção em tempo real.

Lembre: mitigação gerenciada não substitui práticas de hardening de aplicação. Ela complementa políticas de WAF, validação de entrada, e arquitetura resiliente.

Checklist operacional para negociar com provedores

1. Peça cláusula de visibilidade: acesso a logs de borda e amostras por timestamp durante testes.
2. Defina indicadores observáveis (headers, códigos de status e tempos de failover) como critérios de aceitação.
3. Exija playbooks de escalonamento e SLAs de resposta a incidentes (tempo de resposta inicial e comunicações regularizadas).
4. Solicite testes coordenados: avalie comportamento durante um teste conjunto com janela e escopo acordados.

Perguntas frequentes

Um CDN garante proteção total contra DDoS?

Não. Uma CDN reduz exposição e bloqueia vetores simples, mas pode não deter ataques L7 sofisticados que imitam tráfego legítimo nem proteger contra rotas alternativas até a origem. Valide com os testes e evidências descritos.

Como diferenciar tráfego legítimo de ataque nas minhas métricas?

Compare padrões de comportamento: aumento súbito de requests por endpoint sem aumento correspondente de conversão, padrões de user‑agent repetitivo, ausência de cookies esperados e aumento de erros 4xx/5xx. Logs de sessão e correlacionamento por fingerprint ajudam a separar ruído de ataque.

O que é failover de origem e por que importa?

Failover de origem é o tempo e processo para redirecionar ou recuperar serviço quando a origem fica indisponível. Importa porque uma borda pode continuar retornando respostas de cache, mas a lógica autenticada e escrita (checkout, faturamento) depende de origem saudável. Tempo de failover longo significa janela de perda de transações.

Que logs pedir ao provedor para validar ação de mitigação?

Solicite logs de borda com timestamps, campos de request (IP, Host, User‑Agent), ações executadas (bloqueio, challenge, rate limit), e amostras de tráfego descartado. Para mitigação L3, peça métricas de pico e registros de alteração de rota/filtragem.

O que a solução MVX Shield faz e o que não substitui

MVX Shield oferece avaliação técnica coordenada, testes de prova e relatório de evidências acionáveis para suas jornadas críticas, além de serviços de hardening específicos para L7. Não substituímos práticas de engenharia seguras: configuração de autenticação, validação de entrada e arquitetura resiliente continuam essenciais.

Próximo passo prático

Solicite uma avaliação técnica de proteção DDoS coordenada com testes controlados e receba um relatório de evidências acionáveis. Para começar, agende uma avaliação ligada ao nosso programa de L7 Hardening e às ofertas de Website Security. Se precisar de resposta a incidentes, veja também nossa solução de Incident Response. Solicite uma avaliação técnica de proteção DDoS e receba um relatório de evidências acionáveis.