IP bloqueado no servidor? Como identificar a conta de e-mail causadora via WHM e cPanel

Você já passou pela situação de um cliente ligar desesperado porque o escritório inteiro perdeu o acesso ao site e aos e-mails? Quando verificamos, o IP público da empresa foi banido pelo firewall do servidor. Mas a pergunta de um milhão de dólares é: quem, entre 50 colaboradores daquela rede local, está errando a senha de e-mail repetidamente e derrubando o acesso de todos?

A maioria dos servidores modernos com cPanel utiliza o cPHulk Brute Force Protection ou o CSF (ConfigServer Security & Firewall) para monitoramento de logins. Se um celular ou gerenciador (como o Outlook) tenta logar com uma senha antiga em looping (geralmente após uma troca recente de credencial corporativa), os daemons de segurança interpretam como um ataque de brute force e bloqueiam o IP de origem.

Neste artigo, compilei um guia técnico para isolar a conta culpada pelos bloqueios, analisar os arquivos de logs de forma detalhada e parametrizar o firewall para evitar recorrências.

1. Planejamento preventivo e backups do firewall (finding #1)#

Antes de efetuar alterações nas tabelas do firewall ou adicionar IPs às listas de exceção, você deve realizar backups consistentes das definições de configuração e de regras do ConfigServer Security & Firewall (CSF). Um erro sintático em arquivos de configuração pode interromper a filtragem de segurança de todo o servidor.

Execute os seguintes comandos no terminal como usuário root para gerar os backups preventivos das configurações em /etc/csf/:

# Criar backups das regras do CSF com timestamps no diretório root
cp /etc/csf/csf.conf /root/csf.conf.bak.$(date +%Y%m%d)
cp /etc/csf/csf.allow /root/csf.allow.bak.$(date +%Y%m%d)
cp /etc/csf/csf.deny /root/csf.deny.bak.$(date +%Y%m%d)

# Alternativa: gerar um arquivo tar compactado completo do diretório do CSF
tar czf /root/csf-backup-$(date +%Y%m%d).tar.gz /etc/csf/

Isso garante um ponto de restauração limpo caso o firewall necessite ser revertido ao estado operacional inicial.

2. Identificando a origem via cphulk no WHM#

Se você tem privilégios de revenda ou acesso root, o primeiro local para iniciar o diagnóstico é o histórico de eventos do cPHulk Brute Force Protection no WHM.

1. Acesse o WHM e procure por cPHulk Brute Force Protection no menu lateral.
2. Navegue até a aba History Reports.
3. Filtre os registros pelas falhas de login recentes utilizando o IP público do cliente.

A tabela exibirá de forma estruturada o IP de origem, a conta de e-mail de destino (ex: [email protected]), o serviço atacado (geralmente IMAP ou Dovecot) e o timestamp exato do evento.

3. Diagnóstico via mail delivery reports no WHM#

Caso o cPHulk não apresente registros conclusivos imediatos, a ferramenta Mail Delivery Reports (Relatórios de Entrega de E-mail) do WHM oferece uma excelente auditoria visual baseada nos logs do Exim:

1. No painel WHM, acesse Mail Delivery Reports.
2. Busque pelos eventos recentes inserindo o IP público bloqueado no campo de pesquisa.
3. Certifique-se de marcar as opções Show Blocked e Show Failed.
4. Localize eventos com a legenda Authentication Failure.
5. Clique no ícone de lupa para exibir os detalhes da transação.

A saída de debug mostrará a rejeição do servidor SMTP:

535 Incorrect authentication data ([email protected])

Isso confirma categoricamente que a conta [email protected] é a responsável por propagar credenciais incorretas a partir daquele IP.

4. Investigação pelo cPanel do usuário (track delivery)#

Se você não possui acesso administrativo ao WHM mas tem as credenciais de acesso do cPanel do domínio afetado, é possível isolar o erro:

1. Faça login no cPanel da conta do domínio afetado.
2. Na seção Email, selecione a ferramenta Track Delivery (Gerenciador de Entrega).
3. Marque as opções Show Blocked e Show Failed.
4. Filtre a busca. Qualquer falha de autenticação via SMTP será listada nos relatórios informando a conta exata de envio.

5. Auditoria de outros IPs e subredes bloqueados (finding #3)#

Frequentemente, escritórios de clientes utilizam conexões de internet redundantes (múltiplos links dedicados) ou IPs dinâmicos de uma mesma faixa da operadora. Se um IP foi bloqueado, outros IPs ou subredes da mesma região podem estar sob a mesma negação.

Você deve auditar a lista de negações do firewall e o histórico global do cPHulk para avaliar a abrangência do problema:

# Pesquisar ocorrência de IPs de teste ou específicos bloqueados no CSF
csf -g | grep "DENY"

# Visualizar as primeiras 20 linhas da lista de IPs negados do CSF
cat /etc/csf/csf.deny | head -20

# Verificar se há outros IPs de subredes semelhantes bloqueados (ex: prefixo de faixa de IP do cliente)
grep "203.0.113." /etc/csf/csf.deny

# Buscar ocorrências de bloqueio sistêmico no log do cPHulk
tail -100 /usr/local/cpanel/logs/cphulkd.log | grep "Blocked"

A identificação de múltiplos IPs bloqueados da mesma faixa indica que o dispositivo falho do usuário pode estar alternando de rede (ex: transitando entre o Wi-Fi do escritório e dados móveis) ou que múltiplos colaboradores na mesma subrede estão cometendo erros de senha.

6. Auditoria de contas de e-mail com falha sistêmica (finding #4)#

Em servidores com alto tráfego, múltiplos usuários de diferentes domínios podem sofrer brute force. Para isolar contas que estão gerando picos de falhas de autenticação globalmente no servidor, podemos analisar e agrupar registros do log de e-mails (/var/log/maillog):

# Exibir tentativas de login falhas recentes
grep "failed" /var/log/maillog | tail -20

# Contar e ordenar de forma decrescente as falhas de autenticação agrupadas por conta de e-mail
grep "Authentication Failure" /var/log/maillog | awk '{print $NF}' | sort | uniq -c | sort -rn

# Alternativa para logs estruturados do Dovecot/cPanel
grep -i "password mismatch\|auth failed" /var/log/maillog | awk -F'user=' '{print $2}' | awk -F',' '{print $1}' | sort | uniq -c | sort -rn

Além disso, verifique no WHM (ou através do comando /usr/local/cpanel/bin/whmapi1) se há contas com senhas expiradas ou bloqueadas preventivamente, o que justificaria as falhas contínuas de autenticação dos dispositivos dos clientes.

7. Verificação de segurança e configuração do dispositivo (finding #5)#

Após isolar o IP do cliente e as contas com falhas, o administrador deve orientar o cliente a auditar as configurações locais dos dispositivos. Um dispositivo móvel com a senha antiga gravada em cache continuará forçando requisições em background, gerando novos bloqueios em minutos.

Recomendações técnicas imediatas a serem passadas ao usuário final:

1. Atualizar a senha armazenada: Remova e reinsira a credencial nos aplicativos de e-mail (Outlook, Apple Mail, Gmail App, Thunderbird).
2. Verificar as portas de conexão segura:

• IMAP (Seguro): Porta 993 com criptografia SSL/TLS.
• POP3 (Seguro): Porta 995 com criptografia SSL/TLS.
• SMTP (Seguro): Porta 465 ou 587 com SSL/TLS ou STARTTLS ativo.

1. Desabilitar login automático temporariamente: Caso o dispositivo apresente falha de conexão persistente, desative o sincronismo automático para evitar flood de requisições até que a credencial seja validada.

8. Prevenção de recorrência e whitelisting (finding #6)#

Para evitar que redes de escritórios centrais de clientes ou IPs corporativos estáveis sofram novos bloqueios sistêmicos devido a erros isolados de colaboradores, você deve configurar listas de permissão permanentes ou configurar alertas no servidor.

# Adicionar o IP público dedicado do cliente à Allow List permanente do CSF
echo "203.0.113.50" >> /etc/csf/csf.allow

# Recarregar as regras do firewall para aplicar a nova whitelist imediatamente
csf -r

Adicionalmente, acesse WHM > Security Center > cPHulk Brute Force Protection e, na aba Whitelist Management, insira o IP ou subrede do cliente. Para garantir visibilidade de incidentes, configure alertas em WHM > Tweak Settings > Notifications para ser notificado sempre que ocorrerem picos de bloqueio por brute force.

9. Análise forense de logs de autenticação (finding #7)#

Caso precise conduzir um diagnóstico forense detalhado, você deve analisar diretamente os arquivos de log do servidor no terminal:

# Auditar os logs específicos do cPHulk Daemon
tail -200 /usr/local/cpanel/logs/cphulkd.log

# Monitorar logs de autenticação do Dovecot em busca de falhas
grep -i "failed\|invalid" /var/log/maillog | tail -20

# Verificar logs específicos de conexões POP3/IMAP
grep -i "auth\|login" /var/log/maillog | tail -20

# Auditar logs do Exim (SMTP) por conexões rejeitadas ou autenticações incorretas
grep -i "rejected\|blocked\|auth_failed" /var/log/exim_mainlog | tail -20

10. Auditoria do daemon cphulk e banco de dados local (finding #8)#

Se o cPHulk se comportar de maneira anômala ou parecer não bloquear invasões, você deve validar o status do daemon do serviço e a integridade de seu banco de dados local SQLite:

# Verificar se o serviço daemon cphulkd está respondendo corretamente
/usr/local/cpanel/bin/cphulkdcheck

# Exibir os parâmetros do arquivo de configuração ativa do cPHulk
cat /var/cpanel/cphulkd.conf

# Inspecionar registros e limites diretamente na tabela local de bloqueios temporários
sqlite3 /var/cpanel/hulkd/cphulk.db "SELECT * FROM ip_limits LIMIT 10;"

11. Auditoria e validação do status do CSF (finding #9)#

Nunca altere regras de firewall sem verificar se o ConfigServer Security & Firewall está ativamente operacional e executando o monitoramento de logs de intrusão (LFD):

# Verificar a versão instalada e status operacional básico do CSF
csf -v

# Verificar se os daemons csf e lfd estão ativos no systemd
systemctl status csf --no-pager
systemctl status lfd --no-pager

# Pesquisar se um IP específico está listado nas regras ativas do iptables/CSF
csf -g 203.0.113.50

# Exibir a allow list do arquivo de permissões
cat /etc/csf/csf.allow

12. Roteiro pós-fix de desbloqueio e teste (finding #2)#

Para confirmar se o IP do cliente está operacional e monitorar se novos travamentos não estão sendo gerados pelo mesmo IP, siga este roteiro de desbloqueio e validação:

# Desbloquear temporariamente o IP do cliente das regras de bloqueio do CSF
csf -dr 203.0.113.50

# Confirmar se o IP foi devidamente removido do firewall
csf -g 203.0.113.50

# Monitorar logs de autenticação em tempo real filtrados pelo IP liberado
tail -f /var/log/maillog | grep "203.0.113.50"

# Acompanhar em paralelo os logs do cPHulk para validar se a reconfiguração dos clientes funcionou
tail -f /usr/local/cpanel/logs/cphulkd.log | grep "203.0.113.50"

Acompanhe as telas por pelo menos 10 a 15 minutos enquanto os usuários reconfiguram seus dispositivos. Caso as tentativas com falhas de autenticação cessem, a correção foi bem-sucedida.

13. Procedimento de rollback de regras de firewall (finding #10)#

Caso precise reverter as whitelists criadas e restaurar o firewall às regras de segurança estritas originais por motivos de auditoria ou término de testes, execute o seguinte procedimento de rollback:

# Remover o IP temporário da allow list do CSF
csf -ar 203.0.113.50

# Restaurar os arquivos originais do CSF a partir do backup preventivo gerado no início da atividade
cp /root/csf.conf.bak.20260616 /etc/csf/csf.conf
cp /root/csf.allow.bak.20260616 /etc/csf/csf.allow
cp /root/csf.deny.bak.20260616 /etc/csf/csf.deny

# Recarregar as configurações de rede do firewall
csf -r

# Confirmar a integridade operacional do CSF após a recarga
csf -v

14. Checklist de troubleshooting IP bloqueado#

Siga este checklist operacional para diagnosticar incidentes de IPs bloqueados:

Fase 1: Diagnóstico & investigação#

• [ ] Verificar logs de negação do firewall no host: tail -100 /var/log/lfd.log
• [ ] Pesquisar IP afetado no histórico do cPHulk: WHM > cPHulk > History
• [ ] Auditar relatórios de entrega de e-mail por erros 535: Mail Delivery Reports
• [ ] Isolar a conta de e-mail específica geradora dos erros de login

Fase 2: Correção & liberação#

• [ ] Efetuar backup preventivo dos arquivos do CSF em /etc/csf/
• [ ] Liberar o IP público no CSF: csf -dr <IP>
• [ ] Adicionar IP à Whitelist no cPHulk e no CSF
• [ ] Instruir o usuário a atualizar as credenciais no dispositivo móvel ou Outlook
• [ ] Confirmar o uso de portas seguras (993 para IMAP, 465/587 para SMTP)

Fase 3: Validação & monitoramento#

• [ ] Monitorar a fila de tentativas de login: tail -f /var/log/maillog
• [ ] Validar status do cPHulk com /usr/local/cpanel/bin/cphulkdcheck
• [ ] Monitorar comportamento da rede por 15 minutos pós-desbloqueio

15. Matriz de riscos e mitigações#

Considerações práticas#

Identificar o motivo de um bloqueio não precisa ser um jogo de adivinhação. O ecossistema cPanel oferece ferramentas robustas de interface gráfica que substituem bem o terminal em momentos de urgência. O segredo é saber cruzar os dados do cPHulk com os Relatórios de Entrega.

Veja também

Infraestrutura O mistério do IP fantasma quando o CSF ignora whitelist, NAT e estado de conexão

Infraestrutura Debugando pure-ftpd travado na mensagem de boas-vindas em cPanel/OVH

Infraestrutura Como contornar o limite global de e-mails no cPanel e CloudLinux: resolvendo o erro XID psafa9

Este post está licenciado sob CC BY-NC.