Em Qua, 2009-05-13 às 13:54 -0400, Filipe Brandenburger escreveu:
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
Sim estou catando em todos os logs de todos os sites com grep e olhando e nada encontrado até agora mas tem muito à ver ainda pois são mais de 100 sites. Já fiz um bloqueio de firewall liberando OUTPUT somente as portas necessárias como 25/tcp, 53/udp e 53/udp. O restante está bloqueado e isso já vai impedir que ele baixe algo do servidor.
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.
Uma excelente idéia também. :) vou tentar ela caso não funcione o bloqueio que fiz com o iptables. ;)
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.
Sim, vou parar para dar uma olhada nisso com certeza. Até o momento nunca havia precisado.
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.
É o problema é que peguei recentemente esse servidor e nele já haviam pra lá de 100 páginas em PHP e já resolvi algumas com furos mas deve ter alguma ainda com certeza.
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.
Não acredito que o root dele tenha sido comprometido porque desde o download como o arquivo em questão foram feitos apenas com o usuário apache, tudo que foi criado no sistema estava como usuário apache e o processo era um processo filho do apache. Passei alguns programas para checagem como o rkhunter e outros e não encontrei nada suspeito mesmo.
Bem vamos ver como vai ficar depois desses bloqueios que fiz. :) Estou suspeitando que a falha possa estar no webmail porque além de antigo, é aquele webmiau ele é o único que grava arquivos no /tmp as outras páginas estão confinadas em seus diretórios.