Problema crítico com a permissão www-data

3

Estou usando um servidor web apache no debian, lidando com 12 sites diferentes. Dois dias atrás eu sofri um ataque e um hacker enviou um shell php através de ftp em um desses 12 sites.

O que eu queria sobre este shell, é "bah, isso só pode acessar a pasta www, ele não pode voltar", mas aqui está o problema, com esse shell ele pode acessar até mesmo a pasta / e ver todos as pastas-documentos que ele queria (mailq, usuários, todos os arquivos de sites ...), ele poderia navegar por TODOS os meus vps assistindo todos os documentos e seu conteúdo (sem modificá-los!), sem modificá-los.

Eu estive pensando nesses últimos dias sobre isso e suspeito que seja um problema de permissão de dados www ou algo assim, mas não encontrei nenhuma solução.

Então, como eu poderia fazer isso se eu navegar no site1.com (no meu vps) eu estaria usando um usuário que só poderia acessar a esse diretório?

Em qualquer palavra, se um hacker fizer o upload de um shell php novamente, eu quero que ele não olhe para o resto dos documentos por trás /var/www/site1.com/www/

Obrigado pessoal!

    
por user61264 23.11.2010 / 17:52

2 respostas

1

O que você pediu é uma boa ideia, mas na prática pode ser muito difícil de implementar.

Não há realmente nenhuma maneira de impedir que o invasor veja arquivos acessíveis ao servidor da web ... porque o ataque está chegando via servidor da web, não é possível bloquear o acesso sem tornar os arquivos completamente inacessíveis. Você pode proteger outros dados confidenciais em seu sistema, certificando-se de que eles só possam ser acessados por grupos específicos ... por exemplo, certifique-se de que apenas o grupo "mail" possa acessar nosso mailq. Isso significa (a) criar os grupos necessários, (b) definir as permissões necessárias de arquivo / diretório e (c) assegurar que qualquer daemons seja executado com as credenciais corretas.

Se você está procurando uma solução mais robusta, pode usar algum tipo de solução leve de virtualização (por exemplo, Linux Containers, link ) para criar servidores privados virtuais para cada site, mas isso exige mais tempo e recursos.

Você pode executar cada website como um ID de usuário separado. Isso é um pouco complicado; o mais fácil é executar uma instância do Apache para cada site em uma porta específica e usar o módulo Proxy do Apache para delegar acesso do seu servidor principal na porta 80. Como essa solução envolve uma instância do Apache por site, ela também tem conseqüências de recursos. Existem módulos que permitem realizar isso em uma única instância do Apache, consulte link para um exemplo.

    
por 23.11.2010 / 18:04
1

Eu recomendaria usar um ambiente chroot'ed com mod_security . Desta forma, qualquer comprometimento do daemon do Apache (ou o usuário do chroot do qual o Apache é executado) irá apenas expor a árvore do chroot, não o servidor inteiro em si.

Documentação aqui: link

    
por 23.11.2010 / 18:09