NGINX e PHP FPM - problemas gerais de configuração e desempenho usando open_basedir

Question

Eu quero configurar um servidor NGINX, que é capaz de hospedar vários sites, que são separados uns dos outros, então vhosta não pode acessar arquivos de vhostb .

Instalei um novo servidor Debian 7.5 e instalei o NGINX e o PHP FPM dos pacotes debian padrão.

Depois, adicionei 2 novos usuários vhosta e vhostb e adicionei o usuário www-data do servidor NGINX ao grupo de cada usuário.

Em seguida, criei a seguinte estrutura de diretórios.

   var/
    |---www/
    |---vhosta
         |---httpdocs (permissions 750 - owner: vhosta - group: vhosta)
    |---vhostb
         |---httpdocs (permissions 750 - owner: vhostb - group: vhostb)

Configurei um pool PHP FPM individual para cada host virtual para separar os processos PHP de cada host virtual. A configuração é a seguinte (mostrando apenas para vhosta )

[vhosta]
listen = /var/run/php5-fpm-vhosta.sock
user = vhosta
group = vhosta
listen.owner = vhosta
listen.group = vhosta

Em minha opinião, essa configuração deve separar vhosta do acesso a arquivos no diretório vhostb's httpdocs, pois vhosta não tem permissões de acesso à pasta httpdocs de vhosta . Eu verifiquei isso, tentando criar um script PHP simples em vhosta , que tenta acessar arquivos no diretório vhostb's httpdocs.

Até agora, tudo bem. Eu instalei um aplicativo PHP (CMS) em vhosta e fiz alguns testes de desempenho com o ApacheBench.

Geralmente, tudo corre mais suave e rápido do que com o Apache2 e acabarei com o seguinte resultado.

Requests per second:    31.62 [#/sec] (mean)
Time per request:       316.209 [ms] (mean)
Time per request:       31.621 [ms] (mean, across all concurrent requests)
Transfer rate:          430.58 [Kbytes/sec] received

Bem, 31,62 solicitações por segundo estão bem para mim neste momento.

Por último, quero acessar a restrição de vhosta e vhostb a um subconjunto de diretórios, para que eles não tenham acesso a outros arquivos de sistema legíveis do mundo. Eu faço isso, usando a diretiva do PHP open_basedir.

Eu adicionei o seguinte a cada conjunto de PHP FPM de hosts virtuais (apenas mostrando vhosta )

php_admin_value[open_basedir] = /var/www/vhosta/httpdocs/:/tmp/

Ao fazer isso, os vhosts não poderão acessar, e. / etc / passwd. Eu criei um script PHP simples, que verifica se os vhosts não podem acessar arquivos fora dos diretórios configurados.

Finalmente, eu repeti o teste de desempenho e terminei com o seguinte resultado.

Requests per second:    11.82 [#/sec] (mean)
Time per request:       8460.087 [ms] (mean)
Time per request:       84.601 [ms] (mean, across all concurrent requests)
Transfer rate:          161.18 [Kbytes/sec] received

Parece que adicionar uma diretiva open_basedir ao conjunto PHP FPM causa um grande decréscimo no desempenho. Os tempos de acesso e a quantidade de solicitações por segundo agora são bastante semelhantes em comparação com uma configuração usando o Apache2 com mod_php.

Minhas perguntas são as seguintes:

1. A configuração que criei pode ser considerada "segura", portanto, os vhosts individuais não podem acessar um ao outro? Se não, qual é a melhor prática para fazer isso e o que estou perdendo?

2. Por que o desempenho diminui tanto quando eu uso o open_basedir? Ou é salvo para não usar o open_basedir, já que arquivos como o / etc / passwd são legíveis para o mundo?

Answer 1

Se você realmente quer que eles não acessem nada real no sistema, configure o chroot para php-fpm, criando assim um "falso" / etc / passwd e assim por diante. Ou, ainda mais fácil, use o docker!

1) Não tenho certeza de como você configurou os arquivos estáticos a serem carregados a partir desses vhosts, porque eles não devem ser carregados neste caso, talvez apenas se você passar tudo para o php-fpm que abre você para outro tipo de ataque e degrada o desempenho. Normalmente você colocaria permissões como essa (considerando que nginx é o usuário executando o processo nginx):

• / var / vhosta: proprietário vhosta.nginx; perm 750
• / var / vhostb: proprietário vhostb.nginx; perm 750

2) Eu não tenho 100% de certeza, no entanto, se você tem um aplicativo complexo que carrega uma enorme quantidade de arquivos, e seu I / O não oferece um bom desempenho, então pode fazer sentido. Restrições de open_basedir fazem coisas como checar se os arquivos não são um symlink ou dentro de um symlink e assim por diante, fazendo um monte de requisições de I / O aumentando assim o IOPS do seu disco. Mais uma razão para usar o docker ou pelo menos chroot.