O que fazer quando um site em VPS sofre um ataque CC (2026): WAF da Cloudflare, limitação de taxa no Nginx e checklist de emergência para proteger a origem

Os sinais mais intuitivos costumam ser estes:

• A CPU ou o load average do VPS sobe de repente;
• O volume de requisições de access.log está anormal, de várias a dezenas de vezes maior que o normal;
• Um determinado caminho é requisitado repetidamente, por exemplo /wp-login.php, /xmlrpc.php, /search, /api/*;
• O Nginx ainda consegue responder, mas o backend começa a retornar 502, 504;
• O Cloudflare Analytics ou o gráfico de tráfego do provedor mostra picos anormais;
• Usuários normais acessam lentamente, mas os recursos estáticos podem ainda estar normais.

Primeiro veja os IPs com maior volume de requisições recentes:

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Depois veja os caminhos mais martelados:

sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Se o seu site está atrás da Cloudflare, os logs do Nginx podem estar cheios de IPs de nós da Cloudflare, e nesse caso você precisa primeiro configurar o IP real do visitante, senão vai fazer um julgamento errado.

A prática comum no Nginx é usar CF-Connecting-IP:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
real_ip_header CF-Connecting-IP;

As faixas de IP da Cloudflare são atualizadas, então em produção recomenda-se verificar a lista oficial periodicamente. Depois de configurar, primeiro execute:

sudo nginx -t
sudo systemctl reload nginx

Se você ainda não está familiarizado com a localização de problemas nos logs, pode ler isto primeiro:

• Como ler logs de VPS: journalctl, systemctl, Nginx e logs de aplicação para localizar problemas

Se o tráfego do ataque já passa pela Cloudflare, trate-o primeiro na Cloudflare. O motivo é simples: bloquear as requisições na borda evita consumir a CPU, a memória, a banda e as conexões de banco de dados do seu VPS.

Para uma emergência temporária, você pode fazer três coisas primeiro:

1. Ativar as regras gerenciadas em Security / WAF;
2. Adicionar uma Custom Rule para os caminhos anormais;
3. Adicionar uma Rate Limiting Rule para caminhos pesados como login, busca e API.

Por exemplo, se o ataque se concentra em /wp-login.php, você pode primeiro adicionar uma regra mais rígida:

• Caminho correspondente: /wp-login.php
• Dimensão de contagem: IP
• Limite: 5-10 vezes por minuto
• Ação: Managed Challenge ou Block
• Duração do bloqueio: de 10 minutos a 1 hora

Se o que está sendo martelado é uma API, por exemplo /api/search, o limite pode ser mais folgado que o da página de login:

• 60-120 vezes por minuto;
• Retornar 429 ou Managed Challenge ao ultrapassar;
• Abrir exceções para usuários logados, monitoramento interno ou IPs confiáveis.

Não bloqueie o site inteiro de imediato. É assim que muitos sites pequenos se prejudicam: mecanismos de busca, callbacks de pagamento, sondas de monitoramento e usuários móveis normais são bloqueados juntos; o ataque é mitigado, mas o negócio também.

A documentação oficial do Cloudflare Rate Limiting também alerta: a limitação de taxa não libera com precisão um número fixo de requisições, e pode haver alguns segundos de atraso entre a contagem e o bloqueio. Por isso a origem ainda precisa de configuração de fallback.

O limit_req do Nginx usa uma abordagem parecida com "balde furado": as requisições podem ter rajadas breves, mas a taxa de longo prazo não pode ultrapassar o limite que você definir.

Primeiro defina as zonas de limitação de taxa no bloco http, normalmente colocadas em /etc/nginx/nginx.conf ou /etc/nginx/conf.d/limits.conf:

limit_req_zone $binary_remote_addr zone=site_limit:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_limit:10m;

O significado é aproximadamente:

• Páginas normais: 10 requisições por segundo por IP;
• Login/APIs sensíveis: 1 requisição por segundo por IP;
• A memória compartilhada de 10m é suficiente para rastrear uma grande quantidade de IPs;
• $binary_remote_addr usa menos memória que uma string de IP comum.

Depois aplique na configuração do site:

server {
    server_name example.com;

    limit_req zone=site_limit burst=30 nodelay;
    limit_conn addr_limit 20;
    limit_req_status 429;
    limit_conn_status 429;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location = /wp-login.php {
        limit_req zone=login_limit burst=5 nodelay;
        limit_req_status 429;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location = /xmlrpc.php {
        deny all;
    }
}

Aqui há vários detalhes importantes:

• burst=30 dá aos navegadores normais uma breve margem de rajada ao carregar uma página;
• nodelay significa que as requisições em rajada não entram na fila e são tratadas diretamente conforme a regra após ultrapassar o limite;
• limit_req_status 429 é mais claro que o 503 padrão, significa requisições demais;
• O xmlrpc.php do WordPress deve ser desativado diretamente se não for usado;
• APIs, login e páginas de busca devem ser limitados separadamente; não use um único limite para o site inteiro.

Depois de modificar, sempre teste primeiro:

sudo nginx -t
sudo systemctl reload nginx

Se você mudou recentemente a configuração do Nginx e encontrou falha no reload, pode ler isto primeiro:

• O que fazer quando a configuração do Nginx no VPS está errada: nginx -t, reload failed, proxy reverso e configuração de certificados

A limitação de taxa não é melhor quanto mais rígida.

Já vi um site pequeno limitar o site inteiro a 1r/s, e como resultado a página inicial tinha uma dúzia de recursos CSS, JS e imagens, então os usuários recebiam 429 assim que abriam a página. O ataque não foi totalmente bloqueado, mas os usuários normais ficaram de fora primeiro.

Depois de entrar no ar, primeiro veja o log de erros do Nginx:

sudo tail -f /var/log/nginx/error.log | grep "limiting requests"

Se você vir algo como:

limiting requests, excess: 12.450 by zone "site_limit", client: 203.0.113.10

significa que este IP está acionando a limitação de taxa.

Depois conte por código de status:

sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

Se os 429 de repente forem muitos, continue olhando os caminhos:

sudo awk '$9 == 429 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Se os 429 se concentram em /wp-login.php, /xmlrpc.php, /api/search, normalmente isso é bom; se a página inicial, os recursos estáticos e as verificações de saúde também recebem muitos 429, as regras estão muito grossas.

Muitas pessoas relaxam depois de colocar a Cloudflare na frente, mas se o IP de origem já vazou, os atacantes podem acessar diretamente o IP do seu VPS e contornar a Cloudflare.

Os sinais típicos dessa situação são:

• Não se vê muitas requisições na Cloudflare;
• Mas a banda do VPS e os logs do Nginx estão muito altos;
• Aparecem muitos IPs de origem que não são da Cloudflare no Nginx;
• Acessar diretamente http://你的源站IP consegue abrir o site.

No mínimo, faça duas coisas.

Primeiro, o site padrão do Nginx não deve servir diretamente o site real:

server {
    listen 80 default_server;
    server_name _;
    return 444;
}

Segundo, o firewall deve permitir apenas que IPs da Cloudflare acessem 80/443. Tenha cuidado com este passo: primeiro confirme que você consegue entrar via SSH e que as faixas de IP da Cloudflare estão completas, senão você pode derrubar seu próprio site.

Se o IP de origem já é alvo há muito tempo, a abordagem mais limpa geralmente é:

1. Abrir um novo VPS ou trocar o IP público;
2. Colocar apenas o novo IP de origem no DNS da Cloudflare;
3. Restringir o firewall para que 80/443 aceite apenas a Cloudflare;
4. Não vazar o novo IP em cabeçalhos de e-mail, repositórios Git, DNS histórico ou páginas de monitoramento.

Se o ataque causar Cloudflare 521/522, você pode consultar:

• O que fazer quando um site em VPS mostra Cloudflare 521 / 522: origem, firewall e timeouts do Nginx

Se o ataque vem de poucos IPs fixos, bloquear IPs é útil:

sudo ufw deny from 203.0.113.10

Ou usar iptables temporariamente:

sudo iptables -I INPUT -s 203.0.113.10 -j DROP

Mas se o ataque vem de centenas ou milhares de IPs, bloquear IPs manualmente é basicamente inútil. Você vai deixar a tabela de regras cada vez mais bagunçada, e a CPU ainda terá que processar uma grande quantidade de conexões.

Nesse caso, é melhor usar:

• Cloudflare WAF / Rate Limiting;
• Nginx limit_req e limit_conn;
• Fail2Ban para bloquear automaticamente IPs que acionam continuamente a limitação de taxa;
• A proteção de alta defesa do provedor ou uma proteção DDoS mais upstream.

Se você já suspeita que a máquina foi comprometida em vez de apenas inundada de requisições, primeiro siga o processo de tratamento de invasão:

• O checklist de 24 horas após um VPS ser invadido: desconectar primeiro ou preservar evidências primeiro

Se o site está sendo martelado, eu trataria nesta ordem:

1. Primeiro olhar o access.log do Nginx para confirmar os IPs de alta frequência e os caminhos de alta frequência;
2. Se passar pela Cloudflare, primeiro ativar WAF / Managed Challenge / Rate Limiting;
3. Concentrar a proteção em login, busca, API e xmlrpc.php;
4. Adicionar no Nginx limit_req, limit_conn e o código de status 429;
5. Verificar a configuração de IP real para evitar que o Nginx veja apenas IPs de nós da Cloudflare;
6. Restringir o firewall para que a origem aceite apenas acesso da Cloudflare;
7. Observar as mudanças em 429, 403, 502, 504 para evitar prejudicar usuários normais;
8. Depois que o ataque terminar, fazer uma revisão: se o IP de origem vazou, quais caminhos são os mais caros e se é necessário cache ou divisão de arquitetura.

Não trate a limitação de taxa como panaceia. Para um DDoS volumétrico realmente em grande escala, o Nginx vai saturar antes de conseguir processar, e você precisa contar com a Cloudflare, a proteção de alta defesa do provedor ou o scrubbing upstream. A limitação de taxa do Nginx é mais adequada para bloquear CC de pequeno e médio porte, crawlers maliciosos, abuso de API e força bruta de login: requisições na camada HTTP.

Quando um site em VPS sofre um ataque CC, os dois extremos são os mais perigosos: só saber reiniciar serviços, e bloquear o site inteiro de imediato.

Uma abordagem mais estável é o tratamento em camadas: a Cloudflare bloqueia o grosso na borda, o Nginx usa limit_req e limit_conn como fallback na origem, o firewall evita que o IP de origem seja contornado, e os logs observam continuamente o prejuízo a usuários normais e os caminhos de ataque.

Se você só lembrar de uma coisa: primeiro use os logs para confirmar o caminho do ataque, depois limite a taxa dos caminhos mais caros, e não limite a taxa do site inteiro às cegas.