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 


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.

      caçador dito

    Gaara, nos tempos atuais essas coisas deveriam ser automatizadas o máximo possível, eu recomendo que você experimente o Ansible. Sem agente, você só precisa de python no host remoto, muito simples de configurar, arquivos yaml, modelos Jinja.

    https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx

         KZKG ^ Gaara dito

      Vamos ver, isso nem sempre é só para sites WordPress, e ... haha ​​talvez Ansible clica em volao, mas prefiro saber exatamente como tudo funciona no servidor, mesmo que tenha que gastar 1 minuto criando uma nova meia e uma novo VHost 😀

           caçador dito

        Com o Ansible você automatiza tudo, faz praticamente o que quiser, a vantagem desse método é que você encapsula a prática e depois executa à vontade, imagine que você tem um site muito carregado e deseja fazer balanceamento de carga entre os servidores de aplicativos, estes tem que ser configurado exatamente igual você não pode pular uma etapa ou fazer algo diferente em uma delas, já imaginou fazer o procedimento passo a passo 4 vezes? Com o Ansible é tão simples quanto adicionar o nome do host ao arquivo de inventário e Voilá !!

        http://www.ansible.com/how-ansible-works

           caçador dito

        Desculpe pelo culto Ansible, mas é uma dessas tecnologias que você descobre e quer que todos a usem agora porque é tão legal e prático, é como quando você descobre o NGINX e quer que todos os seus amigos deixem o Apache imediatamente.

        https://speakerdeck.com/slok/ansible-all-the-things

      mstaaravin dito

    Tenho certeza que minha postagem complementa isso ...
    http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/

      apodrece87 dito

    Sou (ou pretendo ser) desenvolvedor e com o NGIX tive muitos problemas ao configurar o nginx + php-fpm. Sei que a distro archlinux não é a melhor para fazer como servidor, mas toda vez que atualizava uma versão do ngix ou php tudo sempre travava então desisti da tentativa rs ... Por hoje fico com o clássico Apache + PHP, mas vou ver se ando em torno do NGIX novamente ... talvez em uma máquina virtual

         caçador dito

      A mentalidade muda um pouco, o nginx serve o conteúdo estático e serve como proxy reverso para o php-fpm que é quem roda o PHP real, você tem que começar em partes e conseguir o deploy passo a passo, procure um guia para implantar o framework com o qual você trabalha, cada um tem seu detalhamento pelos nomes do público, estático, recursos, etc ...

      anônimo dito

    Faça à comunidade o grande favor de abandonar a palavra "hostear", que não existe. Por Deus, é tão difícil dizer "hospedeiro"?

      Wil dito

    Saudações, seguindo seu exemplo gostaria de saber se um pool poderia ser feito apenas para o backen do wordpress, ou seja, para o wp-admin criando um novo soquete para conexões de entrada para o backend

    localização / wp-admin {
    root /var/www/yoursite.com/wp-admin;
    index index.php index.html index.htm;
    localização ~ ^ / wp-admin /(.+. php) $ {
    try_files $ uri = 404;
    root /var/www/yoursite.com/wp-admin;
    incluir / etc / nginx / fastcgi_params;

    fastcgi_pass server unix:/run/php5-fpm2.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 256 4k;
    fastcgi_busy_buffers_size 256k;
    fastcgi_temp_file_write_size 256k;
    fastcgi_read_timeout 1240;
    }
    location ~* ^/wp-admin/(.+\.(jpg|jpeg|gif|css|png|js|ico|html|xml|txt))$ {
    root /var/www/tusitio.com/wp-admin/;
    }
    }