[CentOS-pt-br] Apache deixando criar arquivos maliciosos

[Marcelo Gondim]

Em Qua, 2009-05-13 às 13:54 -0400, Filipe Brandenburger escreveu:
> Olá,
> 
> 2009/5/13 Marcelo Gondim <gondim em 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.