Invasões de hacker no index.htm

[MyWay Hosting]

pessoal, algumas contas (sempre as mesmas) estão tendo seus arquivos index.htm alterados (ou criados, caso eles não existam) com uma página de hacker e com vírus (pelo menos o chrome acusou). nada além disso é alterado. alguém sabe dizer o que posso corrigir para acabar com isso? mês passado fiz uma boa varredura, endureci algumas coisas, mudei as senhas dessas contas e hoje veio novamente a reclamação de um cliente e varrendo o servidor encontrei vários sites com esse arquivo index.htm enviado pelo hacker.

já tenho o modsecurity funcionando a mais de um ano, o maldetect está fazendo a varredura todo dia e o clamscan está varrendo no upload via ftp (isso configurei no mês passado achando que pudesse resolver algo). o csf está quase todo verdinho. tem alguns sites que nem arquivos tem e tem somente o index padrão (aquele que diz que o site foi hospedado na minha empresa).

o servidor é linux centos 5 x86 com cpanel. também tenho o suphp/suhoshin e as permissões nos arquivos/pastas estão todas ok.

Qual compilação do Apache e PHP está usando ?

1) Se for DSO, mude para SUPHP.

2) Endureça as configurações do php.ini central com

disable_functions = "dl, exec, shell_exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, shell-exec, fpassthru, crack_check, crack_closedict, crack_getlastmessage, crack_opendict, psockopen, symlink, ini_restore, posix_getpwuid, print_r"

3) Sim, o SUPHP não funciona com gerenciador de memória cache.

4) Instale o NGINX para aumentar a performance para sites estáticos

5) Ative o file cache do seu servidor para que a memória ram seja usada corretamente

6) Configure a pressão de cache + o que ele irá dropar na hora de descarregar a memória RAM para liberar visto que em um momento ele irá descarregar a ram para não dar falta de memória em seu servidor.

Segue um link para ver como gerenciar memória cache

https://gist.github.com/dakull/5629740

Procure mais no google.

Lembre que inodes e page vão para o cache e em um momento ela é descarregada.

Se seu servidor tem muita memória, configure pressão ZERO pro cache durante o dia e descarregue na noite. Monitore isso para não gerar swap.

Essas dicas de cache estou lhe passando porque vc falou sobre o uso de cache em SUPHP.

Não existe algo mais seguro que SUPHP.

Você está sofrendo um hack que muito provavelmente não seja devido a symlink hack e sim um script rodando e alterando rapidamente todas index. É um hack comum em servidores DSO que não tem absolutamente nenhuma segurança visto que os scripts rodam como nobody e podem a qualquer momento acessar qualquer conta no seu servidor.

Ter servidor não é algo fácil. Você irá precisar estudar bastante mas essas dicas são fundamentais para segurança e performance.

Espero ter ajudado.

Abraços !

Editado Julho 21, 2014 por MyWay Hosting

[redirect]

Qual compilação do Apache e PHP está usando ?

1) Se for DSO, mude para SUPHP.

2) Endureça as configurações do php.ini central com

disable_functions = "dl, exec, shell_exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, escapeshellcmd, escapeshellarg, shell-exec, fpassthru, crack_check, crack_closedict, crack_getlastmessage, crack_opendict, psockopen, symlink, ini_restore, posix_getpwuid, print_r"

3) Sim, o SUPHP não funciona com gerenciador de memória cache.

4) Instale o NGINX para aumentar a performance para sites estáticos

5) Ative o file cache do seu servidor para que a memória ram seja usada corretamente

6) Configure a pressão de cache + o que ele irá dropar na hora de descarregar a memória RAM para liberar visto que em um momento ele irá descarregar a ram para não dar falta de memória em seu servidor.

Segue um link para ver como gerenciar memória cache

https://gist.github.com/dakull/5629740

Procure mais no google.

Lembre que inodes e page vão para o cache e em um momento ela é descarregada.

Se seu servidor tem muita memória, configure pressão ZERO pro cache durante o dia e descarregue na noite. Monitore isso para não gerar swap.

Essas dicas de cache estou lhe passando porque vc falou sobre o uso de cache em SUPHP.

Não existe algo mais seguro que SUPHP.

Você está sofrendo um hack que muito provavelmente não seja devido a symlink hack e sim um script rodando e alterando rapidamente todas index. É um hack comum em servidores DSO que não tem absolutamente nenhuma segurança visto que os scripts rodam como nobody e podem a qualquer momento acessar qualquer conta no seu servidor.

Ter servidor não é algo fácil. Você irá precisar estudar bastante mas essas dicas são fundamentais para segurança e performance.

Espero ter ajudado.

Abraços !

 

obrigado pelas dicas, mas como eu já tinha dito no primeiro post eu já usava o suphp, e como o restante do tópico mostra que ao usar o cache ele foi desabilitado, então foi esse o problema. retirando o cache os problemas cessaram. mas estarei sempre de olho e caso algo novo acontece reportarei aqui.

[MyWay Hosting]

O uso do cache não iria "desativar o suphp". Isso acontece ao contrário. Quando você compila o php em modo suPHP o cache não funciona.

O problema cessou porque talvez tenham desistido de hackear seu servidor ou então a conta que estava insegura com scripts falhos foi desativada ou ainda teve scripts removidos.

Você precisa configurar o php.ini central e bloquear os comandos no disable_functions. Isso irá gerar uma camada extra de proteção.

Abraços

[Mr Bomber]

Existem algumas shells que a depender da configuração do servidor, com um clique você consegue fazer um pishing de vários index de várias contas ao mesmo tempo.

O ideal não é "matar" o arquivo com a shell, mas sim descobrir como que ela tá conseguindo subir no seu servidor.

SUPHP, modsecurity com boas regras, FollowSymLinks off, e várias funções desabilitadas no php.ini, podem ajudar ou talvez até resolver.

[rplab]

Bom no meu caso, consegui resolver o problema utilizando o Incube encrypted para encorpar as index, só assim consegui resolver os problemas relacionados a troca de index (conteúdo) e outros problemas, pois nem mesmo o datacenter sabia como parar os ataques, tanto que em apenas um dia houve 4 grandes ataques que em apenas 1 minuto10 segundos foram transmitidos 40 TB de dados.