# Bloquear IP no WordPress: 4 camadas que funcionam Bloquear IP no WordPress funciona em quatro camadas: plugin, arquivo .htaccess, firewall do servidor e borda (CDN). Segundo a WPScan (2025), a força bruta no wp-login.php segue como o vetor de acesso não autorizado mais comum. O bloqueio por aplicação para na borda em até 0 ms quando o IP vem de uma CDN. Escolha a camada pela origem real do tráfego. Bloquear IP é negar o acesso de um endereço de rede específico ao seu site antes que ele chegue ao login ou ao conteúdo. No WordPress, essa regra pode viver no plugin, no arquivo .htaccess, no firewall do servidor ou na CDN, e cada camada para o atacante num ponto diferente da requisição. A camada errada deixa o IP malicioso consumir PHP e banco antes de ser barrado. Este guia mostra como bloquear IP em quatro lugares, qual deles cabe ao seu cenário e como validar a regra. Para o panorama completo, veja o guias de segurança WordPress da FULL. --- ## Primeiros passos: Onde bloquear IP de fato resolve A decisão começa por 1 pergunta: o IP malicioso chega direto no seu servidor ou passa antes por uma CDN? Na maioria dos sites que chegam ao suporte da FULL com "bloqueio que não pega", a regra estava na camada errada para a origem do tráfego. Bloquear IP no plugin não adianta se o Cloudflare entrega todas as requisições com o mesmo IP de borda. A tabela abaixo mapeia cada camada ao ponto exato em que ela interrompe o atacante.

Bloquear IP no WordPress: 4 camadas e onde cada uma atua
Camada	Onde o IP é barrado	Quando usar
Plugin (Wordfence)	Dentro do PHP, após carregar o WordPress	Sem acesso ao servidor; gestão visual
.htaccess	No Apache, antes do PHP	Bloqueio fixo e barato de poucos IPs
Firewall do servidor	Na rede, antes do Apache	VPS própria, IP abusivo persistente
Borda (Cloudflare)	Antes de tocar sua origem	Site atrás de CDN ou sob ataque

Quanto mais cedo na cadeia o IP é barrado, menos recurso ele queima. O bloqueio na borda nem chega ao seu PHP; o bloqueio por plugin já gastou uma execução inteira do WordPress. Linke esse raciocínio ao seu caso antes de escolher a ferramenta. Quem quer um panorama de antemão pode revisar o guia de segurança no WordPress antes de aplicar a regra. ## Por que o WordPress não bloqueia IP sozinho O WordPress não traz bloqueio de IP nativo porque seu núcleo é um CMS, não um firewall: ele responde a toda requisição que o servidor entrega. Um endereço que dispara 400 tentativas de login por minuto no wp-login.php é processado normalmente até você instalar uma camada de defesa. A própria OWASP classifica a força bruta como ataque de baixo custo e alto volume, justamente por explorar endpoints abertos por padrão. Sem uma regra explícita, cada tentativa abusiva consome um ciclo de PHP e uma consulta ao banco. Por isso o brute-force derruba sites pequenos por exaustão de CPU antes mesmo de adivinhar a senha. Bloquear IP corta o problema na origem: o endereço para de ser atendido. É a diferença entre filtrar o tráfego e apenas torcer para a senha aguentar. ## Como bloquear IP no WordPress em 4 camadas Bloquear IP exige escolher entre 4 camadas e validar a regra logo após aplicá-la. Os passos abaixo vão da opção mais acessível (plugin, sem tocar no servidor) até a mais profunda (borda, antes da origem). Siga na ordem e pare na camada que cobre o seu cenário. Em sites com tráfego acima de 50 mil visitas/mês, a recomendação de campo da FULL é combinar a camada de borda com o plugin, nunca depender de uma só. ### Passo 1: Bloqueie o IP pelo plugin Wordfence O Wordfence resolve o bloqueio sem acesso a servidor: em **Wordfence > Blocking**, você cola o IP, define o motivo e salva, e o plugin passa a barrar o endereço dentro do PHP. O perfil público do WPVulnerability mostra o Wordfence com risco atual seguro, com 34 CVEs já corrigidas ao longo dos anos. Detalhe operacional: como o bloqueio acontece após o WordPress carregar, ele protege a aplicação, mas ainda gasta uma execução por requisição. Para o passo a passo de instalação, veja como configurar o Wordfence. ### Passo 2: Bloqueie o IP no arquivo .htaccess O .htaccess barra o IP antes do PHP, no nível do Apache, com três linhas. Adicione `Require all granted` seguido de `Require not ip 203.0.113.45` no topo do arquivo na raiz do site e o Apache rejeita o endereço com um 403 antes de tocar no WordPress. Esse método tende a ser o mais leve para poucos IPs fixos, porque não carrega nenhum plugin. O risco: um erro de sintaxe no .htaccess derruba o site inteiro com 500. Sempre faça backup antes; o guia de controles do .htaccess no WordPress cobre a sintaxe correta. ### Passo 3: Bloqueie o IP no firewall do servidor Em VPS própria, o firewall do sistema barra o IP na camada de rede, antes do Apache. Com fail2ban lendo os logs de acesso, um IP que estoura o limite de tentativas é banido via iptables por um tempo configurável, em geral 600 segundos. Essa camada para o atacante antes de qualquer software web responder, o que reduz o consumo de CPU em picos de força bruta. É a opção mais sólida para quem administra o servidor, mas exige acesso SSH e cuidado: banir o próprio IP por engano corta seu acesso administrativo. Combine com a regra de como evitar ataques de força bruta no login. ### Passo 4: Bloqueie o IP na borda com Cloudflare Na borda, o Cloudflare bloqueia o IP antes que ele toque sua origem, em **Security > WAF > Tools**. Você insere o endereço, escolhe a ação Block e a CDN passa a rejeitar a requisição em um dos data centers de São Paulo, Rio ou Fortaleza, sem custo de PHP para você. Segundo o Cloudflare Radar, que monitora a latência global de rede, a presença local no Brasil corta o tempo de resposta da regra. É a única camada que protege contra ataques de volume real. Veja como colocar o site atrás da CDN em configuração de CDN no WordPress. ## Cves reais: Por que bloquear IP é defesa, não cura Bloquear IP reduz a superfície de ataque, mas não corrige a falha que o atacante explora: 61 CVEs já foram catalogadas só no Elementor ao longo dos anos, sendo 3 críticas. Bloquear o IP de um atacante conhecido não fecha essa porta para os outros. Uma delas, a CVE-2023-48777 (CVSS 9.9), permitia upload arbitrário de arquivo em versões abaixo da 3.18.2, o que dava execução remota a qualquer visitante, não a um IP específico. O mesmo vale para o Contact Form 7: a CVE-2020-35489 (CVSS 10.0) permitia upload sem restrição em versões abaixo da 5.3.2. Como a FULL é a única CNA (CVE Numbering Authority) brasileira sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais, a leitura aqui é direta: bloquear IP é contenção de tráfego, atualização de plugin é a correção. As duas falhas acima já estão corrigidas , o risco atual mora em quem não atualizou. ## Erros comuns ao bloquear IP no WordPress O erro número 1, recorrente nos chamados de "bloqueei e não funcionou" no suporte da FULL, é bloquear IP por aplicação num site atrás de CDN. Quando o Cloudflare está na frente, o WordPress vê o IP da borda, não o do atacante, e a regra bane o endereço errado ou todos de uma vez. A correção é restaurar o IP real via cabeçalho `CF-Connecting-IP` antes de qualquer bloqueio por plugin ou .htaccess. O segundo erro é tratar IP estático como solução definitiva. Botnets giram milhares de endereços e o IP dinâmico residencial muda em horas, então bloquear IP avulso vira um jogo de gato e rato. A saída é combinar com limite de tentativas e, em ataques de volume, mudar para regras por país ou por reputação na borda. Para a base de hardening, consulte como fazer hardening de segurança no WordPress e o conceito de firewall WordPress. ## Como validar se o bloqueio de IP funcionou A validação leva 2 minutos e evita o falso positivo de "achei que bloqueei". Depois de aplicar a regra, acesse o site a partir do IP barrado (use uma VPN ou um proxy) e confirme o retorno: 403 Forbidden para .htaccess e borda, ou a tela de bloqueio do Wordfence para o plugin. Se a página carregar normal, a regra está na camada errada ou o IP real não foi capturado. Confirme também o log: o painel do Wordfence registra cada hit barrado com data e hora, e o Cloudflare mostra o evento em **Security > Events**. Esse rastro prova que o bloqueio está ativo e ajuda a auditar reincidência. Para um diagnóstico independente do site inteiro, rode o FULL Scan e cruze o resultado com o repositório de vulnerabilidades. ## Bloqueio gerenciado: O custo de não fazer manual Bloquear IP manualmente funciona, mas escala mal: em 150 mil sites WordPress monitorados pela FULL, a camada que mais segura ataque de volume é a gerenciada, não a regra avulsa. A gente vê no suporte que quem mantém regra a regra em vários sites acaba deixando brecha. O plano PRO da FULL entrega o Wordfence já configurado dentro do bundle, junto de outros 16 plugins premium, por R$849,90/ano. Distribuído entre os 10 sites do plano, isso dá cerca de R$85 por site por ano, abaixo do preço avulso de um único firewall premium, com firewall e bloqueio rodando sem você manter regra a regra. Conheça o pacote em FULL.services/planos. ## Próximos passos para blindar o login Bloquear IP é a primeira trava, não a última: a regra certa para no ponto certo da requisição, mas precisa de limite de tentativas, 2FA e atualização em dia para sustentar a defesa. A ordem prática é começar pela camada que cobre sua origem, validar com um 403 real e só então empilhar as defesas complementares. Quem opera o servidor ganha mais barrando o IP no firewall ou na borda; quem não tem acesso resolve bem com Wordfence e All in One Security. Para seguir aprendendo, o guia de segurança para WordPress e o FULL Academy reúnem os próximos tutoriais do tema.

Perguntas frequentes sobre bloquear IP no WordPress

É possível bloquear IP no WordPress sem instalar plugin?

Sim. O bloqueio por .htaccess dispensa qualquer plugin: três linhas com `Require not ip` no Apache barram o endereço com um 403 antes do PHP carregar. Em VPS própria, o firewall do servidor com fail2ban faz o mesmo na camada de rede. O plugin Wordfence só é necessário para quem prefere gestão visual e não tem acesso ao servidor.

Por que o bloqueio de IP não funciona quando o site usa Cloudflare?

Porque a CDN entrega toda requisição com o IP de borda, não o do atacante. O WordPress então vê um único endereço e a regra bane o IP errado ou todos os visitantes. A correção é restaurar o IP real pelo cabeçalho CF-Connecting-IP antes de bloquear, ou criar a regra direto no Cloudflare em Security > WAF, onde o IP original ainda é visível.

Qual a diferença entre bloquear IP por plugin e bloquear no servidor?

O plugin Wordfence bloqueia dentro do PHP, depois que o WordPress carrega, então ainda consome uma execução por requisição. O .htaccess e o firewall do servidor barram o IP antes do PHP, no Apache ou na rede, gastando bem menos recurso. Para ataque de volume, quanto mais cedo na cadeia o IP é barrado, melhor: a borda no Cloudflare nem toca sua origem.

Como bloquear uma faixa inteira de IPs de uma vez?

Use notação CIDR. No .htaccess, `Require not ip 203.0.113.0/24` barra os 256 endereços da faixa; no Cloudflare, o campo de IP aceita o mesmo formato em Security > WAF. Isso é útil contra botnets concentradas em um bloco de rede. Cuidado: faixas largas podem barrar usuários legítimos, então valide o alcance antes de aplicar e prefira regras por país quando o ataque for global.

Bloquear IP protege contra todas as vulnerabilidades do WordPress?

Não. Bloquear IP contém tráfego de um atacante conhecido, mas não corrige a falha. A CVE-2023-48777 do Elementor (CVSS 9.9) permitia execução remota a qualquer visitante, não a um IP único: só atualizar o plugin acima da versão 3.18.2 fecha a porta. Bloqueio de IP é contenção; atualização e hardening são a cura. As duas defesas trabalham juntas, nunca uma no lugar da outra.

Legenda: a tela Blocking do Wordfence mostra onde o IP é barrado dentro do PHP, após o WordPress carregar.