Guia para proteger wp-admin contra bots sem plugin

16 min de leitura  ·  Guia técnico

Proteger o wp-admin contra bots sem plugin significa configurar restrições de acesso diretamente no servidor web — Nginx ou Apache — antes que qualquer requisição chegue ao PHP ou ao WordPress. Para aplicar essa proteção, siga estes passos:

1. Identifique o servidor web em uso (Nginx ou Apache) e localize o arquivo de configuração do seu site WordPress.
2. Configure rate limiting no bloco location do wp-login.php para limitar requisições por IP.
3. Adicione autenticação HTTP Basic ao diretório wp-admin com htpasswd.
4. Restrinja o acesso ao wp-admin apenas a IPs autorizados usando diretivas allow e deny.
5. Exclua o admin-ajax.php das restrições para não quebrar funcionalidades do WordPress.
6. Recarregue o servidor web e valide o comportamento com ferramentas de teste.

Pré-requisitos para proteger o wp-admin contra bots no servidor

• Acesso root ou sudo ao servidor (VPS ou dedicado) com Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9 ou AlmaLinux 9.
• Nginx 1.18+ ou Apache 2.4+ instalado e configurando o site WordPress.
• WordPress instalado e funcionando com PHP-FPM (PHP 8.1, 8.2 ou 8.3).
• Utilitário apache2-utils (para htpasswd) instalado — necessário mesmo no Nginx.
• Conhecimento do IP fixo ou range CIDR dos administradores do site.
• Acesso SSH ao servidor — veja como em Acessando servidores VPS Linux da AviraHost.

Como bloquear bots no wp-login.php com rate limiting no Nginx

O rate limiting no Nginx é a primeira linha de defesa contra ataques de força bruta ao painel WordPress. A diretiva limit_req_zone cria uma zona de memória compartilhada que rastreia o número de requisições por IP em uma janela de tempo, e limit_req aplica esse limite ao endpoint específico.

Abra o arquivo de configuração principal do Nginx (geralmente em /etc/nginx/nginx.conf) e adicione a zona de rate limiting dentro do bloco http:

http {
    limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;
    ...
}

Essa configuração cria uma zona chamada wplogin com 10 MB de memória (suficiente para rastrear cerca de 160 mil IPs) e permite no máximo 5 requisições por minuto por IP.

Em seguida, no arquivo de configuração do seu site (por exemplo, /etc/nginx/sites-available/seusite.conf), adicione o bloco location para o wp-login.php:

server {
    ...

    location = /wp-login.php {
        limit_req zone=wplogin burst=2 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;
    }

    ...
}

O parâmetro burst=2 permite até 2 requisições extras em rajada antes de rejeitar, e nodelay garante que essas requisições em burst sejam processadas imediatamente sem enfileiramento. O status 429 (Too Many Requests) é retornado para IPs que excedem o limite.

Valide a configuração e recarregue o Nginx:

nginx -t && systemctl reload nginx

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Para testar, use curl em loop e observe o retorno 429 após exceder o limite:

for i in {1..10}; do curl -o /dev/null -s -w "%{http_code}\n" https://seusite.com.br/wp-login.php; done

200
200
429
429
429
429
429
429
429
429

Restringir acesso ao wp-admin por IP no Nginx

Limitar o acesso ao painel administrativo por endereço IP é uma das medidas mais eficazes para bloquear bots e scanners automatizados. Diferente de plugins de segurança que processam a requisição dentro do PHP, essa restrição ocorre na camada do servidor web, antes de qualquer execução de código.

No arquivo de configuração do seu site no Nginx, adicione o bloco de localização para o wp-admin:

server {
    ...

    location ^~ /wp-admin/ {
        allow 203.0.113.10;
        allow 198.51.100.0/24;
        deny all;

        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/run/php/php8.3-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }

    location = /wp-admin/admin-ajax.php {
        allow all;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    ...
}

Substitua 203.0.113.10 pelo seu IP real e 198.51.100.0/24 por qualquer range CIDR adicional necessário. O bloco separado para admin-ajax.php é obrigatório — sem ele, funcionalidades de plugins e temas que dependem de AJAX deixarão de funcionar para usuários comuns do site.

Atenção: se você não tiver um IP fixo, considere usar uma VPN com IP dedicado antes de aplicar essa restrição, para não bloquear seu próprio acesso ao painel.

Recarregue o Nginx após a alteração:

nginx -t && systemctl reload nginx

Um IP não autorizado tentando acessar /wp-admin/ receberá imediatamente um erro 403 Forbidden, sem que o PHP-FPM seja sequer acionado.

Adicionar autenticação HTTP Basic ao wp-admin

A autenticação HTTP Basic cria uma segunda camada de proteção ao exigir usuário e senha antes mesmo de exibir a tela de login do WordPress. Bots que não conhecem essas credenciais são bloqueados na camada do servidor web, sem consumir recursos do PHP.

Instale o utilitário htpasswd (pacote apache2-utils no Debian/Ubuntu ou httpd-tools no Rocky Linux/AlmaLinux):

apt install apache2-utils -y

Crie o arquivo de senhas com o usuário desejado:

htpasswd -c /etc/nginx/.htpasswd adminwp

New password:
Re-type new password:
Adding password for user adminwp

Atenção: use a flag -c apenas na primeira vez. Em execuções subsequentes, ela sobrescreve o arquivo inteiro. Para adicionar mais usuários, omita o -c.

Agora, adicione as diretivas de autenticação ao bloco location ^~ /wp-admin/ no Nginx:

location ^~ /wp-admin/ {
    auth_basic "Area Restrita";
    auth_basic_user_file /etc/nginx/.htpasswd;

    allow 203.0.113.10;
    deny all;

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

Recarregue o Nginx:

nginx -t && systemctl reload nginx

Ao acessar https://seusite.com.br/wp-admin/, o navegador exibirá uma janela de autenticação nativa antes de qualquer interação com o WordPress. Certifique-se de que o site usa HTTPS — sem SSL, as credenciais do HTTP Basic trafegam em texto claro. Consulte Lista Prática: 5 Vantagens de ter SSL gratuito no seu site para entender a importância do certificado.

Proteção equivalente no Apache com .htaccess e mod_evasive

Se o seu servidor usa Apache 2.4, a proteção contra bots no painel administrativo do WordPress pode ser implementada via arquivo .htaccess dentro do diretório wp-admin ou diretamente no VirtualHost. A abordagem via VirtualHost é preferível por questões de desempenho, pois o Apache não precisa verificar arquivos .htaccess em cada requisição.

Crie ou edite o arquivo /var/www/seusite/wp-admin/.htaccess:

AuthType Basic
AuthName "Area Restrita"
AuthUserFile /etc/apache2/.htpasswd
Require valid-user

Order Deny,Allow
Deny from all
Allow from 203.0.113.10
Allow from 198.51.100.0/24

Gere o arquivo de senhas para o Apache:

htpasswd -c /etc/apache2/.htpasswd adminwp

Para rate limiting no Apache, instale e habilite o módulo mod_evasive:

apt install libapache2-mod-evasive -y
a2enmod evasive

Configure o módulo em /etc/apache2/mods-enabled/evasive.conf:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        5
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   600
    DOSLogDir           /var/log/apache2/mod_evasive
</IfModule>

Essa configuração bloqueia por 600 segundos qualquer IP que faça mais de 5 requisições à mesma página em 1 segundo. Reinicie o Apache:

systemctl restart apache2

Para excluir o admin-ajax.php da autenticação Basic no Apache, adicione ao .htaccess do wp-admin:

<Files "admin-ajax.php">
    Satisfy Any
    Allow from all
</Files>

Bloquear user-agents de bots conhecidos no Nginx

Além do rate limiting e da restrição por IP, é possível bloquear requisições de bots maliciosos identificando seus user-agents. Essa técnica complementa as anteriores e é especialmente útil para barrar scanners de vulnerabilidades e crawlers agressivos que tentam enumerar plugins e temas do WordPress.

No arquivo de configuração do Nginx, adicione um mapa de user-agents bloqueados dentro do bloco http:

http {
    map $http_user_agent $bad_bot {
        default         0;
        ~*sqlmap        1;
        ~*nikto         1;
        ~*masscan       1;
        ~*zgrab         1;
        ~*python-requests 1;
        ~*go-http-client 1;
        ~*curl/7        1;
    }
    ...
}

No bloco server, aplique o bloqueio:

server {
    ...
    if ($bad_bot) {
        return 403;
    }
    ...
}

Atenção: o bloqueio por user-agent não é infalível — bots sofisticados falsificam o user-agent. Use essa técnica como camada adicional, nunca como proteção única. Além disso, tome cuidado ao bloquear strings genéricas como curl, pois podem afetar integrações legítimas de APIs e scripts de monitoramento.

Recarregue o Nginx após as alterações:

nginx -t && systemctl reload nginx

Problemas comuns e como resolver

Sintoma: erro 403 ao acessar o wp-admin com IP autorizado

Causa: o IP do administrador pode estar sendo mascarado por um proxy reverso ou CDN (como Cloudflare), fazendo com que o Nginx veja o IP do proxy em vez do IP real do usuário. Outra causa comum é erro de digitação no CIDR ou no IP configurado no bloco allow.
Solução: verifique o IP real que chega ao servidor com tail -f /var/log/nginx/access.log enquanto tenta acessar o painel. Se estiver usando Cloudflare, configure o módulo ngx_http_realip_module para restaurar o IP original: adicione set_real_ip_from 103.21.244.0/22; (ranges do Cloudflare) e real_ip_header CF-Connecting-IP; no bloco server.

Sintoma: plugins param de funcionar após ativar autenticação Basic

Causa: plugins que fazem requisições AJAX para /wp-admin/admin-ajax.php estão sendo bloqueados pela autenticação HTTP Basic. Isso afeta plugins de carrinho de compras, formulários, sliders e qualquer funcionalidade que dependa de AJAX no frontend.
Solução: adicione um bloco location separado para admin-ajax.php com auth_basic off; no Nginx, ou use a diretiva <Files "admin-ajax.php"> com Satisfy Any no Apache, conforme demonstrado nas seções anteriores. Após a correção, teste as funcionalidades afetadas no frontend do site.

Sintoma: rate limiting bloqueando o próprio administrador durante login

Causa: o limite de requisições configurado é muito restritivo (por exemplo, 1r/m) ou o administrador está atrás de um IP compartilhado (NAT corporativo, VPN) que já acumulou requisições de outros usuários.
Solução: aumente o valor de rate para 10r/m e o burst para 5. Se o problema persistir com IP compartilhado, adicione o IP do administrador em uma whitelist usando a diretiva geo do Nginx para excluí-lo do rate limiting: geo $limit { default 1; 203.0.113.10 0; } e use $limit como chave na zona.

Sintoma: o arquivo .htpasswd não é encontrado pelo Nginx

Causa: o caminho especificado em auth_basic_user_file está incorreto ou o usuário do processo Nginx (www-data no Debian/Ubuntu, nginx no Rocky Linux) não tem permissão de leitura no arquivo.
Solução: verifique o caminho com ls -la /etc/nginx/.htpasswd e ajuste as permissões: chmod 640 /etc/nginx/.htpasswd && chown root:www-data /etc/nginx/.htpasswd. Confirme o usuário do Nginx com ps aux | grep nginx.

Perguntas frequentes sobre proteção do wp-admin contra bots

É possível proteger o wp-admin sem instalar plugin de segurança?

Sim. Você pode restringir o acesso ao wp-admin diretamente no Nginx ou Apache usando diretivas de controle de acesso por IP, autenticação HTTP Basic e rate limiting. Essas configurações atuam antes mesmo do PHP ser executado, tornando-as mais eficientes do que plugins. Isso significa menor consumo de CPU e memória, mesmo sob ataque.

Como bloquear ataques de força bruta no wp-login.php pelo Nginx?

No Nginx, use a diretiva limit_req_zone para definir uma zona de rate limiting e aplique limit_req no bloco location do wp-login.php. Isso limita o número de requisições por segundo por IP, interrompendo ataques de força bruta antes que atinjam o PHP-FPM. Configure o status de retorno como 429 para que ferramentas de monitoramento identifiquem corretamente os bloqueios.

Qual a diferença entre bloquear bots no servidor e usar plugin de segurança?

Bloquear no servidor (Nginx ou Apache) impede que a requisição chegue ao WordPress, economizando CPU e memória. Plugins de segurança processam a requisição dentro do PHP, consumindo recursos mesmo para tráfego malicioso. A proteção em nível de servidor é mais eficiente e difícil de contornar, pois opera em uma camada que o WordPress sequer consegue influenciar.

Posso restringir o wp-admin apenas ao meu IP sem afetar outros usuários?

Sim. Basta adicionar uma regra de allow para os IPs autorizados e deny all para o restante no bloco de configuração do wp-admin no Nginx ou Apache. Usuários com IPs não listados receberão erro 403, enquanto os IPs permitidos acessam normalmente. O restante do site público continua acessível para todos os visitantes sem qualquer restrição.

A autenticação HTTP Basic no wp-admin afeta o funcionamento do WordPress?

A autenticação HTTP Basic adiciona uma camada extra antes do login do WordPress, sem interferir nas funcionalidades internas. Porém, é necessário garantir que requisições AJAX do WordPress (admin-ajax.php) sejam excluídas da autenticação Basic, pois plugins e temas dependem desse endpoint para funcionar corretamente. Sem essa exceção, funcionalidades de frontend como formulários e carrinhos de compras podem parar de responder.

Conclusão

Proteger o wp-admin contra bots diretamente no servidor web é uma abordagem mais eficiente e robusta do que depender exclusivamente de plugins de segurança. As técnicas apresentadas neste guia atuam na camada de infraestrutura, antes que qualquer requisição maliciosa consuma recursos do PHP ou do banco de dados.

• Implemente rate limiting no wp-login.php como primeira medida — é simples, eficaz e não afeta usuários legítimos com comportamento normal de acesso.
• Combine restrição por IP com autenticação HTTP Basic para criar duas camadas independentes de proteção, garantindo que mesmo que um bot descubra o IP autorizado, ainda precise das credenciais Basic.
• Sempre exclua o admin-ajax.php das restrições e teste todas as funcionalidades do site após cada alteração de configuração para evitar quebrar integrações de plugins e temas.

Leia também

• Otimizar a Segurança do WordPress em Hospedagem Linux: Passos Práticos e Rápidos
• Migrar WordPress entre hospedagens sem downtime: procedimento completo
• Solucionar plugin causando lentidão no WordPress (e desativar cirurgicamente)

Precisa de ajuda com segurança do WordPress no servidor?

Configurar proteções em nível de servidor exige acesso root e conhecimento de Nginx ou Apache. Se você precisa de um ambiente WordPress com infraestrutura gerenciada e suporte técnico especializado, a AviraHost oferece planos de hospedagem otimizados para WordPress com recursos de segurança já configurados.

Conheça os planos de hospedagem WordPress da AviraHost