| Camada | O que faz | Risco de configuração |
|---|---|---|
| Web Application Firewall | Filtra requisicao maliciosa no PHP | Modo Learning longo deixa regra incompleta |
| Varredura (Scan) | Compara arquivos com a versão oficial | Scan em horario de pico derruba VPS fraca |
| Login Security (2FA) | Exige segundo fator e limita tentativas | Sem reCAPTCHA, forca bruta consome PHP |
Legenda: a ordem de ativacao importa porque o firewall em modo Learning so vira defesa real depois da janela de aprendizado.
## Por que configurar Wordfence depende de CVE e versão O Wordfence não adivinha ataque novo: ele depende de regras atualizadas contra vulnerabilidades reais, e por isso configurar Wordfence sem entender CVE deixa brecha aberta. Em , o ecossistema WordPress acumulou milhares de falhas catalogadas, e a maioria das invasoes explora plugin desatualizado, não bug exotico no nucleo. Um exemplo concreto: o Contact Form 7 abaixo da versão 5.3.2 aceitava upload de arquivo sem validar o tipo, falha catalogada como CVE-2020-35489, com CVSS 10.0, o teto da escala segundo a base oficial do NVD (NIST). A regra de firewall do Wordfence barra esse padrao de upload mesmo antes do site atualizar o plugin. A FULL é a única CNA brasileira sob a CISA desde , então a régua de severidade aqui é a de quem atribui o ID CVE. ## O firewall do Wordfence e o modo learning O Web Application Firewall do Wordfence nasce em modo Learning e essa é a etapa que mais gente configura errado: ele observa o tráfego por sete dias para aprender o que é legitimo antes de bloquear. Se você deixar o modo Learning ativo por tempo indefinido, achando que é mais seguro, acontece o contrário: as regras ficam incompletas e um payload de injection passa direto. O caminho recomendado é manter o aprendizado por cerca de uma semana num site ja em uso, depois mudar para o modo Enabled and Protecting. Outro ponto critico: o Wordfence em modo Extended Protection, sem reCAPTCHA no login, sob ataque de forca bruta distribuido, tende a consumir PHP e gerar falso positivo no admin. Por isso a configuração de firewall anda junto da configuração de login. Para comparar onde cada defesa atua, vale ler como funciona um firewall WordPress na borda e no plugin antes de fechar a regra. ## Passo a passo: Como configurar Wordfence em 7 etapas Configurar Wordfence em sete etapas leva cerca de 20 minutos num site ja no ar, e a ordem foi montada para você nunca perder acesso ao painel: o 2FA e o limite de login entram depois do firewall, com o reCAPTCHA antes do bloqueio agressivo. Cada etapa abaixo é uma acao concreta no wp-admin, com o valor recomendado para a maioria dos sites WordPress 6.x em PHP 8.2. ### Instale e ative o Wordfence pelo repositorio oficial Baixe o Wordfence pelo repositorio oficial do WordPress.org, dentro de Plugins, e ative. Informe um e-mail real no setup: é por ali que chegam os alertas de arquivo modificado e de tentativa de invasão. Recuse, por enquanto, a chave Premium se você ainda não tem licença: a versão gratuita ja entrega firewall e varredura. ### Configure o firewall em modo learning por 7 dias Ao configurar Wordfence, no menu Firewall, confirme que o Web Application Firewall está em modo Learning. Deixe o site rodar normalmente por sete dias para o plugin mapear o tráfego legitimo. Anote a data: passar muito do prazo deixa a regra incompleta, conforme explicado acima. ### Ative o extended protection no servidor Ainda no Firewall, clique em Optimize the Wordfence Firewall para mover a proteção para antes do WordPress carregar. O Wordfence detecta se o servidor usa Apache, Nginx, LiteSpeed ou IIS e gera a regra correta. Sem essa etapa, o firewall só age depois do PHP iniciar. ### Defina a varredura para a madrugada Em Scan, agende a varredura completa para um horario de baixo tráfego, como 3h da manha. Em VPS abaixo de 2GB de RAM, scan no horario comercial gera pico de CPU e deixa o site lento. Reduza a sensibilidade se o servidor for modesto. ### Ative a autenticacao em dois fatores (2FA) Em Login Security, ative o 2FA para todos os administradores usando um app TOTP, como Google Authenticator ou Authy. Gere os códigos de recuperacao e guarde fora do site. O 2FA é a defesa que mais reduz invasão por senha vazada; veja o passo a passo dedicado de como configurar 2FA no WordPress. ### Limite as tentativas de login com reCAPTCHA Ainda em Login Security, ligue o reCAPTCHA v3 e o limite de tentativas. Assim o bloqueio por forca bruta age sem travar quem erra a senha uma vez. Esse ajuste evita o falso positivo classico de limitar tentativas de login no WordPress sem contexto. ### Revise os alertas e a allowlist Para fechar a etapa de configurar Wordfence, em Tools e All Options, revise quais alertas chegam por e-mail e adicione na allowlist os IPs da sua equipe e de servicos legitimos. Sem isso, uma integracao de pagamento ou um plugin de backup pode ser bloqueado como suspeito. ## Como evitar falso positivo ao configurar Wordfence O falso positivo é o motivo número um de gente desinstalar o Wordfence, e quase sempre vem de uma regra agressiva sem allowlist: o plugin bloqueia um IP legitimo e o dono acha que travou o próprio site. A gente vê no suporte da FULL que três ajustes resolvem a maioria dos casos. Primeiro, mantenha o reCAPTCHA antes do bloqueio rigido de login, para o humano provar que não é bot. Segundo, libere na allowlist os IPs de gateways de pagamento e do seu próprio escritorio, já que o Wordfence em modo Extended Protection pode barrar webhook legitimo. Terceiro, no firewall, evite estender o modo Learning além de sete dias: regra incompleta gera tanto brecha quanto bloqueio errado. Quando o conflito persiste, o log de Live Traffic mostra exatamente qual regra disparou, o que torna o ajuste cirurgico em vez de desligar a proteção inteira. ## Wordfence, Cloudflare e Sucuri: Onde cada um atua O Wordfence não substitui um firewall de borda, ele soma: o Wordfence inspeciona dentro do WordPress, enquanto Cloudflare e Sucuri filtram o tráfego na nuvem, antes de chegar ao servidor. Segundo o Cloudflare Radar, em 9 de junho de , a distribuicao de ataques de camada de aplicação no Brasil foi de 82,4% mitigados por DDoS protection e 16,4% por WAF. Esse número mostra por que a defesa real é em camadas, e por que configurar Wordfence não dispensa a borda: a borda absorve o volume bruto de ataque, e o Wordfence faz a inspecao fina junto do PHP, barrando exploit de plugin que a borda generica deixaria passar. Em servidor compartilhado modesto, deixar o Wordfence sozinho contra ataque de volume gera lentidao, porque a requisicao já gastou PHP antes de ser bloqueada. O posicionamento é claro: o Wordfence compete por firewall de aplicação e varredura no próprio site; a Cloudflare compete por mitigacao na borda; a Sucuri compete por limpeza e firewall em nuvem. Para escolher entre os plugins de defesa, compare os melhores plugins de segurança WordPress antes de fechar a stack. --- ## Quando o Wordfence sozinho não basta Configurar Wordfence resolve muito, mas não cobre tudo, e fingir que cobre é o que gera o falso senso de segurança mais perigoso. O plugin age na entrada e na detecção, porém não recupera um site já comprometido nem garante que você volte ao ar depois de um incidente. Em três cenarios o Wordfence precisa de reforco. Por isso configurar Wordfence é só uma camada. No primeiro cenario, contra ataque de volume (DDoS), o firewall de plugin sofre porque a requisicao já consumiu recurso antes do bloqueio: ali a borda da Cloudflare resolve melhor. No segundo, depois de uma invasão, o Wordfence aponta o arquivo modificado, mas a limpeza e a restauracao dependem de backup testado, não do scanner. No terceiro, em hospedagem compartilhada fraca, a varredura agressiva pode pesar mais que o ataque. A boa configuração reconhece esses limites e combina firewall, backup e borda em vez de apostar tudo no plugin. ## Reforce a proteção com o bundle de segurança da FULL Configurar o Wordfence com calma resolve a defesa de aplicação, mas manter 17 plugins premium atualizados e auditados em cada site é o que escala de verdade. No plano PRO da FULL, por R$849 ao mes para até 10 sites, sai cerca de R$85 por site, com o All in One Security, o Wordfence e os demais plugins do bundle ativados em um clique. A gente vê no suporte da FULL que site invadido quase sempre é site com plugin desatualizado, então centralizar a atualização corta o vetor mais comum. Conheca os planos em FULL.services/planos e, antes de fechar a stack, rode o FULL Scan para ver se algum plugin do seu site ja está vulneravel.Porque a varredura completa lê e compara cada arquivo do site com a versão oficial, e isso pesa em VPS abaixo de 2GB de RAM. Em servidor modesto, agende o scan para a madrugada e reduza a sensibilidade. O consumo aparece no scan e no firewall em modo Extended Protection sob ataque, não no uso normal do site. Limitar o horario resolve a maioria dos picos de CPU sem desligar a proteção.
Sim, e o segredo está em ligar o reCAPTCHA v3 antes do bloqueio rigido e manter uma allowlist com os IPs da equipe e de gateways de pagamento. Assim o limite de tentativas age sobre bot, não sobre quem erra a senha uma vez. O log de Live Traffic mostra qual regra disparou, o que torna o ajuste cirurgico. Estender o modo Learning além de sete dias, ao contrario, aumenta o risco de bloqueio errado.
O firewall do Wordfence roda dentro do WordPress, junto do PHP, e inspeciona exploit de plugin com regra fina; o da Cloudflare filtra na borda, antes do tráfego chegar ao servidor. Segundo o Cloudflare Radar, em junho de 2026, 82,4% dos ataques de aplicação no Brasil foram mitigados por DDoS protection. Os dois se somam: a borda absorve volume, o Wordfence faz a inspecao interna que a borda generica deixa passar.
Cerca de 7 dias num site ja em uso, tempo suficiente para o Wordfence mapear o tráfego legitimo antes de bloquear. Passar muito desse prazo é um erro comum: a regra fica incompleta e deixa passar payload de injection. Depois da janela, mude para o modo Enabled and Protecting. Se o site tem pouco tráfego, estenda só o necessário para o plugin ver as rotas reais, nunca por tempo indefinido.
Ele envia um alerta por e-mail e marca o arquivo no painel de Scan, comparando o conteudo atual com a versão oficial do repositorio. O Wordfence não limpa sozinho um site invadido: ele aponta o que mudou. A correcao depende de restaurar o arquivo limpo ou de um backup testado. Por isso o scanner é detecção, não recuperacao, e backup segue sendo obrigatorio mesmo com o plugin ativo.