Hospedagem em vários sites - falta de vulnerabilidade importante para proteger sites um do outro?

EDIT # 2 23 de julho de 2015: Procurando uma nova resposta que identifique um item de segurança importante esquecido na configuração abaixo ou possa dar motivos para acreditar que tudo está coberto.

EDIT # 3 29 de julho de 2015: Estou procurando especialmente por uma possível configuração incorreta, como permitir inadvertidamente algo que possa ser explorado para contornar restrições de segurança ou, pior ainda, deixar algo em aberto.

Essa é uma configuração de hospedagem compartilhada / em vários sites e queremos usar uma instância compartilhada do Apache (ou seja, é executada em uma conta de usuário), mas com o PHP / CGI sendo executado como usuário de cada site, para garantir que nenhum site possa acessar os arquivos de outro site, e queremos verifique se nada está faltando (por exemplo, se não soubéssemos sobre a prevenção de ataques de links simbólicos).

Aqui está o que eu tenho até agora:

• Certifique-se de que os scripts PHP sejam executados como a conta e o grupo de usuários Linux do site e estejam presos (como o CageFS) ou pelo menos adequadamente restritos usando as permissões do sistema de arquivos Linux.
• Use suexec para garantir que os scripts CGI não possam ser executados como usuário do Apache.
• Se precisar de suporte de inclusão no servidor (como em arquivos shtml), use Options IncludesNOEXECpara impedir que o CGI possa ser executado quando você não espera (embora isso não deva ser uma grande preocupação se você estiver usando o suexec).
• Tenha a proteção contra ataques de link simbólico para que um hacker não consiga convencer o Apache a exibir os arquivos de outro site como texto sem formatação e a divulgar informações exploráveis, como senhas de banco de dados.
• Configure AllowOverride/ AllowOverrideListpara permitir apenas quaisquer diretivas que um hacker não possa explorar. Eu acho que isso é menos preocupante se os itens acima forem feitos corretamente.

Eu usaria o MPM ITK se não fosse tão lento e não rodasse como root, mas estamos especificamente querendo usar um Apache compartilhado e ainda assim garantir que seja feito com segurança.

Encontrei http://httpd.apache.org/docs/2.4/misc/security_tips.html , mas não foi abrangente sobre este tópico.

Se é útil saber, estamos planejando usar o CloudLinux com CageFS e mod_lsapi.

Existe mais alguma coisa para se certificar de fazer ou conhecer?

EDIT 20 de julho de 2015: As pessoas enviaram boas soluções alternativas que são valiosas em geral, mas observe que esta pergunta é direcionada apenas à segurança de uma configuração compartilhada do Apache. Especificamente, há algo não coberto acima que poderia permitir que um site acesse os arquivos de outro site ou comprometa outros sites de alguma forma?

Obrigado!

Concordo plenamente com os itens que você tem até agora.

Eu costumava executar essa configuração para vários usuários há alguns anos e basicamente encontrei o mesmo problema: mod_php é rápido (em parte porque tudo é executado dentro do mesmo processo) e suexec é lento, mas seguro (porque cada solicitação bifurca um novo processo). Fui com o suexec, porque era necessário o isolamento do usuário.

Atualmente existe uma terceira opção que você pode considerar: dar a cada usuário seu próprio daemon php-fpm. Se isso é viável depende do número de usuários, porque cada um deles precisa obter pelo menos um processo php-fpm usando sua conta de usuário (o daemon então usa um mecanismo semelhante ao pré-fork para escalar solicitações, portanto, o número de processos e o uso de memória pode ser um fator limitante). Você também precisará de uma geração automatizada de configurações, mas isso deve ser possível com alguns scripts de shell.

Eu não usei esse método em ambientes grandes, mas o IMHO é uma boa solução para fornecer um bom desempenho do site PHP, enquanto ainda isola os usuários no nível do processo.

Tudo o que você tem até agora parece bem pensado. A única coisa que eu pude ver como um problema é o fato de a maioria das explorações procurar obter acesso root de uma maneira ou de outra. Portanto, mesmo que cada site e seus processos e scripts correspondentes sejam presos corretamente e tudo tenha seu próprio usuário e permissões que um hacker com raiz não poderia se importar menos, eles apenas evitarão tudo o que você configurou.

Minha sugestão seria usar algum tipo de software de VM (VMware, VirtualBox, Qemu, etc) para dar a cada site sua própria prisão de SO. Isso permite que você, como administrador do sistema, não se preocupe com um único site comprometido. Se um hacker obtém raiz explorando php (ou qualquer outro software) na VM de um site, basta pausar a VM e dissecá-la mais tarde, aplicar correções ou reverter para um estado ininterrupto. Isso também permite que os administradores do site apliquem software ou configurações de segurança específicas ao seu ambiente de site específico (que pode quebrar outro site).

A única limitação para isso é o seu hardware, mas com um servidor decente e as extensões de kernel corretas, é fácil lidar com isso. Eu executei com êxito esse tipo de configuração em um Linode, pois o Host e o Guest eram muito muito escassos. Se você está confortável com a linha de comando que eu presumo, você não deve ter nenhum problema.

Esse tipo de configuração reduz o número de vetores de ataque que você precisa monitorar e permite que você se concentre na segurança das Máquinas Host e lide com todo o resto, site por site.

Eu sugeriria que cada site fosse executado sob seu próprio daemon Apache e fiz o Apache com chroot. Toda a função php do sistema falhará, pois o ambiente chroot do Apache não terá acesso ao / bin / sh. Isso também significa que a função mail () do php também não funcionará, mas se você estiver usando um provedor de email externo para enviar emails do seu aplicativo de email, isso não deverá ser um problema para você.

O SELinux pode ser útil mod_selinux. Um rápido tutorial é apresentado aqui:

Como posso usar o SELinux para limitar scripts PHP?

Como as instruções são um pouco datadas, verifiquei se isso funciona no RHEL 7.1:

Eu usei a versão do Fedora 19 e compilei com simulação contra o RHEL 7.1 + EPEL.

YMMV se você usar o mock básico da configuração do epel, é fornecido com:

[mockbuild@fedora mod_selinux]$ mock -r rhel-7-x86_64 --rebuild \
    mod_selinux-2.4.3-2.fc19.src.rpm

Atualize seu sistema de destino primeiro para garantir que selinux-policyseja atual.

Instale na caixa de destino (ou instale primeiro no seu espelho local):

yum localinstall mod_selinux-2.4.3-2.el7.x86_64.rpm

Agora, você deve atribuir a cada host virtual no apache uma categoria. Isso é feito adicionando uma linha como no exemplo abaixo chamado selinuxDomainVal.

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host1
    ServerName host1.virtual
    selinuxDomainVal *:s0:c0
</VirtualHost>

<VirtualHost *:80>
    DocumentRoot /var/www/vhosts/host2
    ServerName host2.virtual
    selinuxDomainVal *:s0:c1 
</VirtualHost>

Em seguida, na raiz do documento para cada host, renomeie suas raízes de documento para a mesma categoria que as rotuladas na configuração do httpd.

chcon -R -l s0:c0 /var/www/vhosts/host1
chcon -R -l s0:c1 /var/www/vhosts/host2

Se você deseja fazer com que a rotulagem seja respeitada se fizer uma nova redefinição do sistema, é melhor atualizar também a política local!

semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c0 '/var/www/vhosts/host1(/.*)?' 
semanage fcontext -a -t httpd_sys_content_t -r s0-s0:c1 '/var/www/vhosts/host2(/.*)?'

Já existem muitas respostas técnicas boas (consulte também: https://security.stackexchange.com/q/77/52572 e Dicas para proteger um servidor LAMP ), mas eu ainda gostaria de mencionar aqui um ponto importante (de outra perspectiva) sobre a segurança: a segurança é um processo . Tenho certeza de que você já considerou isso, mas ainda espero que seja útil (também para outros leitores) às vezes repensá-lo.

Por exemplo, na sua pergunta, você se concentra principalmente nas medidas técnicas: "essa pergunta é direcionada apenas à segurança de uma configuração compartilhada do Apache. Especificamente, existem etapas de segurança que são importantes a serem seguidas, mas que estão ausentes na lista acima ao executar o compartilhamento compartilhado Apache e PHP. "

Quase todas as respostas aqui e em outras 2 perguntas que eu mencionei também parecem ser puramente técnicas (exceto a recomendação de se manter atualizado). E, do meu ponto de vista, isso pode causar a impressão de alguns leitores enganosos: se você configurar seu servidor de acordo com as melhores práticas uma vez, ficará seguro para sempre. Então, por favor, não esqueça os pontos que eu sinto falta nas respostas:

1. Antes de tudo, não esqueça que a segurança é um processo e, em particular, sobre o ciclo "Planeje-faça-verifique-aja", conforme recomendado por muitos padrões, incluindo a ISO 27001 ( http://www.isaca.org/ Journal / archives / 2011 / Volume-4 / Pages / Planejando e implementando-ISO27001.aspx ). Basicamente, isso significa que você precisa revisar regularmente suas medidas de segurança, atualizá-las e testá-las .

2. Atualize seu sistema regularmente. Isso não ajudará contra ataques direcionados usando vulnerabilidades de dia zero, mas ajudará contra quase todos os ataques automatizados.

3. Monitore seu sistema. Estou realmente perdendo este ponto nas respostas. Do meu ponto de vista, é extremamente importante ser notificado o mais cedo possível sobre algum problema com o seu sistema.

   É o que diz a estatística: "O tempo médio entre a infiltração e a descoberta é de 173,5 dias" ( http://www.triumfant.com/detection.html ), "número médio de 205 dias antes da detecção" ( https: // www2 .fireeye.com / rs / fireye / images / rpt-m-trends-2015.pdf ). E espero que esses números não sejam o que todos queremos ter.

   Existem muitas soluções (inclusive gratuitas) não apenas para monitorar o estado do serviço (como o Nagios), mas também sistemas de detecção de intrusão (OSSEC, Snort) e sistemas SIEM (OSSIM, Splunk). Se ficar muito complicado, você poderá pelo menos ativar algo como 'fail2ban' e / ou encaminhar seus logs para um servidor syslog separado e receber notificações por email sobre eventos importantes.

   Novamente, o ponto mais importante aqui não é qual sistema de monitoramento você escolhe, o mais importante é que você tenha algum monitoramento e o revise regularmente de acordo com o seu ciclo "Planejar-Fazer-Verificar-Agir" .

4. Esteja ciente das vulnerabilidades. O mesmo que monitoramento. Basta assinar uma lista de vulnerabilidades para ser notificado, quando alguma vulnerabilidade crítica for descoberta para o Apache ou outro serviço importante para a sua instalação. O objetivo é ser notificado sobre as coisas mais importantes que aparecem antes da sua próxima atualização planejada.

5. Planeje o que fazer em caso de incidente (atualize-o e revise-o regularmente, de acordo com o ciclo "Planejar-fazer-verificar-agir"). Se você fizer perguntas sobre a configuração segura, isso significa que a segurança do seu sistema se torna importante para você. No entanto, o que você deve fazer caso o sistema seja invadido, apesar de todas as medidas de segurança? Novamente, não quero dizer apenas medidas técnicas aqui, como "reinstalar o SO": onde você deve denunciar um acidente de acordo com a lei aplicável? Você tem permissão para desligar / desconectar seu servidor imediatamente (quanto custa para sua empresa)? Quem deve ser contatado se a principal pessoa responsável estiver de férias / doente?

6. Tenha um servidor de backup, archive e / ou substituição / replicação. Segurança também significa disponibilidade do seu serviço. Verifique seu backup / arquivamento / replicação regularmente e também teste os procedimentos de restauração regularmente.

7. Teste de penetração? (novamente, consulte o ciclo "Planeje-faça-verifique-aja") Se parecer demais, você pode pelo menos experimentar algumas ferramentas on-line gratuitas, que analisam seus serviços da Web em busca de problemas de malware e segurança.

Seu caso de uso é ideal para contêineres de encaixe.

Cada contêiner pode representar um cliente ou cliente, com IDs de usuário exclusivos atribuídos a cada grupo de contêineres Apache como segurança adicional. A chave seria eliminar privilégios de root no início do contêiner, antes de iniciar sua pilha apache. Cada cliente obtém seu próprio serviço de banco de dados com suas próprias senhas exclusivas, sem a dor de cabeça de levantar dezenas de máquinas virtuais, cada uma exigindo seus próprios núcleos especiais de floco de neve e outras despesas gerais. Afinal, o coração do estivador é o chroot. Administrado adequadamente, eu assumiria isso em um cluster virtual típico a qualquer dia.

Muitas boas sugestões aqui já. Há coisas que foram perdidas na discussão até agora.

Preste atenção aos processos fora daqueles executados como parte da veiculação de páginas da web. ou seja, verifique se todos os seus trabalhos cron que tocam em dados não confiáveis ​​estão sendo executados como o usuário apropriado e na prisão apropriada, independentemente de esses trabalhos serem definidos pelo usuário ou não.

Na minha experiência, coisas como análise de log, quando fornecidas pelo serviço de hospedagem, são executadas como root quase sempre e o software de análise de log não recebe a auditoria de segurança que desejarmos. Fazer isso bem é um pouco complicado e depende da configuração. Por um lado, você não deseja que seu processo apache de propriedade da raiz (ou seja, o processo pai) grave em qualquer diretório que o usuário possa comprometer. Isso provavelmente significa não escrever diretamente na prisão. Por outro lado, você precisa disponibilizar esses arquivos para os processos na cadeia para análise, e você gostaria que isso fosse o mais próximo possível do tempo real. Se você puder conceder às suas cadeias acesso a uma montagem somente leitura de um sistema de arquivos com os logs, isso deve ser bom.

Aplicativos PHP normalmente não veiculam seus próprios arquivos estáticos, e se você tiver um processo apache compartilhado, acho que seu processo apache está lendo coisas diretamente das cadeias do ambiente host? Nesse caso, isso abre uma variedade de preocupações.

.htaccessos arquivos são óbvios, onde você precisa ter muito cuidado com o que permite. Muitos aplicativos php, senão os mais substanciais, dependem muito da organização dos arquivos .htaccess que você provavelmente não pode permitir sem subverter o esquema planejado.

Menos óbvio é como o apache decide o que é um arquivo estático de qualquer maneira. eg O que faz com um arquivo *.php.gifou *.php.en? Se esse mecanismo ou outro engana a discriminação sobre o que é um arquivo estático, é possível que o apache execute php de fora da prisão? Eu configuraria um servidor Web leve e separado para conteúdo estático, que não está configurado com nenhum módulo para a execução de conteúdo dinâmico, e teria um balanceador de carga decidindo quais solicitações enviar ao servidor estático e quais ao dinâmico.

Com relação à sugestão do Stefan's Docker, é possível ter um único servidor da web que fica fora do contêiner e que conversa com os daemons php em cada contêiner pelo conteúdo dinâmico, além de ter um segundo servidor da web que fica em um contêiner do docker, e que compartilha os volumes que cada um usa para seu conteúdo e, portanto, é capaz de veicular o conteúdo estático, o mesmo que no parágrafo anterior. Recomendo o docker entre as várias abordagens de tipo de prisão, mas com essa ou outras abordagens de tipo de prisão, você terá vários outros problemas para resolver. Como funciona o upload de arquivos? Você coloca daemons de transferência de arquivos em cada contêiner? Você adota uma abordagem baseada em git no estilo PAAS? Como você torna acessíveis os logs gerados dentro do contêiner, e rolá-los? Como você gerencia e executa tarefas cron? Você concederá aos usuários algum tipo de acesso ao shell e, nesse caso, esse é outro daemon dentro do contêiner? etc etc.

A primeira coisa que não vejo é o gerenciamento de processos, de modo que um processo não pode passar fome por outro processo de CPU ou RAM (ou E / S, apesar de seu sistema de arquivos estar arquitetado para evitar isso). Uma grande vantagem de uma abordagem de "contêineres" para suas instâncias PHP versus tentar executá-las todas em uma imagem de "SO" é que você pode restringir melhor a utilização de recursos dessa maneira. Sei que esse não é o seu design, mas é algo a considerar.

Enfim, voltando ao caso de uso do PHP rodando atrás do Apache, basicamente funcionando como proxy. O suexec não impede que algo seja executado como usuário apache - ele oferece a capacidade de executar como outro usuário. Portanto, uma preocupação é garantir que tudo seja feito corretamente - a página de documentos denota esse perigo potencial: https://httpd.apache.org/docs/2.2/suexec.html . Então, você sabe, grão de sal e tudo isso.

Do ponto de vista de segurança, pode ser útil ter um conjunto restrito de binários de usuário para trabalhar (que a cagefs fornece), principalmente se eles são compilados de maneira diferente ou em uma biblioteca diferente (por exemplo, uma que não inclua recursos indesejados), mas o O perigo é que, nesse ponto, você não esteja mais seguindo uma distribuição conhecida para atualizações, esteja seguindo uma distribuição diferente (cagefs) para suas instalações PHP (pelo menos no que diz respeito às ferramentas de espaço do usuário). Embora você provavelmente já esteja seguindo uma distribuição específica com o cloudlinux, isso representa um risco incremental, não necessariamente interessante por si só.

Deixaria AllowOverride onde você poderia ter pretendido. A idéia principal por trás da defesa em profundidade é não confiar em uma única camada para proteger toda a sua pilha. Sempre assuma que algo pode dar errado. Mitigue quando isso acontecer. Repita até mitigar o máximo possível, mesmo que você tenha apenas uma cerca na frente dos sites.

O gerenciamento de logs será fundamental. Com vários serviços em execução em sistemas de arquivos isolados, a integração de atividades para correlacionar quando há um problema pode ser uma pequena dor se você não tiver configurado isso desde o início.

Esse é o meu despejo cerebral. Espero que haja algo vagamente útil lá. :)