Alem de outra coisa que devemos considerar.
claramente o problema é a aplicação (o site), pois esse tipo de filtro, tratamento quem deveria garantir é a aplicação.
Agora vamos tentar separar algumas coisas: o apache é uma coisa, o php é outra coisa e assim vai. Então voce pode, por motivos de teste, colocar o php para rodar em modo seguro (do php).
No log, como o Felipe indicou, você pode ter uma ideia de como o hacker está se comportando, adaptando os filtros do mod-security para filtrar o hack.
[]s
Atenciosamente ________________________________________________ Renato de Oliveira Diogo
Bacharel em Ciência da Computação UNESP - Bauru
LPIC1 - Linux Professional Institute Certification - Nível 1
renato.diogo@gmail.com renato.diogo@yahoo.com.br
2009/5/13 Filipe Brandenburger filbranden@gmail.com:
Olá,
2009/5/13 Marcelo Gondim gondim@linuxinfo.com.br:
Pois é todas as páginas tem essa instrução e o /tmp. Mas é no /tmp mesmo que ele tá colocando o arquivo e rodando. Não posso restringir permissão de escrita porque alguma aplicação que ainda estou vendo grava arquivos sess_????? no /tmp, provavelmente é o webmail.
Primeiramente, uma olhada nos logs do Apache pode dar uma boa dica de "como" o hacker está entrando. A partir daí você pode começar a entender qual aplicação web é o problema e talvez tirá-la (ou uma parte dela) do ar. Talvez colocar o IP do hacker no iptables possa ajudar a aliviar o problema.
Como uma gambiarra para resolver o seu problema rapidamente, você pode criar uma partição adicional e montá-la no /tmp usando a opção noexec (pode user nodev e nosuid também). Dessa forma, mesmo que o hacker consiga criar um arquivo no /tmp, ele não vai conseguir executá-lo tão facilmente.
A médio termo, você deve pensar em implementar o SELinux, porque ele introduz restrições que vão tornar ainda mais difícil de alguém conseguir executar código na sua máquina a partir de uma aplicação web furada. O SELinux pode ser difícil de implementar no início, algumas aplicações podem precisar de configurações especiais, mas o retorno em segurança faz o esforço valer a pena.
E, obviamente, você deve deixar de rodar essas aplicações furadas. Se você está rodando aplicações open source, você deve procurar as últimas versões e ver se a equipe de desenvolvimento é consciente em relação a segurança. Se as suas aplicações são desenvolvidas in-house, você deve mostrar para os desenvolvedores o problema que a aplicação deles gerou, e indicar que o código seja revisado por um especialista em segurança antes de ser instalado no servidor.
Finalmente, se seu servidor foi comprometido, você não tem mais como garantir que está limpo e que o hacker não deixou nenhuma porta escondida que você não achou. A única coisa que você tem a fazer agora, depois de descobrir o que causou o problema e corrigir o bug, é reinstalar o servidor do zero, sem usar nenhum executável que esteja instalado agora, só backups de antes dele ser hackeado. Qualquer coisa diferente disso pode trazer surpresas para você no futuro.
HTH, Filipe _______________________________________________ CentOS-pt-br mailing list CentOS-pt-br@centos.org http://lists.centos.org/mailman/listinfo/centos-pt-br