Anatomia de uma falha em cascata: do bloqueio de IP por spam à depuração do Roundcube no cPanel

Em servidores de hospedagem e e-mail com múltiplos domínios, problemas de infraestrutura raramente acontecem de maneira isolada. O mais comum é presenciarmos uma reação em cadeia: um incidente de segurança inicial motiva uma ação de limpeza que, por sua vez, expõe inconsistências silenciosas nas permissões de arquivos ou nas camadas de banco de dados do webmail.

Um exemplo prático dessa dinâmica acontece quando um envio massivo de spam leva ao bloqueio de reputação do IP do servidor. Ao aplicar correções com o utilitário nativo mailperm do cPanel para realinhar permissões, os usuários repentinamente perdem o acesso ao webmail com a mensagem genérica: Oops... something went wrong!.

Neste artigo, vamos dissecar essa sequência de eventos do início ao fim: o que acontece no kernel durante o envio em massa, como o script de permissões atua no sistema de arquivos, por que o banco SQLite do Roundcube e os índices do Dovecot quebram no processo e como restaurar o ambiente no terminal.

1. Fase primária: detecção de spam de saída e comportamento do kernel#

O gatilho do problema normalmente começa fora do servidor, quando um gateway de filtragem de saída (como SpamExperts ou Outfilter) detecta um pico de mensagens suspeitas e bloqueia o IP de envio:

Account from server mta.hostingdomain.net (192.0.2.246) was marked as spammer on outfilter.

O que acontece no sistema operacional durante o envio massivo#

Quando uma conta tem suas credenciais comprometidas ou um script PHP malicioso começa a disparar e-mails sem controle, o subsistema de rede e o VFS (Virtual File System) do Linux enfrentam sobrecarga imediata:

• Esgotamento de descritores de arquivos: o processo invasor invoca repetidamente socket() e connect() em direção à porta local do MTA (25 ou 587). Como cada conexão ativa aloca um descritor de arquivo na tabela do kernel, o limite padrão por processo (ulimit -n) pode ser atingido rapidamente, gerando erros do tipo EMFILE (Too many open files).
• Análise de entropia no gateway externo: gateways de borda monitoram o fluxo de saída avaliando a similaridade dos textos com algoritmos como MinHash ou SimHash. Ao constatar dezenas de mensagens praticamente idênticas disparadas em milissegundos, o filtro rebaixa a reputação do endereço e passa a descartar todo o tráfego do servidor.

2. Fase secundária: realinhando permissões com o script mailperm#

Assim que a conta ofensora é identificada e as mensagens da fila são expurgadas, uma prática comum no cPanel é rodar o script de reparo de permissões de e-mail para garantir que nenhuma pasta tenha ficado com permissão incorreta:

/usr/local/cpanel/scripts/mailperm clientuser

O que o script executa sob o capô#

O utilitário /scripts/mailperm é um script em Perl que percorre a estrutura de arquivos da conta para restaurar os padrões esperados pelo Dovecot e pelo Exim:

[Execucao do mailperm]
       │
       ├──> Leitura de /var/cpanel/users/clientuser (Obtem UID e GID)
       │
       ├──> Varredura recursiva de /home/clientuser/mail/
       │       │
       │       ├──> Aplica chmod(0750) em pastas Maildir
       │       └──> Aplica chown(clientuser:mail) em arquivos e subpastas
       │
       └──> Checagem de atributos estendidos (chattr)

1. Mapeamento de UID e GID: o script consulta os metadados do usuário para confirmar a identidade correta da conta. Ele garante que os diretórios em /home/clientuser/mail/ pertençam ao usuário da conta e ao grupo do sistema mail.
2. Definição de máscaras seguras: os diretórios do Maildir (cur/, new/, tmp/) recebem permissão 0750, enquanto os arquivos de mensagens recebem 0640. Isso permite que o Dovecot (MDA) e o Exim (MTA) leiam e gravem mensagens através do grupo compartilhado, impedindo que outros usuários locais acessem o conteúdo.
3. O caso de borda dos atributos de imutabilidade: se o invasor tiver aplicado o bit de imutabilidade via chattr +i em arquivos sensíveis de configuração (como em /home/clientuser/etc/dominio.com/shadow), o comando mailperm falha silenciosamente nessas chamadas com o erro de kernel EPERM (Operation not permitted). Esses arquivos precisam ter o bit removido manualmente com chattr -i.

3. Fase terciária: o erro interno no Roundcube#

Imediatamente após a limpeza e a execução do mailperm, os usuários tentam acessar o webmail pelo navegador e se deparam com a seguinte tela de erro:

Oops... something went wrong!
An internal error has occurred. Your request cannot be processed at this time.
For administrators: Please check the application and/or server error logs for more information.

Por que essa tela genérica aparece?#

O Roundcube adota uma política defensiva: para não expor caminhos internos de arquivos, estruturas de banco de dados ou detalhes do servidor em mensagens públicas, qualquer exceção fatal não tratada pelo PHP é interceptada pelo manipulador global (rcube.php), que registra os detalhes nos logs locais e exibe a mensagem amigável para o usuário final.

Para descobrir o que realmente aconteceu, precisamos consultar o log específico do serviço:

tail -n 20 /var/cpanel/roundcube/log/errors.log

4. Diagnóstico das causas raízes pelo terminal#

Duas situações concorrentes explicam o colapso do Roundcube após incidentes desse tipo.

Causa 1: Permissões divergentes no banco SQLite do Roundcube#

No cPanel, as preferências, contatos e configurações de cada usuário do webmail ficam guardados em pequenos bancos de dados SQLite individuais localizados em /home/clientuser/etc/dominio.com/*.rcubedb.

• O mecanismo da falha: enquanto o script mailperm ajusta o diretório /mail/, ele não recalibra automaticamente arquivos de banco do Roundcube que possam ter sido alterados para o usuário root durante ações manuais de cópia ou restauração.
• O sintoma em baixo nível: quando o PHP-FPM do cPanel tenta gravar dados de sessão ou atualizar a data do último acesso, a extensão PDO tenta obter um bloqueio de escrita via flock(). Sem permissão de escrita no arquivo .rcubedb ou no diretório pai, o SQLite retorna SQLITE_CANTOPEN ou SQLITE_READONLY, gerando uma exceção fatal imediata.

Para verificar as permissões desses bancos:

ls -la /home/clientuser/etc/dominio.com/*.rcubedb

Se o dono estiver listado como root:root ou a permissão estiver abaixo de 0640, o Roundcube não conseguirá abrir o arquivo.

Causa 2: Índices corrompidos no Dovecot e limites de conexões#

O Roundcube não lê as mensagens diretamente do disco; ele conecta-se como cliente IMAP ao Dovecot local na porta 143.

Durante o surto de spam, o volume excessivo de conexões simultâneas pode corromper os arquivos de índice do Dovecot (dovecot.index e dovecot.index.cache). Quando o Roundcube tenta autenticar o usuário após a limpeza, o Dovecot falha ao mapear o arquivo na memória via mmap() e encerra a conexão de forma prematura.

Para verificar se o Dovecot está rejeitando conexões locais:

tail -n 30 /var/log/maillog | grep -i "dovecot"

Mensagens como Disconnected: Corrupted index cache file ou Maximum number of connections from user+IP exceeded confirmam que a camada IMAP é o ponto de estrangulamento.

5. Roteiro prático de recuperação no servidor#

Abaixo está o procedimento consolidado para restabelecer o funcionamento do webmail e garantir a limpeza do ambiente.

Passo 1: Reparar a base SQLite do Roundcube#

O cPanel possui um binário dedicado para validar e atualizar as tabelas do SQLite do webmail:

/usr/local/cpanel/bin/update-roundcube-sqlite --user clientuser

Em seguida, garanta que todos os arquivos .rcubedb e a pasta onde residem pertençam ao usuário correto da conta:

chown -R clientuser:clientuser /home/clientuser/etc/dominio.com/
chmod 0640 /home/clientuser/etc/dominio.com/*.rcubedb

Passo 2: Limpar índices corrompidos do Dovecot#

Como o Dovecot recria os índices de busca automaticamente no próximo acesso, podemos remover com segurança os arquivos temporários de cache da caixa afetada:

find /home/clientuser/mail/dominio.com/ -name "dovecot.index*" -delete

Passo 3: Reiniciar o PHP-FPM interno do cPanel#

Para garantir que conexões antigas em socket ou caches de opcode do PHP não mantenham estados de erro na memória, reinicie o serviço gerenciado:

/usr/local/cpanel/scripts/restartsrv_cpanel_php_fpm

Passo 4: Testar a comunicação local com o IMAP#

Valide se o Dovecot está respondendo normalmente na porta 143 via loopback:

nc -zv 127.0.0.1 143

Você também pode simular um login simples pelo terminal:

echo -e "? LOGIN [email protected] \"sua_senha\"\n? LOGOUT" | nc 127.0.0.1 143

Se a resposta retornar LOGIN completed, o canal entre a aplicação e o servidor de correio foi totalmente restabelecido.

Rotina pós-incidente e validação de liberação na borda#

Após resolver as pendências internas no sistema de arquivos e normalizar o acesso dos usuários ao Roundcube, resta concluir a etapa de liberação do IP junto ao gateway de saída.

Antes de solicitar a remoção do bloqueio:

1. Verifique se ainda existem processos enviando conexões espúrias:

   lsof -i :25,465,587 -nP

1. Confira se a fila do Exim está limpa:

   exim -bpc

1. Solicite o delisting com segurança: envie os logs comprovando a eliminação da causa raiz para o suporte do gateway (ou utilize a interface de autoatendimento do filtro).

Com as permissões do Maildir alinhadas, o banco SQLite acessível e os índices do Dovecot reconstruídos, tanto o tráfego de saída quanto o acesso dos usuários ao webmail voltam a operar de forma consistente.

Veja também

Infraestrutura Diagnóstico profundo de request timeout no cPanel webmail com Roundcube, cpsrvd e SQLite

Servidores Como resolver assinaturas de imagem quebradas no Roundcube com cPanel e CloudLinux

Infraestrutura Roundcube no cPanel quebrando com DB error [14] unable to open database file

Este post está licenciado sob CC BY-NC.