Guia completo do modo Under Attack da Cloudflare: 3 técnicas para preservar SEO e experiência

Introdução

CPU do servidor em 100% e tráfego dez vezes maior: sinais clássicos de um ataque CC. Entrei no painel da Cloudflare, ativei o modo “I’m Under Attack” e, 30 segundos depois, a carga do servidor havia diminuído.

No dia seguinte, abri o Google Search Console: o número de páginas indexadas tinha caído de mais de 1.200 para pouco mais de 800, uma redução superior a 30%. Depois de investigar por um bom tempo, entendi que o desafio de cinco segundos também estava bloqueando os rastreadores dos mecanismos de busca.

Sem ele, o servidor não suportava o ataque; com ele, SEO e experiência do usuário eram prejudicados. Neste artigo, explico como usar o modo Under Attack da Cloudflare para conter ataques sem sacrificar esses dois pontos.

Capítulo 1: o que é o modo Under Attack da Cloudflare?

Como funciona: o que acontece nesses cinco segundos

Em termos simples, o modo Under Attack acrescenta uma etapa de verificação entre seu site e o visitante. Quando alguém acessa o site, a Cloudflare não libera a entrada imediatamente: primeiro exibe uma página intermediária e pede que a pessoa aguarde cerca de cinco segundos.

Essa espera tem uma função. Durante o intervalo, a Cloudflare executa três etapas:

Primeira etapa: o navegador envia automaticamente uma solicitação inicial, e a Cloudflare grava um cookie chamado __cfduid, como se fosse uma credencial temporária para o visitante.

Segunda etapa: o navegador envia outra solicitação, agora com parâmetros criptografados. Depois da validação, a Cloudflare grava o cookie essencial cf_clearance. Essa é a credencial efetiva, válida por 30 minutos por padrão.

Terceira etapa: o navegador solicita a página inicial levando os dois cookies. A Cloudflare confere os dados e libera o acesso; só então o conteúdo do site é carregado de verdade.

Além dessas três solicitações, há outras verificações em segundo plano:

• Verificação JavaScript: um código JS ofuscado testa se o navegador consegue executar JavaScript normalmente. Navegadores comuns passam sem dificuldade, mas muitos bots simples e scripts de ataque falham.
• Impressão digital do navegador: resolução da tela, lista de extensões instaladas, fontes do sistema e outros dados são combinados em uma “impressão digital” única. Isso ajuda a identificar ferramentas de ataque disfarçadas de navegadores normais.
• Análise comportamental: frequência das solicitações, User-Agent, movimento do mouse e outros sinais ajudam a determinar se há uma pessoa de verdade operando o navegador.

Qual é a diferença para os outros níveis de segurança?

A Cloudflare oferece vários níveis de segurança, não apenas o modo Under Attack. A tabela resume as diferenças:

Pela minha experiência, Medium basta no dia a dia. Só mudo temporariamente para I’m Under Attack quando o site realmente está sendo atacado. Não deixe o desafio ativo o tempo todo: seria como viver usando uma máscara de gás e acabar sem ar também.

Quais ataques ele consegue conter?

Antes, vale uma breve explicação sobre DDoS. Ataques de rede são classificados em sete camadas no modelo OSI, e as camadas superiores ficam mais próximas da aplicação.

O modo Under Attack protege principalmente contra ataques à camada 7, os chamados ataques CC (Challenge Collapsar). Eles simulam visitas normais, mas enviam um volume enorme de solicitações até esgotar os recursos do servidor.

Para DDoS volumétricos em camadas inferiores, como UDP Flood e SYN Flood, esse modo tem utilidade limitada. A Cloudflare usa outros mecanismos para se defender deles. Por isso, a documentação oficial o trata como “um dos últimos recursos”, não como uma solução universal.

Nas palavras da Cloudflare, o recurso “realiza verificações adicionais de segurança para ajudar a mitigar ataques DDoS de camada 7”. O ponto importante é “ajudar a mitigar”, e não “bloquear por completo”. Em ataques DDoS de escala muito grande, o modo sozinho não basta e precisa ser combinado com outras defesas.

Capítulo 2: o impacto real no SEO e na experiência do usuário

Os rastreadores de busca conseguem passar pelo desafio?

Eu já testei isso, e a resposta é: depende.

O rastreador do Google, o Googlebot, consegue executar JavaScript e, em teoria, pode passar pela verificação. O problema é que o tempo de rastreamento é precioso. Em vez de esperar cinco segundos como uma pessoa, ele tende a visitar outros sites e voltar mais tarde.

Ao acompanhar os dados do Google Search Console depois de ativar o modo Under Attack, observei alguns efeitos:

1. Queda acentuada na frequência de rastreamento: de cerca de 1.200 acessos diários para 400 a 600.
2. Mais erros de rastreamento: surgiram muitos avisos de timeout e erro de servidor.
3. Indexação mais lenta: artigos novos, antes indexados em 1 ou 2 dias, passaram a levar de 4 a 5 dias.

O rastreador do Baidu sofre ainda mais. Como sua capacidade de executar JavaScript é limitada, ele costuma falhar diante do desafio. Um amigo que mantém um site em chinês ativou o modo por três dias e viu o número de páginas indexadas pelo Baidu cair de mais de 2.000 para pouco mais de 1.000.

O Bing fica entre os dois: consegue passar, mas é mais lento, e o volume indexado pode cair de 15% a 20%.

Dados reais sobre a experiência do usuário

Não basta falar de teoria: precisamos olhar os dados. Fiz um teste A/B e registrei como o comportamento dos usuários mudou antes e depois da ativação.

A taxa de rejeição disparou:

• Antes: 35%
• Depois: 62%
• Aumento: 77%

De cada dez novos visitantes, cerca de seis fecharam a página assim que viram a espera de cinco segundos. E isso no desktop; no celular, a taxa de rejeição chegou a 75%.

O tempo médio de permanência caiu:

• Antes: 3 min 15 s
• Depois: 1 min 48 s
• Redução: 45%

A taxa de conversão caiu pela metade:

Se o site depende de cadastros, compras ou outras conversões, é razoável esperar uma queda de cerca de 50%. A pessoa chega animada, mas precisa esperar cinco segundos antes mesmo de ver o conteúdo e perde boa parte do interesse.

Um amigo do setor de e-commerce me contou que ativou o modo durante um ataque e viu os pedidos daquele dia caírem de uma média de 60 para 22. O ataque foi contido, mas as vendas também desapareceram.

Distorções nas ferramentas de análise

Esse problema é menos visível. A documentação oficial da Cloudflare diz que, como a exibição e a conclusão da página intermediária exigem JavaScript no navegador, é esperado que haja interferência em ferramentas de análise que também dependem de JavaScript.

Na prática:

O Google Analytics registra menos dados:

• A página de espera não inclui o código de rastreamento do GA.
• Quem abandona nessa etapa não é contabilizado.
• Os dados exibidos representam apenas quem passou pela validação; o volume real é maior.

Mapas de calor deixam de funcionar:

Ferramentas como Hotjar e Crazy Egg não registram o comportamento na página de espera. Você pode achar que todos entraram no site normalmente, quando, na verdade, metade foi embora ainda na porta.

O rastreamento de anúncios perde a visibilidade:

Se você usa Google Ads ou anúncios no Facebook, o acompanhamento de conversões pode ficar praticamente inutilizável após a ativação. Facebook Pixel e tags de conversão do Google Ads não são carregados: o orçamento é gasto, mas os dados desaparecem.

O desastre para APIs e serviços de terceiros

O impacto sobre páginas web ainda pode ser tolerado, mas para APIs é desastroso.

Problema 1: todas as solicitações de API falham

Chamadas de API normalmente ocorrem entre programas, não em um navegador. O cliente não executa JavaScript nem espera cinco segundos; ele apenas recebe um erro.

O pior caso que já vi envolveu um aplicativo móvel cuja API era protegida pela Cloudflare. O desenvolvedor ativou o modo no site inteiro por engano e derrubou de uma vez o aplicativo de mais de 50 mil usuários ativos. O telefone de suporte não parava de tocar.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Problema 2: integrações de terceiros são interrompidas

Muitos sites integram serviços externos, como:

• Callbacks de pagamento, como PayPal e Stripe
• Webhooks, como GitHub e Slack
• Feeds RSS
• Monitoramento do site, como Uptime Robot

Esses serviços não passam pelo desafio e acabam bloqueados. A falha no callback de pagamento é especialmente grave: o cliente paga, o site não recebe a notificação, o pedido não é atualizado e a equipe de suporte fica sobrecarregada.

Problema 3: aplicativos móveis não conseguem acessar a API

Se um aplicativo iOS ou Android se comunica com o servidor por uma Web API, ativar o modo Under Attack equivale a inutilizá-lo. O usuário abre o app, fica preso em “Loading” e termina com uma mensagem de “erro de rede”.

Por isso, minha recomendação é clara: se você tem APIs, aplicativos móveis ou integrações importantes, nunca ative o modo no site inteiro. Exclua esses caminhos com Page Rules, como veremos no próximo capítulo.

Capítulo 3: como ativar o modo apenas em caminhos específicos com Page Rules

O que são Page Rules?

Page Rules são as “regras condicionais” da Cloudflare. Elas permitem definir níveis de segurança, políticas de cache e outras opções para caminhos diferentes de uma URL.

Por exemplo:

• Em example.com/api/*, use Security Level Low e não aplique o desafio.
• Em example.com/admin/*, use I’m Under Attack e valide rigorosamente.
• Nas demais páginas, use Medium.

Assim você obtém uma proteção precisa: restringe os pontos sensíveis sem prejudicar a experiência no restante do site.

Há, porém, uma notícia ruim: em junho de 2024, a Cloudflare anunciou que Page Rules seriam descontinuadas gradualmente, com os novos recursos migrando para Configuration Rules, Cache Rules e outros sistemas. A boa notícia é que as Page Rules dos usuários atuais continuarão funcionando e a própria Cloudflare cuidará da migração, sem exigir uma mudança manual.

Contas gratuitas ainda podem usar três Page Rules, o que basta para a maioria dos sites pessoais. O plano Pro oferece 20 e o Business, 50.

Como usar corretamente o curinga * nas URLs

O núcleo das Page Rules é a correspondência de URL, e o recurso mais usado é o curinga *.

Regras básicas:

• * corresponde a qualquer sequência, inclusive vazia.
• Pode ser usado em qualquer posição da URL.
• Uma regra pode ter vários *.

Padrões comuns:

example.com/api/*
→ corresponde a example.com/api/users
→ corresponde a example.com/api/posts/123
→ não corresponde a example.com/apiv2/users (é preciso haver uma barra após api)
example.com/*.jpg
→ corresponde a example.com/logo.jpg
→ corresponde a example.com/images/banner.jpg (inclui subdiretórios)
→ não corresponde a example.com/logo.png
example.com/*admin*
→ corresponde a example.com/wp-admin
→ corresponde a example.com/admin/users
→ corresponde a example.com/myadmin (basta admin aparecer na URL)

Regra de prioridade, um ponto essencial:

As Page Rules são avaliadas de cima para baixo. Assim que encontra a primeira correspondência, a Cloudflare executa essa regra e ignora as seguintes.

Isso significa que:

1. Regras específicas devem vir antes; regras genéricas com curingas, depois.
2. Na ordem inversa, a regra ampla “engole” todas as solicitações e as regras específicas nunca são executadas.

Exemplo incorreto:

Regra 1: example.com/* → Security Level: I'm Under Attack
Regra 2: example.com/api/* → Security Level: Low

A regra 2 nunca entra em vigor, porque a regra 1 já captura todas as solicitações.

A ordem correta é:

Regra 1: example.com/api/* → Security Level: Low (caminho específico primeiro)
Regra 2: example.com/* → Security Level: I'm Under Attack (curinga depois)

Cenário 1: proteger somente o login e o painel administrativo

Esse é o caso mais comum. Atacantes costumam tentar força bruta nas páginas de login, então basta proteger esses pontos com mais rigor.

Em um site WordPress, a configuração seria:

Regra 1: proteger o diretório wp-admin

• Correspondência: example.com/wp-admin*
• Configuração: Security Level → I’m Under Attack

Regra 2: proteger a página de login

• Correspondência: example.com/wp-login.php
• Configuração: Security Level → I’m Under Attack

Regra 3: manter as demais páginas no nível médio

• Correspondência: example.com/*
• Configuração: Security Level → Medium

Com isso, apenas o painel e o login acionam a espera de cinco segundos. A leitura de artigos continua normal e o SEO não é prejudicado.

Cenário 2: excluir endpoints de API

Se o site tem uma API, ela não pode ficar atrás desse desafio. Use:

Regra 1: nível de segurança baixo no caminho da API

• Correspondência: example.com/api/*
• Configuração: Security Level → Low

Regra 2: subdomínio dedicado à API móvel

• Correspondência: api.example.com/*
• Configuração: Security Level → Low

Regra 3: nível alto nos outros caminhos

• Correspondência: example.com/*
• Configuração: Security Level → I’m Under Attack

Observe a ordem: as regras da API precisam estar no topo.

Se a API tem várias versões, você pode usar:

example.com/api/v1/*
example.com/api/v2/*

Isso consome mais regras. Uma alternativa mais eficiente é:

example.com/api*

Esse padrão corresponde a todos os caminhos que começam com /api.

Cenário 3: proteger páginas dinâmicas e liberar arquivos estáticos

Imagens, CSS e JavaScript normalmente não precisam do desafio. Bloqueá-los pode deixar a página incompleta.

Regra 1: liberar imagens

• Correspondência: example.com/*.jpg
• Configuração: Security Level → Low, Cache Level → Cache Everything

Você poderia criar regras semelhantes para:

• example.com/*.png
• example.com/*.css
• example.com/*.js

Mas isso consome muitas regras. Uma solução melhor é servir os arquivos estáticos em um subdomínio de CDN:

• cdn.example.com/* → Security Level: Low

Regra 2: proteção alta nas páginas dinâmicas

• Correspondência: example.com/*
• Configuração: Security Level → I’m Under Attack

Assim, o HTML fica protegido, enquanto imagens e folhas de estilo carregam normalmente, melhorando bastante a experiência.

Configuração completa, passo a passo

Vamos percorrer o processo:

Etapa 1: entre no Cloudflare Dashboard

Acesse cloudflare.com, entre na conta e selecione o domínio desejado.

Etapa 2: abra Page Rules

No menu lateral, acesse Rules → Page Rules.

No Dashboard mais recente, o caminho pode aparecer como Rules → Page Rules (Legacy).

Etapa 3: crie a primeira regra

Clique em Create Page Rule.

No campo If the URL matches, informe o padrão da URL, por exemplo:

example.com/api/*

Role a tela, clique em + Add a Setting, selecione Security Level e defina Low.

Clique em Save and Deploy para salvar.

Etapa 4: crie as outras regras

Repita a terceira etapa. Lembre-se de que a ordem é importante.

Etapa 5: ajuste a prioridade

Na lista de regras, arraste o ícone de três linhas ao lado de cada uma. Coloque as específicas em cima e as genéricas embaixo.

Etapa 6: teste

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

Abra uma janela anônima e visite caminhos diferentes, confirmando que:

• A API não aciona o desafio ✓
• As páginas comuns acionam o desafio ✓
• Os arquivos estáticos carregam normalmente ✓

Como aproveitar ao máximo as três regras do plano gratuito

Com apenas três regras, é preciso escolher bem. Minha configuração recomendada é:

Regra 1: proteger a entrada mais importante

example.com/wp-admin*
Security Level: I'm Under Attack

Regra 2: liberar APIs e arquivos estáticos

example.com/api*
Security Level: Low

Regra 3: proteção média para as demais páginas

example.com/*
Security Level: Medium

Isso protege as áreas críticas sem atrapalhar o uso cotidiano. Se o site não estiver sob ataque, não mude para I’m Under Attack sem necessidade.

Capítulo 4: boas práticas para o Challenge Passage

O que é Challenge Passage?

Como vimos, depois que o visitante passa pela primeira verificação, a Cloudflare grava no navegador o cookie cf_clearance. Ele funciona como uma credencial temporária: enquanto for válido, a pessoa navega pelas outras páginas sem repetir o desafio.

Challenge Passage é justamente o tempo de validade dessa credencial.

O padrão é 30 minutos. Depois da aprovação, o usuário pode navegar pelo site sem voltar a ver a página de desafio nesse período. Ao expirar, o cookie precisa ser renovado na visita seguinte.

Há alguns detalhes técnicos interessantes:

Margem para divergência de relógio: durante a validação, a Cloudflare acrescenta alguns minutos para evitar erros causados por diferenças entre os relógios do cliente e do servidor.

Tratamento especial para XMLHttpRequest: em requisições Ajax, a Cloudflare acrescenta uma hora de tolerância. Isso evita expirações frequentes em aplicações de página única, ou SPAs, com cache de curta duração.

Herança do nível de segurança: se o usuário passou por um Interactive Challenge, a verificação mais rigorosa, o cookie permite atravessar desafios de qualquer nível. Se passou apenas por um nível inferior, ainda precisará validar novamente diante de um nível superior.

Onde configurar o período?

No Cloudflare Dashboard, acesse:

Security → Settings → Challenge Passage

Clique no ícone de edição para mudar o tempo em minutos. A Cloudflare recomenda uma faixa de 15 a 45 minutos.

Essa configuração é global para todo o domínio. Não é possível definir um período diferente para cada caminho.

Valores recomendados para cada cenário

Com base na minha experiência prática, recomendo:

Alta segurança, como finanças, pagamentos e dados sensíveis: 15 a 20 minutos

• Indicado para: internet banking, plataformas de pagamento e sistemas corporativos.
• Motivo: a segurança tem prioridade máxima, as sessões costumam ser curtas e verificações frequentes são aceitáveis.
• Experiência: validar a cada 15 minutos incomoda um pouco, mas é compreensível nesse contexto.

Equilíbrio, como e-commerce, sites corporativos e SaaS: 30 minutos, o padrão

• Indicado para: a maioria dos sites comerciais.
• Motivo: equilibra segurança e experiência; 30 minutos bastam para concluir uma compra ou uma sessão de navegação.
• Experiência: a maioria das pessoas termina o que precisava antes de encontrar uma segunda verificação.

Experiência em primeiro lugar, como portais de conteúdo, blogs e mídia: 40 a 45 minutos

• Indicado para: sites de notícias, blogs técnicos e plataformas de vídeo.
• Motivo: as sessões são longas e passam por várias páginas; verificações frequentes interrompem a leitura.
• Experiência: o leitor consegue terminar alguns artigos longos sem ser interrompido.

No meu blog técnico, uso 40 minutos. Os leitores costumam abrir vários artigos em uma única visita, e 30 minutos às vezes não bastam.

Três equívocos comuns

Equívoco 1: quanto menor o período, maior a segurança

Muita gente imagina que definir cinco minutos e repetir a validação nesse intervalo oferece o máximo de segurança.

Isso é ilusório. O objetivo do modo Under Attack é diferenciar pessoas de máquinas, não impedir a mesma pessoa de voltar. Se um usuário real já foi aprovado, obrigá-lo a repetir o processo a cada cinco minutos só cria irritação.

O tráfego malicioso é bloqueado logo no primeiro desafio, sem obter o cookie, ou usa ferramentas avançadas para contornar a verificação. Nesse segundo caso, cinco ou 30 minutos não fazem diferença.

Equívoco 2: várias horas são mais convenientes

Talvez você pense: “Se eu definir duas horas, a experiência não fica melhor?”

O problema é que um cookie válido por tempo demais reduz bastante a segurança. Imagine:

1. A pessoa passa pela verificação usando o Wi-Fi público de uma cafeteria.
2. Ela vai embora, mas o cookie continua válido.
3. Outra pessoa na mesma rede, ou um invasor, pode obter esse cookie.
4. Pelas próximas duas horas, o invasor navega livremente com essa credencial.

Há uma razão para a Cloudflare recomendar um máximo de 45 minutos. Não tente ser mais esperto definindo um período muito maior.

Equívoco 3: acreditar que o período vale para todas as regras

Eu mesmo já caí nessa armadilha. Mesmo depois de configurar o Challenge Passage, algumas regras continuavam acionando verificações frequentes.

Ao consultar a documentação, descobri que Challenge Passage não se aplica a Rate Limiting Rules.

Se você limita a frequência de solicitações com Rate Limiting, o usuário terá de validar novamente sempre que exceder o limite, independentemente do valor definido no Challenge Passage.

Como saber se a configuração está adequada?

Depois de configurá-la, não confie apenas na intuição. Acompanhe estes indicadores:

1. Reclamações dos usuários

Se as pessoas começarem a dizer que “precisam esperar cinco segundos o tempo todo”, o período pode estar curto demais. Analise o padrão normal das visitas e ajuste o valor.

2. Logs de Security Events

No Cloudflare Dashboard, acesse Security → Events. Se o mesmo IP acionar vários desafios em um intervalo curto, o período talvez esteja baixo demais.

3. Taxa de rejeição e tempo de permanência

Se a rejeição subir de repente e o tempo médio cair, pode haver uma segunda verificação durante a navegação, fazendo o usuário desistir.

Minha prática é observar por uma semana depois de alterar a configuração e ajustar com base nos dados. Não comece com valores extremos.

Como combinar o recurso com o WAF

Em muitos casos, não é preciso aplicar o modo Under Attack em todo o site nem repetir desafios com frequência. Com o WAF, o resultado pode ser melhor:

1. Filtre o tráfego claramente malicioso no WAF
   • Bloqueie faixas de IP maliciosas conhecidas.
   • Intercepte User-Agents anormais.
   • Limite a frequência das solicitações.
2. Reserve o modo Under Attack para caminhos críticos
   • Ative-o apenas em páginas de login, cadastro e pagamento usando Page Rules.
   • Use Medium ou High nas demais páginas.
3. Defina um período razoável
   • Não tente usar o menor intervalo possível.
   • Trinta minutos bastam para a maioria dos sites.

Nessa configuração, 90% do tráfego malicioso é filtrado pelo WAF, e apenas os 10% restantes, considerados suspeitos, passam pelo desafio. O resultado é mais seguro e menos incômodo para usuários legítimos.

Capítulo 5: sete boas práticas para usar o modo Under Attack

Prática 1: não o mantenha ativo no site inteiro

Esse é um dos erros mais comuns entre iniciantes. A pessoa vê o site sob ataque, ativa o recurso às pressas e esquece de desligá-lo quando o ataque termina, mantendo-o por meses.

O que fazer:

• Ative temporariamente apenas durante um ataque evidente.
• Depois que ele terminar, normalmente em 1 a 3 dias, volte para Medium ou High.
• Use uma ferramenta de monitoramento, como UptimeRobot, para verificar o site regularmente.
• Crie um lembrete semanal no calendário para revisar o nível de segurança.

Eu sigo uma regra: sempre que ativo o modo, programo um alarme no celular para 48 horas depois e reavalio obrigatoriamente se ele ainda é necessário.

Prática 2: priorize a proteção precisa com Page Rules

Ativar no site inteiro é a solução mais bruta, como soldar todas as portas de casa para impedir a entrada de ladrões. A abordagem inteligente é trancar apenas as portas importantes.

Caminhos que merecem proteção reforçada:

1. Login: /login, /wp-login.php
2. Cadastro: /register, /signup
3. Administração: /admin, /wp-admin
4. Pagamento: /checkout, /payment
5. Envio de formulários: /contact, /comment

Caminhos que precisam ser excluídos:

1. APIs: /api/*, /rest/*
2. Arquivos estáticos: /*.jpg, /*.css, /*.js
3. Feeds RSS: /feed, /rss.xml
4. robots.txt e sitemap.xml
5. Health checks: /health, /status

Uma configuração ideal para um blog técnico:

Regra 1: example.com/wp-admin* → I'm Under Attack
Regra 2: example.com/xmlrpc.php → I'm Under Attack (alvo específico em WordPress)
Regra 3: example.com/* → Medium

Prática 3: personalize a página de desafio para melhorar a experiência

A página padrão do desafio aparece em inglês, o que não é amigável para usuários que falam português. Os planos pagos da Cloudflare permitem personalizá-la.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Como personalizar:

Acesse Custom Pages → 5-Second Shield e envie uma página HTML personalizada.

Elementos recomendados:

• Logotipo e nome do site, reforçando a marca.
• Mensagem em português: “Estamos verificando a segurança do seu navegador. Aguarde…”
• Contagem regressiva para tornar a espera menos monótona.
• Motivo breve: “Para proteger o site contra ataques, precisamos confirmar que você é uma pessoa.”
• Informações de contato para quem encontrar problemas.

O melhor exemplo que vi transformava os cinco segundos em um pequeno jogo de carregamento no qual o usuário coletava estrelas. A espera ficou bem mais agradável.

Prática 4: combine com regras de WAF

O modo Under Attack deve ser a última linha de defesa, não carregar toda a pressão. O WAF pode filtrar boa parte do tráfego malicioso antes.

Regras de WAF recomendadas:

Regra 1: bloquear faixas de IP maliciosas conhecidas

(ip.geoip.country in {"CN"} and cf.threat_score > 30)
→ Action: Block

(Atenção: é apenas um exemplo; a configuração real depende do seu público.)

Regra 2: interceptar User-Agents anormais

(http.user_agent contains "curl" or http.user_agent contains "python")
→ Action: Challenge

Regra 3: limitar a frequência da API

(http.request.uri.path contains "/api/" and rate > 100/1m)
→ Action: Block for 1h

Regra 4: proteger o endpoint de login

(http.request.uri.path eq "/wp-login.php" and rate > 5/5m)
→ Action: Challenge

Com essas regras, 90% do tráfego malicioso é bloqueado antes, e o desafio precisa lidar apenas com uma pequena parcela suspeita.

Prática 5: crie exceções para rastreadores de busca

Essa medida pode reduzir bastante o impacto no SEO. Embora o Googlebot consiga passar em teoria, facilitar o rastreamento é sempre melhor.

Método 1: identificar o User-Agent no WAF

Crie uma WAF Custom Rule:

(http.user_agent contains "Googlebot" or
 http.user_agent contains "Bingbot" or
 http.user_agent contains "Baiduspider")
→ Skip: Security Level for this request

Assim, os rastreadores ignoram a verificação.

Método 2: reduzir o nível para faixas de IP conhecidas

Google, Bing e outros mecanismos publicam as faixas de IP de seus rastreadores. Você pode criar uma IP Access Rule e permitir esses endereços.

Lista oficial de IPs dos rastreadores do Google:

https://developers.google.com/search/docs/advanced/crawling/verifying-googlebot

Atenção:

Atacantes podem falsificar o User-Agent. A abordagem mais segura combina a validação do endereço IP com o User-Agent ou usa uma consulta DNS reversa.

Prática 6: monitore e ajuste

Uma configuração não dura para sempre. É preciso acompanhá-la e otimizá-la continuamente.

Checklist semanal:

1. Revise Security Events
   • Caminho: Security → Events
   • Observe: número de bloqueios, regras acionadas e distribuição dos IPs de origem.
   • Avalie: houve falso positivo? Alguma regra precisa mudar?
2. Revise o Analytics
   • Tendência do tráfego.
   • Mudanças anormais na taxa de rejeição.
   • Queda do tempo médio de permanência.
3. Revise o Google Search Console
   • Estatísticas: a frequência de rastreamento caiu?
   • Cobertura: a indexação foi afetada?
   • Erros: aumentaram os timeouts ou respostas 403?
4. Revise o feedback dos usuários
   • Suporte ou e-mail receberam relatos de dificuldade de acesso?
   • Há reclamações nas redes sociais?

Meu hábito:

Toda segunda-feira, às 10h, dedico 15 minutos a esses dados e registro os resultados em uma planilha do Excel. Se encontro algo anormal, ajusto imediatamente.

Prática 7: use um domínio dedicado para aplicativos móveis

Se você tem um aplicativo iOS ou Android, recomendo fortemente um subdomínio separado para a API.

Arquitetura:

• www.example.com — frontend do site, pode usar o modo Under Attack.
• api.example.com — API, sem o desafio.
• admin.example.com — painel administrativo, com o desafio e uma verificação adicional.

Política de segurança:

• Autentique a API com API Key ou JWT Token.
• Limite a frequência das solicitações pelo WAF.
• Use uma lista de IPs permitidos para aceitar apenas os endereços de saída do aplicativo móvel.

Vantagens:

1. A experiência no aplicativo não é afetada.
2. O frontend do site pode ativar a proteção sem receio.
3. API e frontend ficam desacoplados e mais fáceis de manter.
4. Cada domínio pode usar uma política de CDN diferente.

Projetei essa arquitetura para um cliente cujo site sofria ataques frequentes, mas cujo aplicativo tinha 200 mil usuários ativos por dia. Com um domínio dedicado à API, o site podia ativar o modo Under Attack durante um incidente sem afetar o app.

Conclusão

Depois de tudo isso, a ideia central cabe em três frases:

1. O modo Under Attack é uma ferramenta de emergência, não uma proteção rotineira

Ele se parece com o freio de emergência de um carro: pode salvar você no momento crítico, mas não dá para dirigir pisando nele o tempo inteiro. No cotidiano, Medium combinado com WAF costuma bastar; mude para I’m Under Attack apenas diante de um ataque real.

2. Page Rules são a chave para um controle preciso

Não ative o desafio no site inteiro, pois o prejuízo pode superar o benefício. Proteja apenas login, cadastro, pagamento e outros caminhos críticos, mantendo baixa interferência no restante. Com uma boa configuração, as três regras do plano gratuito são suficientes.

3. Equilibrar segurança e experiência exige ajustes contínuos

Nenhuma configuração serve para sempre. Monitore os dados e ajuste os parâmetros de acordo com o tipo de site, o comportamento dos usuários e os ataques observados. Trinta minutos de Challenge Passage são um bom ponto de partida, mas a decisão final deve vir dos seus próprios dados.

Para terminar, aqui está um checklist de ações:

• Verifique agora: qual é o nível de segurança atual na Cloudflare? Se for I’m Under Attack, avalie se ele ainda é necessário.
• Configure Page Rules: use os cenários do capítulo 3 para criar pelo menos duas regras e obter proteção precisa.
• Defina o Challenge Passage: escolha um valor entre 15 e 45 minutos de acordo com o tipo de site.
• Teste: abra uma janela anônima, visite caminhos diferentes e confirme se a configuração funciona.
• Crie um lembrete de monitoramento: revise Security Events e Analytics uma vez por semana.

Se este artigo ajudou, compartilhe-o com outros administradores que também estejam enfrentando ataques DDoS. E, se você tiver outras experiências ou dúvidas sobre o modo Under Attack da Cloudflare, deixe um comentário.