Găzduiește mai mulți VHosts cu utilizatori diferiți în Nginx

Cel mai normal lucru din lume când ai un server este să te gândești la securitate și mai multă securitate, nu poți fi niciodată suficient de paranoic 😉

O practică oarecum obișnuită și NIMIC recomandat este aceea de a folosi același utilizator pentru toate bazele de date, mai rău dacă se folosește root, ceea ce, pe cât de incredibil pare, există cei care (datorită vagabondajului sau ignoranței) faceți acest lucru, am vorbit deja despre motivul pentru care NU ar trebui să acționați astfel un alt postAcum este timpul să explicăm cum și de ce este mai bine să separați procesarea serverului web la diferiți utilizatori, de data aceasta va folosi nginx.

DedicatedServer_SubImage

Ce este acela al utilizatorilor și al serverului web?

Pentru a-l explica într-un mod scurt și simplu, serverul web (apache, nginx, orice) trebuie să deschidă procese în sistem, procese care vor fi cele care vor prelua fișierele de pe HDD (imagini etc.) și le vor face disponibil pentru browserul clientului. Serverul web nu poate pur și simplu să preia fișierele și să le manipuleze fiind nimeni, adică are nevoie de un utilizator care va fi cel care va face toate acestea până la urmă, iar acel utilizator este cel despre care vorbesc, se înțelege asta?

Ce înseamnă separarea în mai mulți utilizatori?

Să presupunem că pe serverul nostru avem 2 site-uri web, ale noastre, care este un proiect personal, și altul (să ne imaginăm că e prietena sau fratele nostru). Chiar și atunci când folosim baze de date separate și utilizatori diferiți pentru a le accesa, în cele din urmă fișierele ambelor site-uri web sunt manipulate de același utilizator, procesarea PHP este gestionată de același utilizator pentru toate site-urile (este de obicei www-data). Aceasta este o practică nerecomandată, este mai bine să aveți totul bine separat, așa cum se spune într-o vorbă veche, este mai bine să fiți în siguranță decât să vă pare rău.

Ok, înțeleg, cum o fac cu Nginx

2000px-Nginx_logo.svg

Primul lucru de remarcat este că Nginx nu are propriul modul care gestionează procesarea PHP așa cum are Apache, pentru Nginx trebuie să folosim PHP-CGI sau PHP-FPM, care funcționează la fel de bine (sau mai bine) decât Apache. Deci, pentru a separa procesarea PHP între diferiți utilizatori, va trebui să schimbăm liniile din fișierele de configurare PHP (CGI sau FPM), nu Nginx în sine.

Să presupunem că folosești PHP-FPM, vom crea un fișier de configurare pentru piscină Pentru un anumit site, adică un pool este modalitatea de a separa procesarea PHP de PHP-FPM, dar mergem în părți.

1. Mai întâi trebuie să știm ce utilizator al sistemului vom folosi, voi presupune că încă nu avem niciunul creat și bine, să-l creăm:

Toate următoarele comenzi TREBUIE să fie executate cu privilegii administrative, fie cu root direct, fie folosind sudo

adduser blog

Vom începe procesul normal de creare a unui utilizator, vom introduce parola etc.

Bloguiesc utilizatorul doar pentru a urma exemplul, că primul site pe care îl vom găzdui va fi un blog, ei bine ... pentru a cunoaște fiecare utilizator cu care site este legat

1. Mai întâi să mergem la /etc/php5/fpm/pool.d/:

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

2. Acum, vom crea un fișier numit blog.conf:

touch blog.conf

3. Acum vom pune configurația pool-ului pe care îl vom folosi pentru blogul VHost:

Editați fișierul blog.conf cu nano ... de exemplu: sudo nanoblog.conf
[blogul] utilizator = blogul
grup = blogul
asculta = / var / run / php5-fpm-blogul.sock asculta.proprietar = blogul
asculta.grup = blogul
pm = ondemand pm.max_children = 96 chdir = /

Nota: Ceea ce le marchez în roșu este ceea ce trebuie să modifice în funcție de utilizatorul pe care l-au creat anterior. De exemplu, dacă creează un alt VHost cu un alt utilizator (forum de exemplu) atunci în loc de blog pur și simplu puneți forum în fiecare dintre rânduri, este înțeles?

4. Odată ce a fost configurată noua piscină (fișierul blog.conf pe care tocmai l-am creat și editat), este rândul să îi spui lui Nginx VHost să folosească un ciorap diferit pentru acel VHost, pentru acest site. Ciorapul care va fi folosit va fi cel pe care l-am declarat anterior (/var/run/php5-fpm-blog.sock). Să edităm Nginx VHost și în partea de procesare PHP, indicăm să folosim șosetele respective. De exemplu:

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

După cum puteți vedea, indic faptul că procesarea PHP a acelui VHost (aceste linii sunt, de exemplu, în / etc / nginx / sites-enabled / vhost-blog) faceți-o cu șosetele găsite în /var/run/php5-fpm-blog.sock ... care este cea pe care am creat-o anterior când editați /etc/php5/fpm/pool.d/blog.conf ... este nu a înțeles?

5. Odată ce acest lucru este făcut, repornim ambele servicii (php5-fpm și nginx) și voila, vom vedea că prelucrarea acelui site (vhost) NU este realizată de www-data sau root sau de oricine similar, ci de către utilizatorul pe care îl avem definite anterior.

Aici vă arăt rezultatul unui ps aux | grep fpm pe unul dintre serverele nodului meu:

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: carte ebook www 608 0.0 0.2 350084 5008? S Mar30 0:00 php-fpm: piscină www www 609 0.0 0.2 350600 5048 30? S Mar0 00:3 php-fpm: biliard www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: piscină tv3 tv615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: piscina tv1818 revista 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: revista revista pool 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: elev revistă piscina 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: revista elevilor din piscină 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: revista gutl pool 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: elev elev elev 0.4 2.5 458316 52864 28? S Apr5 57:11254 php-fpm: elev de piscină 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

După cum puteți vedea ... separarea procesării PHP de către utilizatori utilizând Nginx + PHP-FPM este foarte ușoară, acolo vedeți că există mai multe pool-uri, deoarece există mai mulți utilizatori.

Concluzii

Când vine vorba de servere, nu sunteți niciodată suficient de paranoic ... securitatea nu este ceva cu care să ne jucăm, cu cât încercăm întotdeauna să îmbunătățim securitatea serverelor noastre și a serviciilor lor, cu atât mai puțin probabil vom fi speriați de un (de succes) încercare de piratare sau ceva similar 😉


9 comentarii, lasă-le pe ale tale

Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.

  1.   dhunter el a spus

    Gaara, în vremurile actuale aceste lucruri ar trebui automatizate pe cât posibil, îți recomand să încerci Ansible. Fără agent, aveți nevoie doar de python pe gazda de la distanță, foarte simplu de configurat, fișiere yaml, șabloane Jinja.

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

    1.    KZKG ^ Gaara el a spus

      Să vedem, asta nu este întotdeauna doar pentru site-urile WordPress și ... haha ​​poate Ansible face clic pe volao, dar prefer să știu exact cum funcționează totul pe server, chiar dacă trebuie să petrec 1 minut creând un șosete și un nou VHost 😀

      1.    dhunter el a spus

        Cu Ansible automatizați totul, faceți practic orice doriți, avantajul acestei metode este că încapsulați practica și apoi executați după bunul plac, imaginați-vă că aveți un site încărcat puternic și doriți să faceți echilibrarea încărcării între serverele de aplicații, acestea trebuie să fie configurat exact la fel, nu puteți sări peste un pas sau să faceți ceva diferit într-unul dintre ei, vă puteți imagina că faceți procedura pas cu pas de 4 ori? Cu Ansible este la fel de simplu ca adăugarea numelui de gazdă în fișierul de inventar și Voilá !!

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

      2.    dhunter el a spus

        Ne pare rău pentru cultul Ansible, dar este una dintre aceste tehnologii pe care le descoperiți și doriți ca toată lumea să o folosească acum pentru că este atât de cool și practic, este ca atunci când descoperiți NGINX și doriți ca toți prietenii dvs. să părăsească Apache imediat.

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

  2.   mstaaravin el a spus

    Sunt sigur că postarea mea completează acest lucru ...
    http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/

  3.   Putreze87 el a spus

    Sunt (sau studiez să fiu) dezvoltator și cu NGIX am avut multe probleme la configurarea nginx + php-fpm. Știu că distro-ul archlinux nu este cel mai bun pentru al face ca server, dar de fiecare dată când am actualizat o versiune de ngix sau php totul s-a prăbușit mereu, așa că am renunțat la încercarea lol ... Pentru astăzi rămân cu clasicul Apache + PHP, dar o să văd dacă mă întorc din nou cu NGIX ... poate într-o mașină virtuală

    1.    dhunter el a spus

      Mentalitatea se schimbă puțin, nginx servește conținutul static și servește ca un proxy invers pentru php-fpm care este cel care rulează PHP-ul real, trebuie să începeți în părți și să realizați implementarea pas cu pas, căutați un ghid de implementare cadrul cu care lucrați, fiecare are detaliile sale prin numele publicului, static, resurse, etc ...

  4.   anonim el a spus

    Faceți comunității marea favoare a abandonării cuvântului „hostear”, care nu există. Doamne, este atât de greu să spui „gazdă”?

  5.   Wil el a spus

    Salutări, urmând exemplul dvs., aș dori să știu dacă un pool ar putea fi făcut doar pentru wordpress backen, adică pentru wp-admin care face un nou socket pentru conexiunile de intrare la backend

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