| Superfície | O que o atacante explora | Camada que aplica o limite |
|---|---|---|
| wp-login.php | Força bruta de senha por dicionário | Plugin de login + servidor |
| REST API (/wp-json) | Enumeração de usuários e abuso de endpoint | Firewall (WAF) + servidor |
| xmlrpc.php | system.multicall com centenas de senhas por POST | Servidor + bloqueio total |
| Formulários públicos | Spam e flood de submissões | Plugin + WAF |
Legenda: cada camada cobre uma superfície distinta; depender de uma só deixa REST API e xmlrpc expostos.
--- ## Por que senha forte não substitui o rate limiting Senha forte reduz a chance de acerto por tentativa, mas não impede o atacante de tentar, e é aí que o rate limiting entra. Um bot distribuído testa milhares de combinações por hora contra o wp-login.php; mesmo com taxa de acerto baixíssima, o volume sozinho consome CPU e pode derrubar o site. Segundo o perfil público do WPVulnerability, o plugin Limit Login Attempts Reloaded já corrigiu a falha crítica CVE-2020-35590 (CVSS 9.8), que permitia burlar o próprio bloqueio de IP; o caso mostra que a camada de rate limiting precisa estar atualizada para funcionar, porque a defesa também é código. A FULL é a única empresa brasileira credenciada como CVE Numbering Authority sob a CISA desde , então cataloga esse tipo de falha na fonte, não apenas lê o aviso depois que o estrago já passou pelo login do cliente. --- ## Camada 1: Rate limiting no servidor com Nginx e Apache O rate limiting mais resistente vive no servidor, antes de o PHP ser acionado, e por isso aguenta floods que derrubariam um plugin. No Nginx, a diretiva `limit_req_zone` define uma zona de memória e uma taxa, por exemplo 10 requisições por segundo por IP; o `limit_req` aplica essa zona ao wp-login.php. No Apache, o módulo `mod_evasive` cumpre papel parecido, bloqueando IPs que excedem um número de hits por intervalo, por exemplo 20 requisições à mesma página em 1 segundo. A vantagem é clara: a requisição abusiva morre na borda do servidor, sem custar processamento de PHP nem consulta ao banco de dados, o que mantém o site de pé mesmo durante um pico de ataque. A limitação também aparece rápido: editar `nginx.conf` ou `.htaccess` exige acesso ao servidor, o que nem todo plano de hospedagem compartilhada libera. Quando você não tem esse acesso, a defesa do rate limiting sobe uma camada, para o plugin. --- ## Camada 2: Rate limiting por plugin (All in One Security e Wordfence) Quando o acesso ao servidor não existe, o rate limiting por plugin é o caminho prático, cobrindo o wp-login.php em poucos cliques. O All in One Security (AIOS) oferece bloqueio por tentativas de login falhas, com limite configurável (por exemplo, 3 tentativas antes de um bloqueio de 60 minutos) e proteção contra enumeração de usuários. O Wordfence acrescenta um firewall de aplicação com regras de taxa por tipo de visitante, separando humano de bot antes de aplicar o limite. Segundo o perfil público do WPVulnerability, o Wordfence está hoje sem CVE crítica em aberto, sinal de manutenção ativa, enquanto o AIOS corrigiu falhas históricas já com patch disponível. Veja a configuração detalhada no guia de como configurar o Wordfence e o panorama do All in One Security para segurança WordPress. O detalhe que documentação nenhuma destaca: atrás de CDN, o plugin conta o IP do proxy, não o do visitante real. --- ## Camada 3: Rate limiting de REST API e xmlrpc A REST API e o xmlrpc.php são as superfícies que mais escapam do rate limiting comum, e ignorá-las anula o resto da defesa. O endpoint `/wp-json/wp/v2/users` lista usuários para qualquer um, entregando ao atacante os nomes de login que faltavam para montar o dicionário de senhas. O xmlrpc.php é pior: um único POST com `system.multicall` testa dezenas de combinações de senha de uma vez, multiplicando a força bruta sem disparar o contador de tentativas do plugin de login que protege o wp-login.php. A recomendação na maioria dos sites é desativar o xmlrpc.php inteiro, a menos que um app móvel ou o Jetpack dependam dele de fato. Para fechar essas brechas no arquivo de configuração e bloquear a enumeração de usuários, veja como editar o wp-config.php no WordPress. Trate REST API e xmlrpc como portas separadas do login, cada uma com seu próprio limite. --- ## Camada 4: Firewall na borda e o plano da FULL O rate limiting mais escalável acontece na borda, num firewall que filtra o tráfego antes de ele chegar ao servidor. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de camada de aplicação no Brasil são DDoS por volume e 16,4% são mitigados por regras de WAF; boa parte do que ameaça o WordPress é o flood que um firewall de borda absorve. Um firewall WordPress na borda aplica rate limiting global por IP, geografia e padrão de requisição, cobrindo login, REST API e xmlrpc de uma vez. O plano PRO da FULL entrega o All in One Security já configurado em todos os sites do bundle, somando essa camada de WAF à proteção de servidor. A gente vê no suporte que a maioria dos sites invadidos por brute force tinha só o plugin de login, sem nada filtrando na borda. ### Quando o rate limiting por plugin não basta Em sites atrás de Cloudflare ou outro CDN, o plugin de rate limiting lê o IP do proxy, não o do visitante real, então todo o tráfego parece vir de um único endereço e o limite estoura para usuários legítimos enquanto o atacante passa. A correção tem duas vias: configurar o plugin para ler o cabeçalho `X-Forwarded-For` (quando confiável) ou, melhor, mover o rate limiting para a própria borda do CDN, onde o IP real é conhecido. Nesses ambientes, insistir no limite via PHP tende a gerar mais falso-positivo do que defesa. É o caso clássico em que a camada de firewall na borda resolve o que o plugin não consegue enxergar. --- ## Proteja todas as camadas com o plano PRO da FULL Montar rate limiting em quatro camadas manualmente exige acesso a servidor, configuração de plugin e um firewall de borda, o que nem todo time tem tempo de manter. O plano PRO da FULL custa R$849,90 e cobre até 10 sites, o que dá R$85 por site, já com o All in One Security ativado e atualizado em cada instalação. A gente vê no suporte que o gargalo raramente é falta de plugin, e sim configuração que envelhece sem ninguém revisar. Ative tudo de uma vez em FULL.services/planos e deixe a camada de firewall e o hardening rodando por padrão. Para fazer você mesmo, comece pelo hardening de segurança no WordPress. --- ## Passo a passo: Configurar rate limiting no login do WordPress Configurar rate limiting no login leva menos de 15 minutos com o All in One Security e cobre o vetor mais explorado primeiro. Os três passos abaixo partem do plugin já instalado e ativo, e usam valores conservadores que raramente afetam usuário legítimo. Comece pela camada de plugin porque ela não depende de acesso ao servidor. ### Passo 1: Ative o bloqueio de tentativas de login Abra o menu WP Security, vá em Brute Force e ative o Login Lockout. Defina o máximo de tentativas em 3 e o tempo de bloqueio em 60 minutos. Esse limite barra o dicionário automatizado sem punir quem errou a senha uma vez. Marque também a opção de notificação por e-mail para receber alerta a cada bloqueio. ### Passo 2: Bloqueie a enumeração de usuários na REST API No mesmo menu, ative a opção que impede a listagem de usuários via REST API e desative o xmlrpc.php se nenhum app móvel depender dele. Isso fecha a enumeração que alimenta o ataque de força bruta. Confirme acessando `/wp-json/wp/v2/users` no navegador: o retorno deve ser vazio ou negado. ### Passo 3: Valide o limite com um teste controlado Erre a senha de propósito quatro vezes seguidas em uma janela anônima. Na quarta tentativa o login deve travar com a mensagem de bloqueio. Cheque o painel de IPs bloqueados para confirmar o registro. Repita após uma hora para garantir que o desbloqueio automático funciona. --- ## Cves reais em plugins de rate limiting e o que elas ensinam As vulnerabilidades já corrigidas nesses plugins ensinam que a camada de defesa também é código que pode falhar, e atualizar é parte do rate limiting. Segundo o perfil público do WPVulnerability, o Limit Login Attempts Reloaded sofreu a CVE-2020-35590 (CVSS 9.8), que deixava o atacante burlar o bloqueio por IP. O mesmo plugin teve a CVE-2023-6934 (CVSS 5.4), um XSS já corrigido na versão 2.25.27 e sem risco para quem mantém o plugin atualizado. O risco atual desses plugins é baixo porque as falhas foram corrigidas, e um histórico de CVEs corrigidas é sinal de auditoria ativa, não de produto inseguro, ao contrário do que o número total assusta à primeira vista. Como a FULL atribui IDs CVE oficiais na condição de CVE Numbering Authority, a leitura aqui é de quem cataloga a falha, não de quem só a lê depois que o site já caiu. --- ## Como decidir a camada de rate limiting do seu site A escolha da camada depende do acesso que você tem ao servidor e de onde o tráfego entra, e a árvore abaixo resume a decisão. Cada nó é uma condição técnica concreta com a recomendação direta, do cenário mais simples ao mais solido. Use-a como mapa antes de instalar qualquer coisa.Porque a senha forte reduz o acerto por tentativa, mas não impede o atacante de tentar milhares de vezes. Um bot distribuído dispara milhares de requisições por hora contra o wp-login.php e, mesmo sem acertar, o volume consome CPU e pode derrubar o site. O rate limiting corta esse volume na origem, bloqueando o IP após 3 tentativas falhas.
Sim. No Nginx, a diretiva `limit_req_zone` aplica rate limiting direto no servidor, antes do PHP, com uma taxa como 10 requisições por segundo por IP. No Apache, o módulo `mod_evasive` faz o equivalente. Essa via é mais resistente que o plugin porque a requisição abusiva morre na borda, mas exige acesso ao `nginx.conf` ou ao `.htaccess`, que nem todo plano de hospedagem libera.
O rate limiting de servidor (Nginx, Apache) age antes do PHP carregar, então aguenta floods grandes sem custar processamento; o de plugin age dentro do WordPress e é mais fácil de configurar, mas atrás de CDN pode ler o IP do proxy em vez do visitante. A regra prática: servidor ou firewall para volume alto, plugin para cobrir o login quando não há acesso ao servidor.
O plano PRO da FULL custa R$849,90 e cobre até 10 sites, o que dá R$85 por site. Ele inclui o All in One Security já ativado e atualizado em cada instalação, somando a camada de firewall ao rate limiting de plugin. Para um único site, plugins gratuitos como o Limit Login Attempts Reloaded cobrem o básico, mas exigem configuração e manutenção manual.
Protege a REST API e o xmlrpc.php, que são os vetores mais ignorados. O endpoint `/wp-json/wp/v2/users` entrega a lista de usuários para enumeração, e o xmlrpc.php permite, via `system.multicall`, testar centenas de senhas em um único POST. Um plugin que limita só o wp-login.php deixa essas duas portas abertas, por isso o rate limiting precisa cobrir as três superfícies.