Servidor próprio, site múltiplo: configuração PHP mais segura

Question

Temos um servidor da empresa com diversos sites. Eles são mantidos por pessoas diferentes dentro de nossa empresa. Todos os sites são públicos. O acesso ao servidor é limitado apenas à nossa empresa. Este não é um ambiente de hospedagem compartilhada.

Estamos procurando proteger o servidor, analisando atualmente o risco relacionado às permissões de arquivos. Nós sentimos que o maior risco é quando os arquivos são enviados e depois abertos / executados pelo público. Isso não deve acontecer, mas um erro em um script pode permitir que as pessoas o façam (há uploaders de imagens, uploaders de arquivos, etc). Scripts de uploader usam PHP.

Então a questão é: qual é a melhor maneira de configurar / organizar permissões de arquivos e processos? Parece haver várias opções para executar o PHP (e o Apache) e definir as permissões. O que devemos levar em consideração? Alguma dica?

Estamos considerando o mod_php e o FastCGI, mas talvez, dada a nossa situação, outras soluções sejam preferidas?

    

Answer 1

Eu recomendo executar suPHP . Usando o suPHP, cada site pode ser compartimentalizado para seu próprio nome de usuário em vez de ser executado como o usuário geral do Apache. Isso significaria que se alguém "invadisse" o servidor devido a um script inseguro no servidor; eles seriam limitados apenas a esse site e não a todo o servidor. A exceção é que, se houver uma exploração raiz, eles poderão obter acesso a todo o servidor ... mas pelo menos o suPHP ajudará na segurança de cada site individual.

Depois de ter o Apache / PHP em diferentes usuários, as permissões de leitura / gravação dos arquivos no servidor se tornam importantes. Você também pode utilizar as permissões mais amplamente do ponto de vista organizacional, permitindo que os usuários atualizem arquivos no site deles e não em qualquer outro.

    

Answer 2

Mais duas opções com segurança variável:

• suexec no apache. Apache pode comer memória. (e não funciona com fcgi eu acredito)

• dispositivos virtuais, um para cada site. Esta solução oferece claro maior liberdade em relação às versões php etc. (eu estou executando o openvz com grande sucesso).

respeita / t

    

Answer 3

• Por padrão, os uploads são armazenados em /var/tmp , então monte-o como +noexec +nosuid e configure seu Apache VirtualHost com php_flag engine 0 (ref: PHP manual) para os diretórios que conterão os arquivos enviados (se você precisar aceitar uploads de arquivos - caso contrário, defina file_uploads 0 em seu php.ini )

• Defina allow_url_fopen 0 em php.ini (apenas no caso de um dos seus codificadores ter a ideia brilhante de incluir URLs) e considere Suhosin se você tiver codificadores questionáveis na equipe

Answer 4

Em termos de mod_php / fastcgi eu prefiro a implementação do FastCGI do php-fpm que agora está incluso no PHP (desde 5.33). O PHP-FPM dá a cada "pool" (website) seus próprios processos (dinâmicos ou estáticos) dos quais serve o php. cada vhost dentro do apache / nginx se conecta ao seu próprio conjunto php-fpm em uma porta específica (ou seja, 9000). Isto é essencialmente realizando a mesma coisa que suExec em que cada requisição / processo do php é "Exec" como seu próprio usuário (você especifica user: group para cada pool, que deve ser chrooted / jailed).

Isso também proporciona um controle mais granular do uso de memória e separa o processamento de arquivos / imagens estáticas e conteúdo dinâmico (php.) Devido a essa separação, o apache não carrega o PHP em seus processos ao servir conteúdo estático. Ao usar o mod_php, cada requisição de um usuário vai requerer um processo de ~ 40MB, mesmo que seja um pedido estático (sendo 30 deles php). Pelo menos esse é o meu entendimento ... por favor corrija-me se estiver errado.

Você pode configurar um pool (www.domain1.com) para ter 5 processos PHP estáticos para manipular solicitações e outro pool (www.domain2.com) para ter 10 processos no mínimo e 30 no máximo.

link

    

Answer 5

Por certo, isso não deve acontecer - e se você é o administrador do site , é sua culpa que aconteceu

We are considering mod_php and FastCGI,

Isto não tem nada a ver com os problemas que você está tendo atualmente nem como você faz para tornar o sistema seguro.

A primeira coisa que você precisa é de um modelo de permissões e processos para suportar a implantação de código no servidor de maneira controlada.

Uma abordagem seria configurar um grupo para cada projeto que exclui o servidor da Web uid e, em seguida, implantar todos os arquivos como rw-rw-r para o usuário e o grupo de desenvolvimento - o servidor da Web depende de permissões 'outros' para ler arquivos. Configure todos os diretórios com o grupo de bits pegajosos definido.

Cada projeto deve estar em seu próprio subdiretório dentro da raiz do documento, e cada projeto deve ter uma pasta de upload gravável pelo servidor web fora da raiz do documento, e pelo menos um dedicado (por grupo) incluir dir fora da raiz do documento ( por preferência cada um deve estar em seu próprio vhost). O acesso deve ser restrito por open_basedir

Publique um padrão de codificação que deve especificar que as permissões não podem ser manipuladas a partir das configurações padrão - e ajuste seu IDS para pegar em quaisquer arquivos PHP adicionados ou permissões alteradas.

Mas existem outros modelos.

O importante é que:

• O servidor da Web nunca deve poder gravar em arquivos acessíveis diretamente pelo servidor da Web.

• Se o conteúdo enviado pelo usuário tiver que ser acessado, ele deve ser higienizado ao carregar e acessado mediado por um script do controlador.

• no caso de código malicioso ser implantado no servidor, ele deve ser estritamente limitado na quantidade de danos que pode causar

• deve ser possível detectar quando as alterações de código são feitas no sistema

• Seu modelo de permissões deve impedir que um projeto interfira no comportamento de outro projeto (por exemplo, suponha que você tivesse um diretório comum 'include' - mesmo que os projetos diferentes não pudessem corrigir os arquivos dos outros, eles poderiam mascarar comportamentos usando o mesmo nome de arquivo em outro lugar no caminho include - ou pior, crie erros usando a mesma função ou nome de classe duas vezes).