tvoltolini

Sendo Cloudlinux, pode ser algum BO com o cagefs. Tenta desativar o cagefs pra essa conta caso esteja habilitado. Outra coisa que podes tentar é mudar a versão do PHP no PHP Selector do Cloudlinux e não pelo gerenciador do cpanel. O log de erro do apache tá registrando alguma coisa pra esses acessos?

Rodar em modo php-cgi é bem pesado, mod_lsapi ou FPM vai ajudar a reduzir o consumo de CPU consideravelmente. Ativa o opcache do PHP pra ter uma camada de otimização e você deve notar uma boa melhora (opcache não funciona no php-cgi). Cloudlinux é paliativo (e caro pra um VPS pequeno), ele vai limitar o consumo de recursos, logo se o processo não for otimizado ele vai deixar o site mais lento. Ele só não vai deixar o site afetar outros sites do servidor, ou no pior caso, derrubar a máquina por consumo de recursos. O site pode precisar de alguma otimização também. Começa arrancando plugins desnecessários, é isso que sempre mata o Wordpress, e desativa o WP-CRON, bota pra rodar numa tarefa agendada. Dependendo da configuração do site isso vai ter dar uma BAITA diferença. E claro, plugins de cache pro WP sempre ajudam

Anonymous Fox tem usa um esquema "simples" pra invadir contas Cpanel SE você tiver o reset de senha habilitado no servidor. O Cpanel guarda o email de contato da conta dentro do ambiente do usuário, num arquivo de texto. Eles encontram alguma vulnerabilidade no site que dá acesso aos arquivos upando um shell qualquer no wordpress ou mesmo roubando a senha de admin do wordpress e upando o arquivo pra dentro. Feito isso eles alteram o email de contato da conta e pedem o reset de senha nesse email. A partir daí eles tem acesso ao cpanel da conta. E não é apenas invasão de site que eles fazem, é bem comum encontrar contas de email com o termo "fox" no nome nessas contas comprometidas. Ao menos era assim que eles faziam há um tempo atrás, se isso está mais elaborado hoje, não sei dizer.

Sem esses detalhes não tem como dizer porque a falha acontece. Se o clamav foi instalado pelo WHM esses detalhes ficam no /var/log/messages. Se foi instalado pelo yum os logs ficam em /var/log/clamav/ Se você usa o CSF com LFD, dá uma olhada se o firewall não está matando o processo em /var/log/lfd.log

Isso é só o log do monitor testando o serviço e detectando falha. Verifica no /var/log/messages, o Clamav instalado pelo cpanel salva os logs nesse arquivo e lá deve mostrar o erro na inicialização. O status também talvez mostre algum detalhe:

Verifica o log de inicialização do serviço em /var/log/clamav/ ou /var/log/messages Esses logs devem mostrar o motivo do serviço estar falhando.

Em situações muito específicas, sim. Mas você não notaria apenas o erro, todos os serviços seriam afetados por lentidão e o servidor apresentaria load alto sem uso de CPU ou memória numa situação dessas.

Você pode ter um gargalo na leitura/escrita do disco no VPS. Como o VPS está dividindo recursos com outras máquinas virtuais, se o uso do disco for pesado nesse node o desempenho pode ficar comprometido, pois você vai ter um "tempo de espera" muito alto, que é o tempo aguardando por dados do disco que estão sendo lidos e/ou escritos.

@Motoboy tenta desativar o wp_cron, você vai notar melhora no desempenho do admin e na navegação do site também Adiciona essa linha no wp-config.php E depois cria um cron pra executar o wp-cron.php de tempo em tempo.

@AJ Meireles Você não vai encontrar nada automatizado pra fazer isso, vai ter bastante trabalho manual copiando FTP e bancos, mas é possível sim, desde que o servidor de destino tenha os mesmos recursos do servidor de origem. Como o Josuel mencionou, ajustes podem ser necessários, principalmente se a configuração dos sites depende de caminho de pastas. Emails você pode copiar com o Imapcopy ou Imapsync. Se você tiver acesso shell no linux o wget ou lftp facilitam a cópia do FTP

Também não conhecia esse ntphp e estava vendo alguns detalhes. O ntphp tem uma desvantagem, segundo o site informa ele só roda com SUPHP, qualquer outro handler faz ele não funcionar, aí o desempenho fica bem limitado. Há alguma limitação no teu plugin, @Jaime? Ele roda com mod_ruid + DSO (suspeito que não, esse bixo não é compatível com nada)? E php-fcgi? Parabéns pela iniciativa e pelo desenvolvimento do plugin ;D

Verifica o conteúdo do arquivo, se é algo suspeito. Confere a data de criação/modificação dele e compara com os logs de acessos no site desse usuário "shopdoan" no mesmo horário, pode ajudar a descobrir como isso foi parar ali.

Acessa as configurações do firewall, procura por FASTSTART e desativa (seta o valor pra 0), depois tenta reiniciar o firewall. Se reiniciar, pode tentar reativar o FASTSTART, talvez resolva depois do primeiro restart

@Leandro dos Santos relaxa, esses emails que você está recebendo de fato não estão saindo do teu servidor nem da tua máquina local: Received: from [23.97.194.64] (port=1120 helo=live.com) Os emails estão sendo disparados desse IP aí. Talvez a configuração do SPF te ajude, mas teu servidor tem que estar configurado pra consultar SPF e negar a mensagem quando houver erro, caso contrário continuará recebendo. De qualquer forma, não é um problema com o teu servidor, nem malware, nem vulnerabilidade como foi mencionado. Isso é bem comum na verdade, e bem simples, o remetente só seta o FROM da mensagem para ser igual ao destinatário.

Como foi comentado, usar um limite muito alto pode causar alguma sobrecarga no firewall e passar a haver lentidão nas conexões mas principalmente ao reiniciar o firewall (não sei ao certo agora com o FASTSTART que deve melhorar bastante). Só um exclarecimento, o DENY_TEMP_IP_LIMIT é a quantidade máxima de IPs bloqueados na lista temporária (bloqueios temporários), não tem nada a ver com limite de tempo de bloqueio.