Guia de rate limiting no Cloudflare: defenda ataques CC em 5 minutos, até no plano gratuito

3 da manhã. O alerta de monitoramento do servidor me acordou: CPU em 100%, site completamente fora do ar. Ao olhar os logs, encontrei dezenas de IPs martelando endpoints, com centenas de requisições por segundo. Era um ataque CC.

Comecei a bloquear IP na pressa, mas logo apareciam novos IPs. Não dava para vencer no braço. Depois de duas horas, lembrei que o Cloudflare deveria ter alguma proteção. Abri o painel, vi Rate Limiting e, para minha surpresa, o plano gratuito já dava para usar. Configurei uma regra limitando um único IP a no máximo 20 requisições por minuto; acima disso, bloqueio por 10 minutos. Em 5 minutos, o tráfego de ataque ficou do lado de fora.

Defender ataque CC não precisa ser complicado. O ponto é configurar rate limiting antes da crise. Neste artigo, vamos ver como usar o rate limiting do Cloudflare, como o plano gratuito funciona, quais limites escolher, como configurar cada cenário e quais armadilhas evitar.

O que é ataque CC? Por que rate limiting consegue bloquear

Primeiro, o básico: CC significa Challenge Collapsar. Em termos simples, é simular um monte de usuários normais acessando seu site sem parar até esgotar os recursos do servidor.

Você talvez pense: isso não é DDoS? Não exatamente. Um DDoS tradicional costuma ser mais bruto, enviando grandes volumes de pacotes inúteis. O padrão é evidente, e a proteção DDoS automática do Cloudflare normalmente segura. Ataque CC é mais esperto: ele envia requisições HTTP normais, como se fossem visitas reais, então a defesa DDoS tradicional pode não perceber.

Um exemplo: um usuário normal talvez clique em algumas páginas em 1 minuto e gere algo como 5 a 10 requisições. Em um ataque CC, um único IP pode disparar mais de 1000 requisições em 30 segundos. E o atacante costuma usar muitas máquinas, ou proxies, para espalhar o tráfego. Fica mais difícil de bloquear.

Rate limiting foi feito justamente para esse padrão. A lógica é simples: monitorar a frequência de requisições de cada IP, sessão, chave de API ou outro identificador. Se passar do limite que você definiu, o Cloudflare toma uma ação: pode mostrar um desafio para provar que é uma pessoa real ou bloquear por um período.

No ataque que eu enfrentei, os IPs do atacante faziam 200 a 300 requisições por segundo. O meu limite era 20 por minuto. Com isso, o tráfego malicioso acionava a regra nos primeiros 1 ou 2 segundos, e o restante ficava bloqueado. Usuário normal nem chegava perto desse limite, então a experiência não era afetada.

Um dado útil: a documentação de melhores práticas do Alibaba Cloud WAF menciona que, em ataques CC típicos, uma única máquina zumbi pode gerar mais de 1000 requisições em 30 segundos, enquanto um usuário normal costuma ficar abaixo de 10 por minuto.

A diferença é grande.

Aqui surge uma preocupação legítima: e se um usuário normal operar rápido demais? Por exemplo, uma interface que atualiza dados de API em sequência? Esse risco existe, por isso o limite precisa ser definido com cuidado. A seguir, entro nos valores por cenário.

O plano gratuito também funciona: entendendo o rate limiting do Cloudflare

Esse ponto merece destaque, porque muita gente, inclusive eu antes, achava que rate limiting era recurso pago. Desde outubro de 2022, o Cloudflare abriu o rate limiting gratuitamente para todos os usuários, incluindo os planos Free, Pro e Business.

Antes era diferente. Até 2022, para usar rate limiting, você pagava por tráfego: US$ 5 por milhão de requisições. Para um site com volume alto, isso podia virar uma conta relevante. Foi por isso que eu adiei esse recurso por um bom tempo.

Agora não precisa mais se preocupar com isso. O Cloudflare anunciou no blog oficial que as regras de rate limiting passaram a estar incluídas em todos os planos, sem cobrança extra. Usuários do plano gratuito podem criar 1 regra de rate limiting; Pro e Business permitem mais.

Você pode perguntar: só 1 regra basta? Para sites pequenos e médios, sim, muitas vezes basta. O segredo é usar essa regra no lugar mais vulnerável: login, cadastro ou API central.

Em alguns projetos pequenos meus, usei exatamente isso: uma única regra protegendo o endpoint de login. Rodou por quase um ano sem grandes problemas. Ataques pequenos de varredura também foram barrados.

Claro, se seu negócio tem muitos endpoints críticos, talvez faça sentido subir para Pro ou Business. O Pro custa US$ 20 por mês e permite 10 regras; o Business custa US$ 200 por mês e permite 15. Mas para site pessoal e empresa pequena, a regra gratuita costuma resolver boa parte do problema.

Mais um detalhe: embora o plano gratuito tenha só 1 regra de rate limiting, a proteção DDoS básica do Cloudflare está incluída em todos os planos e não limita tráfego. Ataques DDoS evidentes tendem a ser bloqueados automaticamente. O rate limiting é mais útil contra ataques CC discretos e abuso de API.

Principais diferenças entre plano gratuito e pago:

• Quantidade de regras: Free 1, Pro 10, Business 15
• Recursos avançados: planos pagos podem usar condições mais complexas, como Bot Score e impressão digital JA3
• Tempo de resposta: planos pagos respondem melhor em alto tráfego

Para quem está começando, eu sugiro testar primeiro no plano gratuito. Proteja o endpoint mais importante, deixe rodar um tempo e veja o resultado. Se precisar de mais regras, aí sim considere upgrade.

Como definir o limite? Sugestões por cenário

Esse foi o ponto que mais me travou na primeira configuração. Eu olhava para o campo “Requests per period” e ficava na dúvida: 10 ou 100? Baixo demais bloqueia usuário real; alto demais não segura ataque.

Depois de ler a documentação do Cloudflare, algumas práticas de provedores grandes e comparar com meus próprios logs, cheguei a algumas referências. Trate esses números como ponto de partida; ajuste conforme o tráfego real do seu site.

Login/cadastro (o alvo mais comum)

Login é zona sensível. Ele costuma ser usado para força bruta e credential stuffing. A característica é clara: usuário normal acessa pouco; ataque gera muito tráfego.

Configuração recomendada em três camadas:

O Cloudflare recomenda uma regra em camadas, que bloqueia ataque sem machucar usuários reais:

• Camada 1: 4 requisições/minuto → JavaScript Challenge
• Camada 2: 10 requisições/10 minutos → CAPTCHA
• Camada 3: 20 requisições/hora → bloqueio por 1 dia

Mas o plano gratuito só oferece 1 regra. Então precisamos simplificar:

• Configuração de camada única: 20 requisições/60 segundos → bloqueio por 10 minutos

Como cheguei a esse limite? Revendo logs do meu site, percebi que um usuário normal, mesmo errando senha e tentando de novo, raramente passa de 5 tentativas em 1 minuto. Um script de ataque dispara centenas ou milhares. Então 20 por minuto bloqueia a maioria dos ataques e ainda preserva usuários normais.

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Se o seu site exige segurança mais rígida:

• Modo estrito: 10 requisições/60 segundos → bloqueio por 1 hora

API (ajuste conforme a regra de negócio)

API varia muito. Cada tipo tem um padrão de acesso.

API de consulta comum:

• Configuração recomendada: 30 requisições/10 segundos → JavaScript Challenge

Esse limite equivale a 3 requisições por segundo, suficiente para a maioria das aplicações frontend normais. Mesmo uma atualização rápida não deve virar bloqueio imediato.

API intensiva em CPU (por exemplo, processamento de imagem ou análise de dados):

• Configuração recomendada: 10 requisições/60 segundos → limite mais rígido

Esse tipo de API consome mais recurso do servidor, então o limite precisa ser menor. Dez chamadas por minuto costuma ser suficiente para uso normal e já reduz abuso.

API pública (serviço oferecido para terceiros):

• Configuração recomendada: defina conforme seu modelo de cobrança e capacidade de recursos

Se você oferece API gratuita, pode usar 100 requisições/hora. Se é uma API paga, ajuste por nível de plano.

O Google Cloud Armor tem um caso de referência: para APIs, eles sugerem 2000 requisições/20 minutos e, ao exceder, limitar 20% do tráfego. Esse modelo progressivo também vale como inspiração.

Páginas comuns (proteção contra scraping)

Páginas comuns têm frequência menor que API, mas ainda podem sofrer scraping agressivo.

Configuração recomendada:

• Páginas normais: 100 requisições/30 segundos → JavaScript Challenge
• Páginas especiais (busca, download etc.): 50 requisições/60 segundos → CAPTCHA

Por que o limite de páginas comuns é tão alto? Porque um usuário normal pode clicar em vários links rapidamente, e cada página traz CSS, JS, imagens e outros recursos. Uma única página pode gerar dezenas de requisições. Por isso, 100 em 30 segundos não deve afetar navegação normal.

Para crawler agressivo, porém, 100 requisições em 30 segundos ainda é rápido demais e costuma ser barrado.

Atenção especial: não coloque limite rígido demais na home. Eu já caí nessa: apliquei rate limiting agressivo na página inicial e acabei bloqueando crawlers do Google e do Bing. O ranking SEO caiu direto. Removi a regra da home e só então a situação se recuperou.

Referência prática

A documentação de melhores práticas do Alibaba Cloud WAF traz uma configuração preventiva para sites pequenos e médios:

• Quando um único IP passa de 1000 acessos em 30 segundos → bloqueio por 10 horas

É uma configuração mais folgada, boa como proteção de retaguarda. Se você não sabe por onde começar, use algo assim e ajuste pelos logs reais.

Outra dica: depois de criar a regra, não comece direto com “Block”. Use “Managed Challenge” no início. Assim, se o limite ficou um pouco baixo, usuários reais ainda conseguem passar pelo desafio em vez de serem bloqueados. Depois de observar por um tempo e confirmar que não há falso positivo, mude para “Block”.

Tutorial de configuração em 5 minutos

Chega de teoria; vamos para a prática. Configurar uma regra de rate limiting é simples mesmo. Dá para terminar em 5 minutos.

Passo 1: entre na página de Rate Limiting

Faça login no painel do Cloudflare, escolha o domínio e siga este caminho:

Security → WAF → Rate limiting rules

Se você nunca configurou antes, deve ver um botão “Create rule”. No plano gratuito, a tela mostra “0/1 rules”, indicando que ainda dá para criar 1 regra.

Passo 2: preencha as informações básicas

Depois de clicar em “Create rule”, você verá uma tela de configuração. Comece pelo topo:

Rule name (nome da regra):

Use um nome que faça sentido, como “Login-Rate-Limit” ou “API-Protection”. Se no futuro houver várias regras, fica mais fácil encontrar.

Passo 3: configure a condição de correspondência (Expression)

Esta etapa diz ao Cloudflare quais requisições devem ser monitoradas pela regra.

Se você quer proteger o endpoint de login, configure assim:

Field: URI Path
Operator: equals
Value: /api/login

Isso monitora apenas requisições para o caminho /api/login.

Se você quer proteger a API inteira, use correspondência por inclusão:

Field: URI Path
Operator: contains
Value: /api/

Assim, todos os caminhos que começam com /api/ serão monitorados.

Você também pode adicionar condições extras. Por exemplo, para excluir um User-Agent específico, como um script seu de monitoramento, clique em “And” e adicione:

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

Passo 4: defina os parâmetros de rate limiting (o núcleo)

Esta é a parte mais importante. Ela decide quando a regra dispara.

Characteristics (característica de contagem):

Escolha como identificar e contar requisições. As opções mais comuns:

• IP Address: conta pelo IP do visitante (recomendado, primeira escolha contra ataque CC)
• Session: conta pelo ID de sessão no Cookie (bom para usuários logados)
• Headers: conta por cabeçalho HTTP, como API Key (bom para proteção de API)

Para proteger login, IP Address costuma bastar.

Period (janela de tempo):

Escolha uma janela no menu, como 10, 30 ou 60 segundos.

Eu geralmente uso 60 seconds, ou 1 minuto. Janela curta demais, como 10 segundos, pode gerar falso positivo. Janela longa demais, como 10 minutos, pode reduzir a efetividade.

Requests per period (limite de requisições):

É o limite dentro da janela. Pelas recomendações acima, login pode usar 20; API pode usar 30.

Duration (duração do bloqueio):

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

Ganhar 15% off →Anúncio

Quanto tempo bloquear depois que o limite é ultrapassado. As opções vão de 1 minuto a 24 horas.

Eu normalmente uso 10 minutes. Tempo curto demais deixa o atacante voltar logo; longo demais pode incomodar usuário real em falso positivo.

Um exemplo completo para proteger login:

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Ou seja: se o mesmo IP acessar o endpoint de login mais de 20 vezes em 1 minuto, esse IP fica bloqueado por 10 minutos.

Passo 5: escolha a ação de resposta (Action)

Quando o limite dispara, o que fazer com essas requisições?

Managed Challenge (desafio gerenciado) - minha primeira escolha:

O Cloudflare decide automaticamente se é pessoa real ou automação. Uma pessoa pode ver uma página de verificação, às vezes passa direto. Bots ficam bloqueados. É a opção com melhor experiência e menor impacto em falso positivo.

Block (bloqueio direto):

Retorna erro 403 e nega acesso. É mais forte, mas se houver falso positivo fica mais chato. Use depois de confirmar que a regra está correta.

Legacy CAPTCHA (CAPTCHA tradicional):

Mostra um CAPTCHA. O usuário precisa resolver para continuar. A experiência é mais pesada, mas separa pessoas reais de bots.

JS Challenge (JavaScript Challenge):

Envia JavaScript para o cliente executar e valida se é um navegador real. Funciona contra crawlers e quase não aparece para usuários normais.

Minha sugestão: comece com Managed Challenge, deixe rodar por um tempo, confirme que não há problema e depois mude para Block se quiser endurecer.

Passo 6: salve e habilite

Depois de configurar, role até o final e clique em “Deploy”. A regra entra em vigor imediatamente.

Passo 7: valide se a regra está funcionando

Depois de configurar, faça um teste simples. Use curl ou o navegador para acessar várias vezes:

for i in {1..30}; do curl https://yourdomain.com/api/login; done

Se estiver correto, as primeiras 20 requisições devem passar. A partir da 21ª, você deve receber status 429 ou ver uma página de desafio.

Você também pode abrir Security → Events no painel do Cloudflare e conferir os logs de bloqueio.

Exemplo completo de configuração

Suponha que eu queira proteger o endpoint de login /api/auth/login. Minha configuração ficaria assim:

Informações básicas:

• Rule name: Login-Rate-Limit

Condição de correspondência:

• URI Path equals /api/auth/login

Parâmetros de rate limiting:

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

Ação de resposta:

• Action: Managed Challenge

Clique em Deploy. Pronto. O processo inteiro realmente cabe em 5 minutos.

Técnicas avançadas e armadilhas comuns

Configurar uma regra de rate limiting parece simples, mas há algumas pegadinhas na prática. Aqui vão as que eu já encontrei e algumas técnicas úteis.

Armadilha 1: prejudicar crawlers de SEO

Já falei disso acima, mas vale repetir.

Não coloque rate limiting agressivo na home ou no site inteiro.

Em um projeto, por economia de tempo, configurei uma regra para o site inteiro: mais de 50 requisições em 30 segundos, bloqueia. Depois de uma semana, o Google Search Console começou a mostrar muitos erros de rastreamento. Ao investigar, vi que o crawler do Google buscava CSS, JS, imagens e outros recursos ao mesmo tempo, acionando o limite com facilidade.

Depois mudei a regra para proteger apenas login e API. Páginas comuns ficaram sem limite rígido, e o problema sumiu.

Recomendação:

• Login, cadastro e API sensível: limite rígido
• Páginas de conteúdo: limite folgado ou nenhum limite
• Home: evite limitar

Se você realmente precisa impedir scraping de conteúdo, use Bot Management do Cloudflare, que é pago. Ele consegue diferenciar crawler legítimo, como Google, de crawler malicioso.

Armadilha 2: o atacante contorna o rate limiting

Um amigo configurou rate limiting e ainda assim sofreu um ataque CC forte. Depois descobriram o motivo: o atacante contornou o Cloudflare e atacou diretamente o IP real do servidor.

Por que isso acontece?

O Cloudflare é um proxy reverso. Ele fica na frente do seu servidor. Mas, se o atacante sabe o IP real da origem, pode acessar o servidor diretamente e pular o Cloudflare.

Como resolver:

1. Permita no firewall do servidor apenas IPs do Cloudflare

O Cloudflare fornece listas oficiais de IPs IPv4 e IPv6. Configure o firewall para permitir apenas esses IPs nas portas 80 e 443.

Em um servidor Linux, dá para usar um script como este:

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

Começar agora →Anúncio

# Permitir acesso apenas de IPs da Cloudflare
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. Troque periodicamente o IP de origem

Se o IP de origem já vazou, considere trocá-lo. Também evite expor o IP real diretamente no DNS.

3. Use Authenticated Origin Pulls do Cloudflare

É uma solução mais avançada. Ela exige que o cliente apresente o certificado do Cloudflare, garantindo que a requisição realmente veio pelo Cloudflare.

Armadilha 3: esquecer monitoramento e ajuste

Regra de rate limiting não é algo que você configura uma vez e nunca mais olha.

Já vi gente criar a regra e abandonar. O resultado:

• Limite baixo demais, bloqueando usuários reais e gerando chamados sem que o suporte entenda
• Tráfego do negócio cresceu, e o limite antigo ficou inadequado
• O padrão de ataque mudou, a regra não acompanhou e a proteção caiu

Recomendação:

Verifique o Security Analytics do Cloudflare periodicamente, por exemplo uma vez por mês:

• Quantas requisições foram bloqueadas
• Se houve falso positivo claro, com usuários normais acionando limite
• Se a taxa de erro 429 está anormal

Ajuste o limite conforme os dados:

• Se há poucos erros 429, considere reduzir o limite para melhorar a proteção
• Se há muitos erros 429, talvez seja preciso aumentar o limite ou ajustar a regra

Técnica 1: lidar com ataques distribuídos

Ataques CC atuais estão mais inteligentes. O atacante usa muitos proxies, cada IP com baixa frequência de requisições. Um limite simples por IP pode não bloquear.

Algumas formas de lidar com ataques distribuídos:

1. Contar por Session/Cookie (em vez de IP)

Se seu site tem mecanismo de sessão, use o Session ID para contar. Mesmo que o atacante troque de IP, o Session ID permanece, e ele ainda pode ser bloqueado.

Na configuração, escolha Cookie em Characteristics e informe o nome do seu Session Cookie.

2. Combinar com filtro de User-Agent

Muitos scripts de ataque têm User-Agent estranho, com marcas como “Python” ou “curl”. Você pode adicionar filtro de User-Agent na condição de correspondência.

3. Usar Bot Management (recurso pago)

É a opção mais forte. O Cloudflare dá uma pontuação de 1 a 100 para cada requisição; quanto menor, maior a chance de ser bot. Você pode criar uma regra para aplicar rate limiting apenas quando Bot Score < 30.

Esse recurso exige plano Business ou Enterprise, então não é para todo mundo.

Técnica 2: estratégia de resposta progressiva (plano pago)

Antes mencionei a proteção em três camadas recomendada pelo Cloudflare. Mesmo que o plano gratuito tenha só 1 regra, usuários pagos podem testar essa estratégia:

Camada 1 (folga):

• Limite: alto, por exemplo 30 requisições/minuto
• Ação: JS Challenge, quase sem percepção

Camada 2 (média):

• Limite: intermediário, por exemplo 50 requisições/10 minutos
• Ação: Managed Challenge, talvez exigindo verificação

Camada 3 (rígida):

• Limite: baixo, por exemplo 100 requisições/hora
• Ação: Block por 24 horas

Assim você dá mais chances a usuários reais e aumenta a punição para atacantes persistentes.

Técnica 3: proteção por região específica

Se seu negócio atua principalmente na China, você pode aplicar limites mais rígidos para tráfego de fora do país.

Adicione uma condição geográfica na Expression:

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

Assim, o limite rígido vale apenas para IPs fora da China, sem afetar usuários domésticos.

Mas atenção: alguns usuários legítimos podem usar VPN e serem tratados como tráfego externo. Por isso, ainda recomendo Challenge em vez de Block direto.

Para fechar

Depois de tudo isso, a ideia central cabe em uma frase: configurar rate limiting não é difícil; o importante é fazer antes do ataque, não quando o servidor já está no chão.

Já vi muita gente acordar de madrugada com alerta e só então começar a pesquisar proteção. Essa sensação de correr atrás no susto é péssima. Se você gastar 5 minutos antes e deixar uma regra pronta, dorme muito mais tranquilo.

Minha sugestão prática:

1. Configure uma regra agora, mesmo que seu site nunca tenha sido atacado. Prevenir é melhor do que improvisar no meio da crise.
2. Comece pelo endpoint de login. Se você só tem 1 regra gratuita, use em login ou cadastro. É um dos pontos mais atacados e mais importantes.
3. Teste depois de configurar. Use curl ou atualize rapidamente pelo navegador para confirmar que a regra dispara. Depois veja os logs em Security Events.
4. Revise periodicamente. Coloque um lembrete mensal para abrir Security Analytics e ajustar o limite conforme o tráfego real.

Um último lembrete: configure o firewall do servidor para aceitar acesso apenas de IPs do Cloudflare. Se o atacante contornar o Cloudflare e bater direto na origem, nenhuma regra no painel vai ajudar.

Se encontrar problema durante a configuração, consulte a documentação oficial do Cloudflare ou procure no fórum da comunidade. A maioria dos problemas já apareceu para alguém, e normalmente há uma solução.

Espero que este guia ajude você a configurar rate limiting sem tropeços e a manter seu site longe do sufoco dos ataques CC.