Hospede vários VHosts com diferentes usuários no Nginx

A coisa mais normal do mundo quando você tem um servidor é pensar em segurança e mais segurança, você nunca pode ficar paranóico o suficiente 

Uma prática um tanto comum e NADA recomendável, é usar o mesmo usuário para todos os bancos de dados, pior se for usado root, que por incrível que pareça, existem aqueles que (devido à vadiagem ou ignorância) fazer isso, eu já falei sobre por que você NÃO deve agir assim em pós infantilAgora é hora de explicar como e por que é melhor separar o processamento do servidor web em diferentes usuários, desta vez ele estará usando nginx.

Servidor Dedicado_SubImage

O que é isso de usuários e servidor web?

Para explicar de forma breve e simples, o servidor web (apache, nginx, seja o que for) precisa abrir processos no sistema, processos que serão os que pegarão os arquivos do HDD (imagens, etc.) e os farão disponível para o navegador do cliente. O servidor web não pode simplesmente pegar os arquivos e manipulá-los sendo ninguém, ou seja, precisa de um usuário que será quem vai fazer tudo isso no final, e é desse usuário que estou falando, entendeu?

O que é separar em vários usuários?

Suponha que em nosso servidor tenhamos 2 sites, o nosso que é um projeto pessoal e outro (vamos imaginar que é a nossa namorada ou irmão) Mesmo quando usamos bancos de dados separados e diferentes usuários para acessá-los, no final os arquivos de ambos os sites são manipulados pelo mesmo usuário, o processamento do PHP é gerenciado pelo mesmo usuário para todos os sites (geralmente www-data) Essa é uma prática não recomendada, é melhor ter tudo bem separado, como diz um velho ditado, é melhor prevenir do que remediar.

Ok, eu entendo, como faço isso com o Nginx

2000px-Nginx_logo.svg

A primeira coisa a notar é que o Nginx não tem seu próprio módulo que lida com o processamento do PHP como o Apache faz, para o Nginx precisamos usar PHP-CGI ou PHP-FPM, que funciona tão bem (ou melhor) que o Apache. Portanto, para separar o processamento do PHP entre diferentes usuários, precisaremos alterar as linhas nos arquivos de configuração do PHP (CGI ou FPM), não o próprio Nginx.

Suponha que você use PHP-FPM, vamos criar um arquivo de configuração de piscina Para um site específico, ou seja, um pool é a maneira de separar o processamento de PHP do PHP-FPM, mas vamos em partes.

1. Primeiro devemos saber qual usuário do sistema iremos utilizar, irei assumir que ainda não temos nenhum criado e bem, vamos criá-lo:

Todos os comandos a seguir DEVEM ser executados com privilégios administrativos, seja com root direto ou usando sudo

adduser blog

Vamos iniciar o processo normal de criação de um usuário, inserir a senha, etc.

Faço um blog do usuário só para seguir o exemplo, que o primeiro site que hospedaremos será um blog, bom que ... conhecer cada usuário com o qual o site está relacionado

1. Primeiro, vamos para /etc/php5/fpm/pool.d/:

cd /etc/php5/fpm/pool.d/

2. Agora, vamos criar um arquivo chamado blog.conf:

touch blog.conf

3. Agora vamos colocar a configuração do pool que usaremos para o blog VHost:

Edite o arquivo blog.conf com nano ... por exemplo: sudo nanoblog.conf
[blog] usuário = blog
grupo = blog
ouvir = / var / run / php5-fpm-blog.sock listen.owner = blog
escute.grupo = blog
pm = ondemand pm.max_children = 96 chdir = /

Nota: O que eu os marco em vermelho é o que eles devem modificar dependendo do usuário que eles criaram anteriormente. Por exemplo, se eles criarem outro VHost com outro usuário (fórum por exemplo) então, em vez de blog, basta colocar fórum em cada uma das linhas, entendeu?

4. Assim que a configuração da nova piscina (o arquivo blog.conf que acabamos de criar e editar), é a vez de dizer ao Nginx VHost para usar uma meia diferente para esse VHost, para este site. A meia que será usada será a que declaramos anteriormente (/var/run/php5-fpm-blog.sock). Vamos editar o Nginx VHost e na parte de processamento do PHP, indicamos o uso dessas meias. Por exemplo:

localização ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.meia;
incluem fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Como você pode ver, indico que o processamento de PHP desse VHost (essas linhas estão, por exemplo, dentro de / etc / nginx / sites-enabled / vhost-blog) faça isso com as meias encontradas em /var/run/php5-fpm-blog.sock ... que é a que criamos anteriormente ao editar /etc/php5/fpm/pool.d/blog.conf ... é não entendeu?

5. Feito isso, reiniciamos os serviços (php5-fpm e nginx) e voila, veremos que o processamento desse site (vhost) NÃO é feito por www-data ou root ou qualquer outro semelhante, mas pelo usuário que nós previamente definido.

Aqui eu mostro a saída de um ps aux | grepfpm em um dos servidores do meu nó:

ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S Mar30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048 30? S Mar0 00:3 php-fpm: piscina www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: piscina tv3 tv615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: pool tv1818 magazine 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: revista pool magazine 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: pool magazine aluno 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: pool pupil magazine 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: pool gutl magazine 3.5 1.3 356724 27164 10? S 38:0 00:5624 php-fpm: pool gutl cgr 0.0 1.0 365168 22696 28? S Abr0 16:7900 php-fpm: pool cgr pupila 0.3 2.5 457052 52444 25? S Abr20 23:11021 php-fpm: pupila da piscina 0.4 2.5 458316 52864 28? S Abr5 57:11254 php-fpm: pool pupila cgr 0.0 1.0 363152 21708 28? S Abr0 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28? S Abr0 08:XNUMX php-fpm: pool cgr

Como você pode ver ... separar o processamento do PHP pelos usuários usando Nginx + PHP-FPM é muito fácil, aí você vê que são vários pools, pois são vários usuários.

Conclusão

Quando se trata de servidores, você nunca pode ficar paranóico o suficiente... segurança não é algo para se brincar, quanto mais tentamos sempre melhorar a segurança de nossos servidores e seus serviços, menos provável que tenhamos medo de um ( bem-sucedida) tentativa de hack ou algo semelhante 