Vert for flere VHosts med forskjellige brukere i Nginx

Det mest normale i verden når du har en server, er å tenke på sikkerhet og mer sikkerhet, du kan aldri være paranoid nok 😉

En noe vanlig praksis og INGENTING anbefales, er å bruke den samme brukeren for alle databaser, verre hvis root brukes, noe som så utrolig som det kan virke, det er de som (på grunn av uklarhet eller uvitenhet) gjør dette, jeg har allerede snakket om hvorfor du IKKE skal handle slik i barnas post, nå er det på tide å forklare hvordan og hvorfor det er bedre å skille webserverbehandlingen i forskjellige brukere, denne gangen vil den bruke Nginx.

Hva er det for brukere og webserver?

For å forklare det på en kort og enkel måte, må webserveren (apache, nginx, hva som helst) åpne prosesser i systemet, prosesser som vil være de som tar filene fra harddisken (bilder osv.) Og gjør dem tilgjengelige for klientens nettleser . Webserveren kan ikke bare ta filene og manipulere dem som ingen, det vil si at den trenger en bruker som vil være den som vil gjøre alt dette til slutt, og at brukeren er den jeg snakker om, forstår du?

Hva er det med å skille mellom flere brukere?

La oss anta at vi på serveren vår har to nettsteder, vårt som er et personlig prosjekt, og et annet (la oss forestille oss at det er kjæresten eller broren vår). Selv når vi bruker separate databaser og forskjellige brukere for å få tilgang til dem, til slutt manipuleres filene på begge nettsteder av samme bruker, og PHP-behandlingen administreres av samme bruker for alle nettsteder (vanligvis www-data). Dette er en ikke anbefalt praksis, det er bedre å ha alt godt skilt, som et gammelt ordtak sier, er det bedre å være trygg enn beklager.

Ok jeg forstår, hvordan gjør jeg det med Nginx

Den første tingen å merke seg er at Nginx ikke har en egen modul som håndterer PHP-behandling slik Apache gjør, for Nginx trenger vi å bruke PHP-CGI eller PHP-FPM, som fungerer like bra (eller bedre) enn Apache. For å skille PHP-behandling på tvers av forskjellige brukere, må vi endre linjer i PHP-konfigurasjonsfiler (CGI eller FPM), ikke Nginx selv.

Anta at du bruker PHP-FPM, vil vi opprette en konfigurasjonsfil av basseng For et bestemt nettsted, det vil si et basseng er måten å skille PHP-behandling fra PHP-FPM på, men vi går i deler.

1. Først må vi vite hvilken bruker av systemet vi skal bruke, jeg vil anta at vi fortsatt ikke har noen opprettet og vel, la oss lage det:

adduser blog

Vi starter den normale prosessen med å opprette en bruker, skriver inn passordet osv.

1. La oss først gå til /etc/php5/fpm/pool.d/:

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

2. Nå skal vi lage en fil som heter blog.conf:

touch blog.conf

3. Nå vil vi sette konfigurasjonen av bassenget som vi vil bruke til VHost-bloggen:

[blog] bruker = blog
gruppe = blog
hør = / var / run / php5-fpm-blog.sock listen.owner = blog
lytte.gruppe = blog
pm = etterspørsel pm.max_children = 96 chdir = /

Merk: Det jeg merker dem med rødt, er hva de må endre, avhengig av brukeren de tidligere opprettet. For eksempel hvis de oppretter en annen VHost med en annen bruker (forum for eksempel) så er det forstått i stedet for å blogge ganske enkelt forum i hver av linjene?

4. Når konfigurasjonen av det nye bassenget (blog.conf-filen som vi nettopp opprettet og redigerte), er det turen å fortelle Nginx VHost å bruke en annen sokk for den VHost, for dette nettstedet. Sokken som skal brukes, er den vi tidligere har erklært (/var/run/php5-fpm-blog.sock). La oss redigere Nginx VHost, og i PHP-prosesseringsdelen indikerer vi at du bruker de sokkene. For eksempel:

plassering ~ \ .php $ {if (! -f $ request_filename) {retur 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.sokk;
inkluderer fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Som du kan se, indikerer jeg at PHP-behandlingen av den VHost (disse linjene er for eksempel inne i / etc / nginx / sites-enabled / vhost-blog) gjør det med sokkene som finnes i /var/run/php5-fpm-blog.sock ... som er den vi opprettet tidligere når du redigerer /etc/php5/fpm/pool.d/blog.conf ... er forstod det ikke?

5. Når dette er gjort, starter vi begge tjenestene på nytt (php5-fpm og nginx) og voila, vi vil se at behandlingen av nettstedet (vhost) IKKE gjøres av www-data eller root eller noen lignende, men av brukeren som vi tidligere definerte .

Her viser jeg deg resultatet av en ps aux | grep fpm på en av node-serverne mine:

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: pool www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: pool 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: pool magazine magazine 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: bassengmagasin elev 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 Apr0 16:7900 php-fpm: pool cgr pupil 0.3 2.5 457052 52444 25? S Apr20 23:11021 php-fpm: pool pupill pupille 0.4 2.5 458316 52864 28? S Apr5 57:11254 php-fpm: pool pupil cgr 0.0 1.0 363152 21708 28? S Apr0 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28? S Apr0 08:XNUMX php-fpm: pool cgr

Som du kan se ... å skille PHP-behandlingen av brukere som bruker Nginx + PHP-FPM, er veldig enkelt, der ser du at det er flere bassenger, ettersom det er flere brukere.

Konklusjoner

Når det gjelder servere, er du aldri paranoid nok ... sikkerhet er ikke noe å leke med, jo mer vi alltid prøver å forbedre sikkerheten til våre servere og deres tjenester, desto mindre sannsynlig blir vi redd av et (vellykket) hackforsøk eller noe lignende 😉