Forma recomendada de restringir usuários do Apache

Question

Seguindo por que devemos restringir os usuários do Apache , mais dois perguntas surge:

1. Qual é o método recomendado de restringindo os lugares usuários do Apache pode atravessar & leia no arquivo sistema?
2. O que fazer contra as bombas de garfos e outros problemas de script de shell? (bash scripting é permitido)

Minhas soluções possíveis (prefiro saber qual solução você escolhe e por quê):

1. chroot OU mod_chroot
2. desabilitar o bash OU usar BASH restrito

Por favor, ofereça outras soluções se achar apropriado. (talvez o selinux seja?)

Estado atual:

• Os usuários têm permissão para executar scripts bash (via PHP, por exemplo)
• o suexec está ativo
• As solicitações do Apache são atendidas com o FastCGI para PHP

Editar:

Desculpe por não fornecer a recompensa ainda. A última coisa que preciso saber é sobre a questão # 2: quando o script do bash é permitido via PHP, como posso defender o meu sistema de ataques (garfo bombas, leitura de dados sensíveis)? O SELinux / Apparmor pode se defender contra essas coisas?

    

Answer 1

SELinux ou Apparmour são as formas mais sérias de alcançar um nível realmente alto de segurança, e não apenas para aplicativos da web. Eles não são simples, no entanto, muitas distribuições modernas fizeram muito para integrá-los, Redhat / SELinux e Ubuntu / Apparmour (com este último considerado "mais fácil" de manter).

Se a segurança é algo que você quer examinar seriamente, eu recomendo começar com eles o mais rápido possível!

    

Answer 2

Use suexec , execute o PHP como um serviço FastCGI (talvez com safe_mode e open_basedir , mas eles serão descontinuados no futuro). Devido a suexec , eles não devem ter permissão para entrar em outros diretórios, desde que cada site tenha seu próprio usuário especializado, por exemplo, user1 para /var/www/www.website1.com/ e user2 para /var/www/www.website2.com/ .

Modifique seu /etc/fstab para não permitir arquivos executáveis em /tmp .

Se você for realmente paranóico, você pode desabilitar o CGI / FastCGI e configurar o Apache para fazer proxy para aplicativos independentes do seu software (aplicativos Ruby on Rails, aplicativos Catalyst etc.). Que por sua vez são executados por seus respectivos usuários.

    

Answer 3

A tendência atual é apenas executar a virtualização leve (openvz, lxc, etc) e separar clientes no sistema.

Isso não oferece 100% de separação dos recursos, mas reduz muito os riscos associados ao compartilhamento de recursos entre vários clientes.

Em geral, hospedagem compartilhada == segurança compartilhada, você pode ter certeza de que alguém vai abusar dela, não importa o quanto você a esteja endurecendo;)

    

Answer 4

Para garantir que os CGIs gerados por apache sejam executados como o usuário que os possui, confio em suPHP ; ele não está limitado ao PHP, pode manipular CGIs arbitrários com qualquer interpretador e fornece um ambiente relativamente controlável no qual executá-los. Uma vez que você cravou os usuários em funcionamento como contas sem privilégios, é uma questão de proteger o sistema contra usuários com privilégios de login normalmente (limites de processo e memória por usuário, políticas do SELinux para proteger arquivos de sistema não administradores usuários, etc).