Processos Órfãos e Bloqueios de IP no cPanel e

Processos órfãos e diagnóstico de bloqueios de IP em camadas no cPanel e CloudLinux#

Em servidores com cPanel e CloudLinux hospedando dezenas de contas, o comportamento do kernel e das camadas de rede pode parecer confuso quando dois problemas se cruzam: processos interativos que se recusam a morrer após a queda de conexões SSH e endereços de IP legítimos impedidos de conectar por motivos invisíveis no painel.

Recentemente passei por esse cenário exato. De um lado, uma conta acumulando comandos de monitoramento sem terminal ativo ocupando a tabela de processos. Do outro, um endereço de teste sofrendo bloqueios sucessivos mesmo após ter sido liberado no firewall principal.

Abaixo documento o caminho que segui para entender o descarte de sinais no kernel, a sintaxe correta para encerrar processos por usuário e o roteiro para auditar bloqueios em cada camada do sistema.

O fantasma das sessões desacopladas#

O primeiro sintoma foi o acúmulo de processos residuais que não liberavam recursos. Ao rodar ps aux para auditar uma conta de usuário específica (user), me deparei com múltiplos shells interativos e comandos de leitura de log abandonados:

[root@server ~]# ps aux | grep user
user 3131927  0.0  0.0   5352  4276 ?        S    10:32   0:00 /bin/bash -l
user 3146071  0.0  0.0   3104  1892 ?        S    10:33   0:00 tail -f domain.com
user 3279880  0.0  0.0   5352  4296 ?        S    15:16   0:00 /bin/bash -l
user 3446124  0.0  0.0   3104  1892 ?        S    10:54   0:00 tail -f domain.com
user 3480583  0.0  0.0   3104  1892 ?        S    15:30   0:00 tail -f domain.com-ssl_log
root  3864491  0.0  0.0   3884  2468 pts/5    S+   15:55   0:00 grep --color=auto user

O comportamento do kernel e a perda do terminal controlador#

Na coluna TTY, o caractere de interrogação (?) indica que os processos perderam o terminal controlador (controlling terminal).

Quando alguém acessa o servidor via SSH, o daemon do OpenSSH realiza uma chamada fork() seguida de execve() para iniciar o /bin/bash -l. O parâmetro -l orienta o bash a executar sua rotina de login, lendo arquivos como /etc/profile e ~/.bash_profile. Se a conexão de rede cai de repente por timeout ou oscilação de link, o kernel envia o sinal SIGHUP ao processo líder da sessão. Porém, se o shell ignorar o sinal ou se o comando filho (tail -f) foi chamado em uma subárvore que não repassa o sinal, o processo perde o pai e é adotado pelo PID 1 (systemd). Ele entra no estado de sono (S), aguardando entrada ou saída indefinidamente.

O comando tail -f piora esse quadro. No utilitário do pacote GNU coreutils, o tail -f usa a chamada de sistema inotify_add_watch do kernel ou faz verificações periódicas com poll() para monitorar descritores de arquivo. Sem um terminal conectado para receber o STDOUT, ele permanece dormindo enquanto espera eventos de buffer que ninguém mais vai ler.

Por que o pkill comum falha em silêncio#

A reação inicial mais frequente é tentar limpar os processos pelo nome da conta:

[root@server ~]# pkillall -9 user
-bash: pkillall: command not found
[root@server ~]# pkill -9 user

O primeiro comando falha porque o utilitário pkillall não existe no padrão do AlmaLinux ou Red Hat (o pacote correspondente é o psmisc, que fornece o killall). Já o pkill -9 user roda sem erros, mas não finaliza nada.

O pkill faz parte do pacote procps-ng. Por padrão, ele compara o argumento informado contra o nome do executável registrado em /proc/[pid]/stat, e não contra o nome do usuário do sistema. Como não havia nenhum binário com o nome literal user, a busca simplesmente não encontrou correspondências.

Para mirar no usuário proprietário dos processos, a flag -u (Effective UID) é necessária:

# Encerramento correto com pkill filtrando por usuario
pkill -9 -u user

# Alternativa usando o utilitario killall
killall -9 -u user

O envio de SIGKILL (-9) impede que a aplicação intercepte o sinal via sigaction(). O kernel encerra a execução imediatamente, recupera a memória e fecha os descritores de arquivo. Por outro lado, arquivos temporários de trava (.lock) criados pela aplicação podem permanecer no disco, exigindo cuidado se o processo estiver gravando em bancos de dados ou sessões.

Inspecionando descritores e chamadas de sistema#

Antes de encerrar processos desconhecidos, costumo investigar o que os mantém presos:

Descritores de arquivo e sockets abertos: usando lsof para inspecionar os arquivos vinculados ao processo:

   lsof -p 3131927

Rastreamento de chamadas de sistema com strace: anexando o rastreador ao processo vivo para checar se ele está bloqueado em leitura:

   strace -p 3131927

Se a saída acusar read(0, ...), o shell está congelado aguardando entrada do STDIN de um terminal inexistente.

Para evitar que novas sessões abandonadas acumulem no servidor, adicionei uma variável de timeout automático de terminal no perfil global do sistema:

# /etc/profile.d/timeout.sh
readonly TMOUT=900
export TMOUT

Com essa diretiva, shells ociosos sem atividade por 15 minutos são encerrados pelo próprio bash.

O labirinto de bloqueios de IP no cPanel e CloudLinux#

Resolvida a fila de processos, passei a investigar a causa de um IP de teste (177.93.168.253) não conseguir alcançar os serviços do servidor. Em instalações com CloudLinux e cPanel, uma recusa de conexão raramente se resume a uma regra solta no iptables. O bloqueio pode acontecer em diferentes camadas.

Fiz o rastreamento do pacote através dos seguintes passos pelo terminal:

1. Camada de rede e kernel (Netfilter e CSF)#

O firewall CSF monitora conexões através do subsistema netfilter do kernel Linux. Se o IP acumulou falhas detectadas pelo LFD, ele é inserido em chains temporárias ou permanentes de descarte.

Para checar e limpar o endereço:

# Pesquisa global nas regras do CSF
csf -g 177.93.168.253

# Remocao temporaria e reinicio das regras
csf -dr 177.93.168.253 && csf -r

Se o CSF não listar o endereço, vale conferir as regras brutas do iptables para verificar se algum módulo específico descartou os pacotes:

iptables -L INPUT -v -n | grep 177.93.168.253

2. Camada de aplicacao e WAF (Imunify360 e ModSecurity)#

No CloudLinux, o Imunify360 trabalha em conjunto com o Apache ou LiteSpeed usando regras do ModSecurity e coleções do ipset. O sistema mantém listas cinzas que forçam testes de CAPTCHA redirecionando a conexão para a porta 52223.

Para verificar a reputação do IP no agente:

# Consulta nas listas do WAF
imunify360-agent blacklist ip list | grep 177.93.168.253
imunify360-agent graylist ip list | grep 177.93.168.253

# Inclusao em lista de permissoes permanente
imunify360-agent whitelist ip add 177.93.168.253 --comment "Acesso Admin"

3. Camada de servico e protecao PAM (cPHulk)#

Quando a conexão TCP inicial funciona nas portas 22 (SSH) ou 2083 (cPanel), mas a autenticação falha em seguida, o responsável costuma ser o cPHulk. Ele se conecta à pilha PAM local e armazena registros em banco SQLite ou MySQL para impedir tentativas de força bruta na camada de aplicação:

# Consulta via utilitario de linha de comando do cPHulk
/usr/local/cpanel/bin/cphulk_pam_ctl --list | grep 177.93.168.253

# Consulta dos registros pela API do WHM
whmapi1 get_cphulk_user_brute_force_log IP=177.93.168.253

# Limpeza do historico de bloqueios para o IP
whmapi1 flush_cphulk_login_history_for_ips ip=177.93.168.253

4. Camada de recursos da conta (CloudLinux LVE e CageFS)#

Se o IP pertence a um usuário que relata páginas em branco ou erros HTTP 508, o problema não está no tráfego de rede, mas sim no esgotamento dos limites do ambiente virtualizado (LVE) ou em falhas de montagem no namespace do CageFS:

# Monitoramento do consumo instantaneo
lvetop

# Historico de falhas de cota da conta
lveinfo --user user

# Verificacao da integridade dos pontos de montagem
cagefsctl --check-environment

5. Auditoria simultanea nos logs do sistema#

Para fechar o diagnóstico sem depender de palpites, costumo cruzar os logs de todos os daemons ao mesmo tempo com um comando único procurando pelo IP em análise:

grep -r "177.93.168.253" /var/log/exim_mainlog /var/log/messages /var/log/secure /usr/local/apache/logs/error_log /var/log/cpanel/cphulkd.log /var/log/imunify360/error.log /etc/apache2/logs/modsec_audit.log

Essa busca rápida aponta na hora qual módulo disparou o gatilho, seja uma rejeição no Exim, um bloqueio no PAM ou uma regra de auditoria do ModSecurity.

Da tabela de processos aos filtros de rede: visão integrada#

Servidores compartilhados com CloudLinux demandam uma visão em camadas para separar problemas de execução de problemas de conectividade. Um processo que parece congelado geralmente está preso esperando eventos de um terminal que caiu, e um IP inacessível pode estar sendo barrado pelo PAM ou pelo WAF mesmo com a porta do firewall aberta no kernel.

Ter em mãos a sintaxe precisa de comandos como pkill -u, inspecionar chamadas de sistema com strace e conhecer a sequência de checagem entre CSF, Imunify360 e cPHulk reduz o tempo de resposta e evita reinicializações desnecessárias de serviços.

Este artigo foi útil?

Deixe uma reação rápida para apoiar o conteúdo:

456 leituras

Creative Commons Atribuição-NãoComercial

Este post está licenciado sob CC BY-NC.