Debugging: resolvendo o bloqueio "access denied by Imunify360 bot protection" em fluxos de automação

Quem lida com servidores web ou integra serviços externos em aplicações já passou por esta situação: uma rotina automática que funcionava sem problemas de repente para de responder. Pode ser um webhook de pagamento que não confirma pedidos, um cronjob externo disparado por serviços em nuvem, uma sincronização entre ERP e e-commerce, ou até um monitor de disponibilidade (como Uptime Kuma ou Pingdom) marcando falso downtime.

Ao verificar os registros da aplicação consumidora, surge um destes dois retornos característicos:

Em chamadas REST ou clientes que esperam JSON:

{"message":"Access denied by Imunify360 bot-protection..."}

Ou em requisições web com resposta HTML (geralmente acompanhada de código HTTP 403 ou 423):

Access Denied by Imunify360 Bot Protection

Esse bloqueio não significa que o servidor caiu ou que a senha da API expirou. Trata-se de uma ação preventiva do WebShield, um dos módulos de proteção do Imunify360.

Abaixo, vamos entender a dinâmica desse mecanismo e ver as formas práticas de liberar o fluxo legítimo, tanto pelo terminal quanto pelo painel de controle ou no código da aplicação.

Por que a automação foi barrada? A mecânica do desafio javascript#

O WebShield atua como uma barreira inicial entre a internet e o servidor web (Apache, LiteSpeed ou Nginx). A principal missão dele é conter ataques automatizados em massa, como raspagem não autorizada, scanners de vulnerabilidade e tentativas de invasão por força bruta.

Para diferenciar pessoas de robôs, o módulo aplica um desafio JavaScript invisível (JS challenge) logo na chegada da conexão:

1. Navegadores comuns: Recebem a página inicial de verificação, executam o script em milissegundos em segundo plano e recebem um cookie de autorização. A navegação flui normalmente sem que a pessoa perceba.
2. Scripts e bibliotecas HTTP: Ferramentas como curl, wget, axios, bibliotecas de requests do Python ou clientes HTTP do PHP (como Guzzle) apenas recebem o HTML bruto. Como não contam com um interpretador JavaScript completo para resolver a lógica e devolver a resposta esperada, a conexão não avança e o WebShield encerra o acesso.

Compreendido o mecanismo, vamos aos caminhos para resolver o bloqueio sem desligar a segurança do servidor como um todo.

1. O mito do user-agent personalizado#

Quando esse bloqueio acontece pela primeira vez, uma reação quase automática entre desenvolvedores é tentar "disfarçar" o script:

# Tentativa comum (e ineficaz):
curl -H "User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36..." https://meu-site.com/api

Se você desenvolve ou consome a API e não tem acesso de administração ao servidor, as alternativas reais são:

• Pedir liberação do IP: Descobrir o IP público fixo de saída da sua ferramenta e solicitar que o suporte da hospedagem adicione esse IP na lista de permissões.
• Automação com motor JS: Em fluxos onde não é possível ter IP fixo nem acesso ao servidor, a saída técnica é usar navegadores headless como Puppeteer ou Playwright, que executam o JavaScript, recebem o cookie de bypass e mantêm a sessão ativa.

2. Diagnóstico nos logs do servidor#

Se você tem acesso SSH ao servidor, antes de mexer em regras de firewall vale a pena confirmar nos registros se o bloqueio veio mesmo do WebShield e isolar o endereço exato que foi barrado:

# 1. Registro de acessos do próprio WebShield (onde os bloqueios de bots ficam registrados)
tail -100 /var/log/imunify360/webshield/access.log | grep "BOT"

# 2. Registros do serviço do Imunify360 na última hora
journalctl -u imunify360 --since "1 hour ago" | grep -i "bot"

# 3. Busca direta pelo termo bot-protection em todos os logs do produto
grep -i "bot-protection" /var/log/imunify360/*.log | tail -20

Se o IP da sua ferramenta aparecer nesses logs associado à flag de bloqueio, o diagnóstico está confirmado.

3. Whitelist via linha de comando (CLI)#

O agente do Imunify360 (imunify360-agent) permite adicionar regras de liberação permanente diretamente no terminal. Aqui existe um detalhe de sintaxe fundamental que evita horas de dor de cabeça.

IP único vs sub-rede (CIDR)#

Para cadastrar um IP individual:

imunify360-agent whitelist ip add 198.51.100.25 --comment "Webhook de Pagamento"

Para liberar uma faixa completa de rede (muito comum em serviços em nuvem como AWS, Cloudflare, GitHub Actions ou gateways de pagamento):

imunify360-agent whitelist subnet add 198.51.100.0/24 --comment "Range Cloud do Gateway"

Suporte a ipv6#

Caso sua infraestrutura utilize IPv6, a mesma separação de comando se aplica:

# IP IPv6 individual
imunify360-agent whitelist ip add 2001:db8::1 --comment "Integracao IPv6"

# Sub-rede IPv6
imunify360-agent whitelist subnet add 2001:db8::/64 --comment "Sub-rede IPv6"

Compatibilidade com a flag de comentário#

Em algumas versões mais antigas do Imunify360, o parâmetro --comment pode retornar erro de argumento desconhecido. Para garantir que scripts de manutenção não travem, use uma estrutura defensiva com fallback:

imunify360-agent whitelist ip add 198.51.100.25 --comment "Rotina Externa" || \
  imunify360-agent whitelist ip add 198.51.100.25

4. Whitelist pela interface gráfica (WHM, cPanel ou DirectAdmin)#

Para quem gerencia o servidor através de painel de controle e prefere não usar o terminal, o processo pode ser feito em poucos cliques na interface web:

1. Acesse o painel de administração da sua hospedagem (como o WHM no caso de cPanel ou a área administrativa do DirectAdmin).
2. No menu de busca ou na seção de Plugins, clique em Imunify360.
3. No painel do Imunify360, selecione a aba Firewall.
4. Entre na sub-aba White List (Lista Branca).
5. Clique no botão Add (Adicionar).
6. Digite o endereço no campo de texto. A interface gráfica reconhece tanto IPs individuais (198.51.100.25) quanto notações de bloco CIDR (198.51.100.0/24).
7. No campo de descrição/comentário, informe o motivo da regra (por exemplo: "API de faturamento" ou "Monitor de Uptime").
8. Clique em Add IP para salvar. A liberação entra em vigor imediatamente.

5. Script automatizado para gestão de regras#

Se você administra vários servidores ou precisa cadastrar regras com frequência, o script bash abaixo detecta automaticamente se o alvo é um IP único ou uma sub-rede CIDR, aplica os comandos corretos com tolerância a falhas na flag de comentários e valida se a inclusão funcionou:

#!/bin/bash
# /usr/local/sbin/imunify-whitelist.sh
# Cadastra IP ou Sub-rede na whitelist do Imunify360 com validacao

set -euo pipefail

TARGET="${1:?Uso: $0 <IP_OU_CIDR> [comentario]}"
COMMENT="${2:-Liberacao via script de automacao}"

# Detecta se e IP individual ou bloco de rede
if [[ "$TARGET" == *"/"* ]]; then
    echo "Identificado: Sub-rede CIDR -> $TARGET"
    imunify360-agent whitelist subnet add "$TARGET" --comment "$COMMENT" 2>/dev/null || \
    imunify360-agent whitelist subnet add "$TARGET"
else
    echo "Identificado: IP unico -> $TARGET"
    imunify360-agent whitelist ip add "$TARGET" --comment "$COMMENT" 2>/dev/null || \
    imunify360-agent whitelist ip add "$TARGET"
fi

# Conferencia imediata
echo ""
echo "=== Verificando regra cadastrada ==="
if [[ "$TARGET" == *"/"* ]]; then
    imunify360-agent whitelist subnet list 2>/dev/null | grep -F "$TARGET" && \
      echo "✓ Sub-rede $TARGET confirmada na whitelist!" || \
      echo "⚠ Sub-rede nao encontrada na listagem ativa."
else
    imunify360-agent whitelist ip list 2>/dev/null | grep -F "$TARGET" && \
      echo "✓ IP $TARGET confirmado na whitelist!" || \
      echo "⚠ IP nao encontrado na listagem ativa."
fi

6. Desativação pontual ou ajuste de sensibilidade do desafio#

Em situações em que o serviço parceiro utiliza dezenas de faixas de IP voláteis que mudam com frequência, manter whitelists manuais pode se tornar inviável. Nesses casos, existem duas abordagens de configuração:

Opção a: desativar apenas a tela de splash screen (desafio JS)#

Em vez de desativar o WebShield por completo, você pode desligar exclusivamente a exibição do desafio JavaScript. A sintaxe exata do JSON varia conforme a família da versão instalada:

# Estrutura padrao para versoes recentes
imunify360-agent config update '{"WEBSHIELD_SPLASH_SCREEN": false}'

# Estrutura em bloco utilizada em versoes especificas
imunify360-agent config update '{"WEBSHIELD": {"splash_screen": false}}'

Opção b: calibrar a sensibilidade sem abrir mão da proteção#

Se a ideia for apenas reduzir o rigor da filtragem para evitar atrito desnecessário:

# Reduz o nivel de agressividade na deteccao de bots
imunify360-agent config update '{"WEBSHIELD_BOT_THRESHOLD": "medium"}'

# Amplia o tempo limite de resolucao do desafio para conexoes mais lentas
imunify360-agent config update '{"WEBSHIELD_CHALLENGE_TIMEOUT": 30}'

Para conferir o que está em vigor após as mudanças:

imunify360-agent config show | grep -i -E "splash|webshield"

7. Roteiro prático para destravar uma automação bloqueada#

Quando o erro aparecer na sua tela ou nos logs da aplicação, este fluxo visual resume o caminho mais direto para resolver o problema:

Boas práticas para manter automações e segurança em harmonia#

O bloqueio por proteção de bots do Imunify360 não é uma falha misteriosa: é o comportamento esperado de um firewall de aplicação quando recebe requisições de clientes HTTP que não renderizam JavaScript.

Para evitar dores de cabeça recorrentes:

1. Priorize whitelists cirúrgicas: Use sempre subnet add para blocos CIDR e ip add para IPs únicos, mantendo a proteção ativa para todo o restante dos visitantes.
2. Documente os comentários: Regras com descrições claras ("Webhook Asaas", "Cronjob AWS Lambda") evitam que colegas de equipe removam a liberação no futuro achando que se trata de uma regra órfã.
3. Não perca tempo trocando User-Agent: Compreender que o mecanismo se baseia em desafio de código poupa tentativas frustradas de contorno superficial.
4. Verifique os logs antes de mudar configurações globais: Confirmar a origem exata do bloqueio no arquivo webshield/access.log dá a certeza de que a correção está sendo aplicada no lugar certo.

🛡️ Benchmark de Segurança em Produção: Quer ver como o Imunify360 se compara frente a CSF/LFD e Wordfence CLI em consumo de CPU e bloqueio L7? Confira nossa análise técnica: Segurança no cPanel em Produção: Imunify360, CSF/LFD e Wordfence CLI no Hub de Rankings & Comparativos.

Veja também

Cibersegurança Anatomia de um incidente: mitigando ataques L7 simultâneos, dos no Dovecot e gargalos de CPU

Cibersegurança Do scan de .env ao bloqueio no kernel: minha jornada com CloudPanel, Nginx e CrowdSec

Infraestrutura WordPress Admin Bloqueado: Diagnóstico Forense, Desbloqueio e Recuperação de Acesso via WP-CLI e MySQL

Este post está licenciado sob CC BY-NC.