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.

DedicatedServer_SubImage

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

2000px-Nginx_logo.svg

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:

Alle følgende kommandoer MÅ utføres med administrative rettigheter, enten med direkte rot eller ved hjelp av sudo

adduser blog

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

Jeg blogger brukeren bare for å følge eksemplet, at det første nettstedet vi vil være en blogg, vel ... å kjenne hver bruker som nettstedet er relatert til

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:

Rediger blog.conf-filen med nano ... for eksempel: sudo nanoblog.conf
[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 😉


9 kommentarer, legg igjen dine

Legg igjen kommentaren

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*

*

  1. Ansvarlig for dataene: Miguel Ángel Gatón
  2. Formålet med dataene: Kontroller SPAM, kommentaradministrasjon.
  3. Legitimering: Ditt samtykke
  4. Kommunikasjon av dataene: Dataene vil ikke bli kommunisert til tredjeparter bortsett fra ved juridisk forpliktelse.
  5. Datalagring: Database vert for Occentus Networks (EU)
  6. Rettigheter: Når som helst kan du begrense, gjenopprette og slette informasjonen din.

  1.   dhunter sa

    Gaara, i nåværende tid bør disse tingene automatiseres så mye som mulig, jeg anbefaler deg å prøve Ansible. Uten agent trenger du bare python på den eksterne verten, veldig enkelt å konfigurere, yaml-filer, Jinja-maler.

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

    1.    KZKG ^ Gaara sa

      La oss se, det er ikke alltid bare for WordPress-nettsteder, og ... haha ​​kanskje Ansible klikker volao, men jeg foretrekker å vite nøyaktig hvordan alt fungerer på serveren, selv om jeg må bruke 1 minutt på å lage nye sokker og en nye VHost 😀

      1.    dhunter sa

        Med Ansible automatiserer du alt, du gjør praktisk talt hva du vil, fordelen med denne metoden er at du innkapsler øvelsen og deretter utfører etter ønske, forestill deg at du har et tungt lastet nettsted og du vil gjøre belastningsbalansering mellom applikasjonsservere, disse må være konfigurert akkurat det samme kan du ikke hoppe over et trinn eller gjøre noe annerledes i et av dem, kan du forestille deg å gjøre prosedyren trinn for trinn 4 ganger? Med Ansible er det så enkelt som å legge vertsnavnet til lagerfilen og Voilá !!

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

      2.    dhunter sa

        Beklager Ansible-kulten, men det er en av disse teknologiene du oppdager, og du vil at alle skal bruke den nå fordi den er så kul og praktisk, det er som når du oppdager NGINX og du vil at alle vennene dine skal forlate Apache umiddelbart.

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

  2.   mstaaravin sa

    Jeg er sikker på at innlegget mitt utfyller dette ...
    http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/

  3.   råtner87 sa

    Jeg er (eller studerer for å være) utvikler, og med NGIX hadde jeg mange problemer når jeg konfigurerte nginx + php-fpm. Jeg vet at archlinux distro ikke er det beste for å gjøre det til en server, men hver gang jeg oppdaterte en versjon av ngix eller php, krasjet den alltid alt, så jeg forlot forsøket lol ... For i dag bodde jeg hos den klassiske Apache + PHP men jeg får se om jeg går rundt NGIX igjen ... kanskje på en virtuell maskin

    1.    dhunter sa

      Mentaliteten endres litt, nginx serverer det statiske innholdet og fungerer som en omvendt proxy for php-fpm som er som kjører den virkelige PHP, du må starte i deler og oppnå distribusjonen trinn for trinn, se etter en guide for å distribuere rammeverket du jobber med, har hver sin detalj ved navn på publikum, statisk, ressurser, etc ...

  4.   anonym sa

    Gjør fellesskapet den store fordel med å forlate ordet "hostear", som ikke eksisterer. Av Gud, er det så vanskelig å si "vert"?

  5.   Ønsker å sa

    Hilsen, etter eksempelet ditt, vil jeg vite om det bare kan lages et basseng for wordpress backen, det vil si for wp-admin som lager en ny kontakt for innkommende tilkoblinger til backend

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