A partir da leitura do link , parece que se o suexec estiver sendo usado corretamente, os scripts CGI serão executado como o usuário do Apache não deve ser uma preocupação, pois eles serão executados sob o usuário definido pelas diretivas do suexec.
Na configuração de um ambiente de hospedagem com vários sites que devem ser isolados uns dos outros, eu fiz o passo óbvio de ter o PHP configurado para ser executado como o usuário associado a cada site, em vez de ser o usuário do Apache, mas Existe alguma maneira de ter certeza de que não é possível que um site possa executar um script escrito em alguma outra linguagem (por exemplo, Python) como o usuário do Apache? Eu vi ataques inteligentes como o ataque symlink que usa regras de .htaccess e um symlink para enganar o Apache em servir arquivos PHP de outros sites como texto simples (isso não está relacionado à pergunta, apenas um exemplo), e desde então eu sou não muito familiarizado com a configuração de linguagens do lado do servidor diferentes do PHP, eu não sabia o que checar e / ou proibir, como via o arquivo conf Apache, para garantir que os scripts escritos em outras linguagens não pudessem ser executados como o usuário do Apache.
Por exemplo, mesmo que o PHP esteja configurado para rodar como usuário do site, se um site for hackeado, o hacker pode criar um arquivo .htaccess que configure arquivos .abc para executar como scripts Perl e se as coisas não estiverem configuradas corretamente no servidor, então eles são executados como o usuário do Apache?
Qual é a melhor maneira de abordar isso?
A partir da leitura do link , parece que se o suexec estiver sendo usado corretamente, os scripts CGI serão executado como o usuário do Apache não deve ser uma preocupação, pois eles serão executados sob o usuário definido pelas diretivas do suexec.
Assim, sua principal preocupação é que uma conta comprometida não possa fazer nada de mal a outras contas.
Permissões de PHP e arquivo
Se o PHP estiver configurado para ser executado como usuário diferente para cada domínio, seus diretórios deverão ser configurados de forma que não tenham acesso de gravação a nada fora de seu próprio domínio. Então, usando PHP (ou qualquer outro comando invocado via PHP) não pode causar nenhum dano ao resto do servidor.
A melhor prática é fazer com que os scripts sejam de propriedade de user1, mas o PHP deve ser executado sob user2. Para acesso do cliente, o FTP deve ser configurado para user1. User2 deve receber acesso de escrita somente para diretórios específicos onde realmente for necessário (cache dir, geração de thumbnails, upload de arquivos via PHP).
Mas muitas pessoas começam a instalar o Wordpress e outros CMS, não sabem o que fazer e dão acesso de gravação a tudo (então o plugin CMS mal escrito pode comprometer todos os scripts php para esse domínio). O Wordpress e outros CMS atualmente suportam instalação / atualização, mesmo sem permissões de gravação para o processo PHP (eles apenas solicitam login FTP e automaticamente o utilizam).
Outra prática recomendada é bloquear o acesso direto da Web aos diretórios em que o usuário2 possui acesso de gravação. Uploads de arquivos devem ser verificados pelo seu script, e somente se forem válidos, movidos para o diretório acessível de fora (caso contrário, alguém pode fazer upload de script PHP em vez de imagem JPG e pode enganar seu servidor web para executá-lo).
Apache
Use a diretiva AllowOverride None do Apache para desabilitar o uso do arquivo .htaccess , para que os ataques não possam configurar a execução de outros scripts CGI. O Apache deve ter apenas acesso de leitura aos arquivos servidos (os arquivos de configuração do PHP contendo senhas não precisam de permissões de leitura para o Apache). Com .htaccess desabilitado, o usuário não tem como alterar a configuração do Apache.
Use Options -FollowSymLinks (ou -SymLinksIfOwnerMatch ) para evitar o ataque "symink".
Instale mod_security para observar atividades suspeitas e bloquear tentativas de invasão, como a injeção de SQL.
EDITAR : Se .htaccess for necessário, você precisa decidir quais opções sua hospedagem suportará e ativar somente essas. Exemplos de opções comumente usadas que são seguras incluem (liste-as em AllowOverride ):
Deny from all para negar acesso a parte do diretório) FollowSymLinks , mas parece que funciona também com este); além do uso do mod_rewrite, o Apache só seguiria o symlink se o arquivo de destino / dir fosse proprietário pelo mesmo usuário que o symlink em si.