Como proteger o Apache para o ambiente de hospedagem compartilhada? (chrooting, evite o symlinking…)

1

Estou tendo problemas para lidar com a configuração do Apache: o problema é que eu quero limitar cada usuário ao seu próprio docroot (assim, um chroot () seria o que eu estava procurando), mas:

  • O mod_chroot funciona apenas globalmente e não para cada host virtual: eu tenho os usuários em um caminho como o seguinte /home/vhosts/xxxxx/domains/domain.tld/public_html (xxxxx é o usuário) e não posso resolver o problema chrooting /home/vhosts , porque os usuários ainda ser permitido ver um ao outro.
  • O uso do apache-mod-itk desaceleraria muito os sites, e não tenho certeza se isso resolveria qualquer coisa
  • Sem usar nenhum dos dois anteriores, acho que a única coisa que resta é evitar o symlinking, não permitindo que os usuários vinculem a algo que não pertence a eles.

Então, eu acho que vou seguir o terceiro ponto, mas ... como evitar eficientemente o symlinking enquanto ainda mantém o mod_rewrite funcionando ?!
O php já foi chrooted com o php-fpm, então minha única preocupação é com o próprio Apache.

    
por Alessio Periloso 26.06.2012 / 23:19

2 respostas

1

Por que você precisa restringir o próprio apache? Não seria melhor / suficiente bloquear seu tempo de execução de script (php, Perl, ruby, ...) em um chroot? Se sim, veja mod_fastcgi e como iniciar um intérprete persistente para o (s) idioma (s) específico (s) que você precisa.

    
por 27.06.2012 / 10:27
1

Qualquer um que se deparar com essa postagem faria bem em observar que o Apache descreve SymLinksIfOwnerMatch como não sendo uma medida de segurança adequada:

This option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable."
(from http://httpd.apache.org/docs/2.2/mod/core.html#options).

Além de não permitir totalmente os links simbólicos e impedir que os usuários substituam essa configuração nos arquivos .htaccess, para ver um resumo das soluções disponíveis para evitar ataques de links simbólicos, confira link (não é apenas específico do cPanel).

    
por 17.07.2015 / 01:16