Ir para conteúdo
  • Cadastre-se

tvoltolini

Membro
  • Postagens

    28
  • Registro em

  • Última visita

Tudo que tvoltolini postou

  1. 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
  2. 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.
  3. 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
  4. 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:
  5. 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.
  6. 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.
  7. 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.
  8. @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.
  9. @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
  10. 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
  11. 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.
  12. 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
  13. @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.
  14. 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.
  15. Dentre outras dificuldades, você não vai conseguir montar um servidor de emails numa rede residencial porque a porta 25 está sendo bloqueada pelas ISPs (a não ser que a que você usa esteja bem atrasada).. O VPS não vem com reverso configurado, mas permite que você configure.
  16. @opencag aqui não achei em outros arquivos, todos eram social.png mesmo. Mas quals dos scripts detectou? Pois o check_filesystem.py mostra qual é o arquivo infectado. Você deve ter consultado com o check_url.py, mas nos meus testes esse aí indicou alguns sites que realmente não tinham nada. Vou te passar aqui uma parte da chave que eu encontrei em vários arquivos, talvez por esse código você consiga encontrar outros infectados: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6K/I2l6k2Iz7Vojzxk5Q 43QNfIJm2jWPvXAvFtft+yy4rD3MseQJWx3PLlkoRQjSI1uiiwwlPZWED0e5wFet nS5tKhvvRaOeUPYJq6MtyUbnaMn7bshlgaAlPaUCVdAOjdtGHMuFaWfnBLgTSu3c uccVC2zOlXx7XK1tw39eZepRemoh0W3Qhf+hDFsEzACSBmKhBiganwCZzTDvyXpj Isso é uma parte de uma public key que faz parte do código dos arquivos
  17. Ruan, pra começar uma revenda não tem segredo, você só tem que setar os planos (caso o painel usado tenha essa funcionalidade) e configurar os nameservers da revenda que você vai usar no registro, se você for usar os do seu domínio. O segundo geralmente até a empresa que vende a revenda já deixa configurado ou manda instruções de como fazer. Não há necessidade de contratar nada terceirizado pra isso ;D
  18. @pablobr o que eu quis dizer é que se o nome do arquivo não for social.png o script nem verifica o hash. Ao menos foi isso que eu entendi dessa parte do código e é o que está mencionado no comentário: # Only process social*.png fname = fname.lower() if not (fname.startswith('social') and fname.endswith('.png')): continue Então se por acaso tiver algum arquivo com outro nome, eu acho que ele já não vai detectar.
  19. Dá uma olhada nos logs do sistema operacional primeiro pra tentar descobrir o que fez ele ficar fora, se foi um reboot, se foi queda do sistema mesmo. Se não indicar nada desse tipo, pode ser um problema no DC mesmo, link instável por exemplo
  20. Esse check_filesystem.py demora muito porque ele não aceita wildcard no caminho. É mais fácil procurar com o find. Pra servidores com Cpanel: find /home*/*/public_html/ -type f -name social.png Depois com a lista de arquivos é só checar se algum deles tem código php dentro. O check_filesystem.py também só verifica arquivos com esse nome (social.png), se o nome for outro ele passa direto, então depois de encontrar alguns, é só procurar por um padrão de código e filtrar os outros arquivos do site pra ver se tem algum com nome diferente. Importante dizer também que esse malware tem se espalhado por plugins e addons pirateados do WP e Joomla, então alertem aqueles seus clientes "espertinhos" ;D
  21. @RobertSP obrigado pelo aviso, eu uso em poucos servidores, só nos que realmente precisam, e não uso o plugin do WHM pra praticamente nada, então realmente não sabia do problema. Obrigado @Pedro Sodre
  22. Bom dia pessoal. Recentemente o WHM recebeu a versão 11.46 na tier RELEASE e o plugin MailManage do ConfigServer parou de funcionar corretamente. Logo foi lançado um update e o plugin voltou a funcionar normalmente, mas alguns dias depois recebi reclamações de que os filtros e redirecionamentos de alguns domínios haviam sumido. Tive que recuperar do backup. Investigando os logs de acesso, vi que alguns clientes tinham usado o plugin para gerenciar os domínios afetados antes do update ser aplicado. Então se o seu plugin está na versão 1.30 ou menor no WHM 11.46, qualquer domínio que você acessar pelo plugin vai ter o arquivo que guarda os redirecionamentos apagado. Atualize o plugin antes de usá-lo se seu WHM recebeu o update.
  23. Você pode criar um redirecionamento do subdomínio pra hospedagem ou criar um park do subdomínio em cima da hospedagem. Apontar o DNS não vai funcionar porque o servidor de destino vai receber a requisição e não vai saber qual site servir, você vai acabar vendo a página default do Cpanel
  24. Isso é só um aviso, não impede o mysql de iniciar corretamente nessa versão, mas indica que causará problemas nas versões futuras. Melhor remover esse parâmetro da configuração (/etc/my.cnf)
  25. Bom, de duas uma, ou teu servidor ainda tá rodando o Nginx de alguma forma, ou esse erro tá vindo de algum componente externo, que é carregado de um servidor que roda Nginx e está com esse problema. Por coincidência eu peguei um caso assim na semana passada. Era um banner no topo do site, também um WP, que carregava uma imagem de um servidor remoto. Esse servidor rodava Nginx e estava com instabilidade. Vez ou outra quando se abria o site o erro do Nginx aparecia. Talvez seja algo parecido, mas aqui era realmente só na parte do banner que o erro aparecia, não no site inteiro.
×
×
  • Criar Novo...

Informação Importante

Concorda com os nossos termos?