Hostear diversos VHosts amb usuaris diferents en Nginx

El més normal de món quan es té un servidor, és pensar en seguretat i més seguretat, mai es pot ser prou paranoic 😉

Una pràctica alguna cosa comuna i RES recomanable, és fer servir el mateix usuari per a totes les bases de dades, pitjor si s'usa root, que per increïble que sembli, hi ha qui (per vagància o desconeixement) Fan això, ja vaig parlar sobre el per què NO s'ha d'actuar així en un altre post, Ara toca explicar com i per què és millor separar el processament de servidor web en diferents usuaris, en aquesta ocasió serà usant Nginx.

DedicatedServer_SubImage

Què és això d'usuaris i servidor web?

Per explicar-ho de forma breu i simple, el servidor web (apache, Nginx, el que sigui) necessita obrir processos en el sistema, processos que seran els que prenguin els arxius de l'HDD (imatges, etc) i els posi disponibles per al navegador d'el client . El servidor web no pot simplement prendre els arxius i manipular-los sent ningú, és a dir, necessita un usuari que serà qui a la fin farà tot això, i aquest usuari és de què els parlo, ¿s'entén?

Què és això de separar en diversos usuaris?

Suposem que en el nostre servidor tenim 2 llocs webs, el nostre que és un projecte personal, i un altre més (imaginem que és el de la nostra núvia o germà). Tot i que fem servir bases de dades separades i usuaris diferents per accedir-hi, a la fi dels arxius de tots dos llocs webs són manipulats pel mateix usuari, el processament PHP és gestionat pel mateix usuari per a tots els llocs (generalment és www-data). Això és una pràctica no recomanable, és millor tenir-ho tot ben separat, com diu un vell refrany, és millor precaver de lamentar.

Ok entenc, com ho faig amb Nginx

2000px-Nginx_logo.svg

El primer és tenir compte que Nginx no compta amb un mòdul propi que s'encarregui de l'processament PHP com sí que ho fa Apache, per Nginx necessitem utilitzar PHP-CGI o PHP-FPM, que funciona igual de bé (o millor) que Apache. Pel que, per separar el processament PHP en diferents usuaris, necessitarem canviar línies en arxius de configuració de PHP (CGI o FPM), no d'Nginx pròpiament.

Suposem que fas servir PHP-FPM, Crearem un arxiu de configuració de piscina per a un lloc específic, és a dir, un pool és la forma de separar el processament PHP de PHP-FPM, però anem per parts.

1. Primer hem de saber quin usuari de sistema farem servir, assumiré que encara no tenim cap creat i doncs bé, anem a crear-lo:

Totes les comandes següents TENEN de ser executats amb privilegis d'administració, bé amb root directe o usant suo

adduser blog

Ens començarà el procés normal de creació d'un usuari, posin el password, etc.

Li poso bloc a l'usuari només per seguir l'exemple, que el primer lloc que hostearemos serà un bloc, doncs això ... per saber cada usuari amb quin lloc guarda relació

1. Primer entrem a /etc/php5/fpm/pool.d/:

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

2. Ara, crearem un fitxer anomenat blog.conf:

touch blog.conf

3. Ara posarem la configuració de l'pool que farem servir per al VHost bloc:

Editin l'arxiu blog.conf amb nano ... per exemple: suo nano blog.conf
[bloc] User = bloc
group = bloc
listen = / var / run / php5-fpm-bloc.sock listen.owner = bloc
listen.group = bloc
am = ondemand pm.max_children = 96 chdir = /

Nota: El que els marc en vermell és el que han de modificar en dependència de l'usuari que anteriorment van crear. Per exemple, si creen un altre VHost amb un altre usuari (fòrum, per exemple) Llavors posen en comptes de bloc simplement fòrum en cadascuna de les línies, ¿s'entén no?

4. Un cop posat ja la configuració de la nova pool (l'arxiu blog.conf que recentment vam crear i editar), Toca el torn de indicar-li a l'VHost de Nginx que faci servir per a aquest VHost, per és lloc, 5 sock diferent. El sock que usarà serem el que prèviament declarem (/var/run/phpXNUMX-fpm-blog.sock). Editem el VHost de Nginx i en la part de l'processament PHP, vam indicar que usi aquest socks. Per exemple:

location ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-bloc.sock;
include fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Com veuen, li indico que el processament PHP d'aquest VHost (aquestes línies estan per exemple dins de / etc / nginx / sites-enabled / vhost-bloc) Ho faci amb el socks que es troba en /var/run/php5-fpm-blog.sock ... que és el que vam crear prèviament a l'editar /etc/php5/fpm/pool.d/blog.conf ... ¿s'entén no ?

5. Un cop fet això, reiniciem ambdós serveis (php5-fpm i nginx) i llest, veurem que el processament d'aquest lloc (vhost) ja NO ho fa www-data ni root ni ningú similar, sinó que ho fa l'usuari que prèviament definim .

Aquí els mostro l'output d'un ps aux | grep fpm en un dels servidors de la meva node:

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? S Mar30 0:00 php-fpm: pool www tv3 611 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool tv3 tv3 615 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: pool tv3 revista 1818 1.7 1.7 437576 36396? S 09:55 0:46 php-fpm: pool revista revista 2264 1.9 1.7 437332 35884? S 10:15 0:26 php-fpm: pool revista pupil·la 2338 4.3 1.0 428992 22196? S 10:18 0:53 php-fpm: pool pupil·la revista 2413 1.8 1.7 437764 36152? S 10:22 0:18 php-fpm: pool revista gutl 2754 3.5 1.3 356724 27164? S 10:38 0:00 php-fpm: pool gutl CGR 5624 0.0 1.0 365168 22696? S Apr28 0:16 php-fpm: pool CGR pupil·la 7900 0.3 2.5 457052 52444? S Apr25 20:23 php-fpm: pool pupil pupil·la 11021 0.4 2.5 458316 52864? S Apr28 5:57 php-fpm: pool pupil·la CGR 11254 0.0 1.0 363152 21708? S Apr28 0:12 php-fpm: pool CGR CGR 13184 0.0 1.0 362872 21360? S Apr28 0:08 php-fpm: pool CGR

Com veuen ... separar el processament PHP per usuaris usant Nginx + PHP-FPM és molt fàcil, aquí veuen que són diversos pools, ja que són diversos usuaris.

Conclusions

Quan es tracta de servidors, mai s'és prou paranoic ... la seguretat no és una cosa per jugar, com més intentem sempre millorar la seguretat dels nostres servidors i els seus serveis, menys probabilitats hi haurà que passem un ensurt per intent (satisfactori) de hack o qualsevol cosa similar 😉


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   caçador va dir

    Gaara, en temps actuals aquestes coses s'haurien automatitzar tot el possible, et recomano provis ansible. Sense agent, només necessita python al host remot, molt simple de configurar, fitxers YAML, templates Jinja.

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

    1.    KZKG ^ Gaara va dir

      A veure, això no sempre és només per a llocs amb WordPress, i ... jaja potser ansible punxa Volao, però prefereixo saber exactament com funciona tot al server, tot i que hagi de dedicar 1 minut a crear jo mateix un nou socks i un nou VHost 😀

      1.    caçador va dir

        Amb ansible automatitzes de tot, fas pràcticament el que vulguis, l'avantatge d'aquest mètode és que encapsulas la pràctica i després executes a voluntat, imagina que tens un lloc molt carregat i vols fer balanceig de càrrega entre servidors d'aplicació, aquests han d'estar configurats exactament igual no pots saltar un pas o fer res diferent en un d'ells, t'imagines fer el procediment pas a pas 4 vegades? Amb ansible és tan simple com afegir el nom de l'amfitrió a el fitxer inventari i voilà !!

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

      2.    caçador va dir

        Perdó el culte a ansible però és que és una d'aquestes tecnologies que descobreixes i vols que tots la facin servir ja perquè és tan genial i pràctica, és com quan descobreixes Nginx i vols que tots els teus amics deixin Apache immediatament.

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

  2.   Mstaaravin va dir

    Estic segur que el meu post complementa a aquest ...
    http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/

  3.   Rots87 va dir

    Jo sóc (o estudi per a ser-ho) desenvolupador i amb NGIX vaig tenir molts problemes a l'hora de configurar nginx + php-fpm. Es que la distro de ArchLinux no és la millor per a fer-la de servidor, però cada vegada que actualitzava una versió de ngix o del PHP sempre se m'ha crasheaba tot així que abandoni l'intent jejeje ... Per avui em quedi amb el clàssic Apache + PHP però vere si em dono una volta per NGIX altra vegada ... potser en una màquina virtual

    1.    caçador va dir

      La mentalitat canvia una mica, nginx serveix el contingut estàtic i serveix de proxy invers per al php-fpm que és qui corre el PHP de veritat, has de començar per parts i anar assolint el deploy pas per pas, busca una guia per desplegar el framework amb el qual treballes, cadascú té el seu detall pels noms de la carpeta public, static, resources, etc ...

  4.   anònim va dir

    Facin-a la comunitat el grandíssim favor d'abandonar el palabro «hostear», que no existeix. Per Déu, ¿tan difícil és dir «allotjar»?

  5.   Wil va dir

    Salutacions, seguint el teu exemple voldria saber si es podria fer un pool sol per al backen de wordpress, és a dir per al wp-admin fent un nou socket sol per les connexions entrants a l'backend

    location / wp-admin {
    root /var/www/tusitio.com/wp-admin;
    index index.php index.html index.htm;
    location ~ ^ / wp-admin /(.+. php) $ {
    try_files $ uri = 404;
    root /var/www/tusitio.com/wp-admin;
    include / 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/;
    }
    }