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

Renato de Oliveira Diogo renato.diogo em gmail.com
Quarta Maio 13 19:22:12 UTC 2009


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 em gmail.com
renato.diogo em yahoo.com.br



2009/5/13 Filipe Brandenburger <filbranden em gmail.com>:
> 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
> 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 em centos.org
> http://lists.centos.org/mailman/listinfo/centos-pt-br
>


Mais detalhes sobre a lista de discussão CentOS-pt-br