Hostirajte više VHostova s ​​različitim korisnicima u Nginxu

Najnormalnija stvar na svijetu kada imate server je razmišljati o sigurnosti i većoj sigurnosti, nikada ne možete biti dovoljno paranoični 😉

Pomalo česta praksa i NIŠTA se ne preporučuje je korištenje istog korisnika za sve baze podataka, još gore ako se koristi root, što koliko god nevjerovatno izgledalo, ima onih koji (zbog skitnice ili neznanja) uradi ovo, već sam govorio o tome zašto se NE bi trebao ponašati ovako drugi postSada je vrijeme da objasnimo kako i zašto je bolje razdvojiti obradu web servera od različitih korisnika, ovaj put će se on koristiti Nginx.

DedicatedServer_SubImage

Šta je to od korisnika i web servera?

Da bi to objasnio na kratak i jednostavan način, web poslužitelj (apache, nginx, bilo što drugo) mora otvoriti procese u sistemu, procese koji će biti ti koji preuzimaju datoteke s tvrdog diska (slike itd.) I prave ih dostupno klijentovom pretraživaču. Web server ne može jednostavno uzimati datoteke i manipulirati njima dok je nitko, odnosno potreban mu je korisnik koji će na kraju sve to učiniti, a taj korisnik je taj o kome govorim, je li to razumljivo ?

Šta je to razdvajanje od nekoliko korisnika?

Pretpostavimo da na našem serveru imamo 2 web stranice, našu koja je osobni projekt, i još jednu (zamislimo da je to naša djevojka ili brat). Čak i kada koristimo zasebne baze podataka i različite korisnike da bismo im pristupili, na kraju datotekama obje web stranice manipulira isti korisnik, PHP obradom upravlja isti korisnik za sve web stranice (to su obično www-podaci). To je praksa koja se ne preporučuje, bolje je da sve bude dobro odvojeno, kako kaže stara izreka, bolje je biti siguran nego žaliti.

Ok, razumijem, kako to mogu raditi s Nginxom

2000px-Nginx_logo.svg

Prva stvar koju treba primetiti je da Nginx nema svoj modul koji se bavi PHP-ovom obradom kao Apache, za Nginx moramo koristiti PHP-CGI ili PHP-FPM, koji radi jednako dobro (ili bolje) od Apache-a. Dakle, da bismo razdvojili PHP obradu između različitih korisnika, morat ćemo promijeniti redove u PHP konfiguracijskim datotekama (CGI ili FPM), a ne sam Nginx.

Pretpostavimo da koristite PHP-FPM, stvorit ćemo konfiguracijsku datoteku od bazen Za određenu web lokaciju, tj. Bazen je način da se PHP obrada odvoji od PHP-FPM-a, ali idemo dijelom.

1. Prvo moramo znati kojeg korisnika sistema ćemo koristiti, pretpostavit ću da još uvijek nemamo kreiran i dobro, kreirajmo ga:

Sve naredbe naredbe MORAJU se izvršavati s administrativnim privilegijama, bilo s direktnim root-om ili koristeći sudo

adduser blog

Pokrenut ćemo normalan postupak stvaranja korisnika, unijeti lozinku itd.

Blogam korisnika samo da bih slijedio primjer, da će prva web lokacija koju ćemo ugostiti biti blog, pa da ... da znam svakog korisnika s kojim je web lokacija povezana

1. Prvo idemo na /etc/php5/fpm/pool.d/:

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

2. Sada ćemo stvoriti datoteku nazvanu blog.conf:

touch blog.conf

3. Sada ćemo staviti konfiguraciju spremišta koju ćemo koristiti za VHost blog:

Uredite datoteku blog.conf pomoću nano ... na primjer: sudo nanoblog.conf
[blog] korisnik = blog
grupa = blog
listen = / var / run / php5-fpm-blog.sock listen.owner = blog
listen.group = blog
pm = ondemand pm.max_children = 96 chdir = /

Napomena: Crvenim ih označavam ono što moraju izmijeniti ovisno o korisniku kojeg su prethodno stvorili. Na primjer, ako kreiraju drugi VHost s drugim korisnikom (foruma na primjer) onda umjesto bloga jednostavno stavite forum u svaki red, zar ne razumijete?

4. Jednom kada se konfigurira novi bazen (datoteku blog.conf koju smo upravo kreirali i uredili), red je da kažete Nginx VHost-u da koristi drugu čarapu za taj VHost, za ovu web lokaciju. Upotrijebit ćemo čarapu koju smo prethodno proglasili (/var/run/php5-fpm-blog.sock). Uredimo Nginx VHost i u PHP dijelu za obradu naznačujemo da koristimo te čarape. Na primjer:

lokacija ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.čarapa;
uključuju fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Kao što vidite, naznačujem da je PHP obrada tog VHost-a (te linije su na primjer unutar / etc / nginx / sites-enabled / vhost-blog) uradite to s čarapama koje se nalaze u /var/run/php5-fpm-blog.sock ... a koje smo prethodno kreirali prilikom uređivanja /etc/php5/fpm/pool.d/blog.conf ... je nije razumio?

5. Nakon što to učinimo, ponovo pokrećemo obje usluge (php5-fpm i nginx) i voila, vidjet ćemo da obradu te stranice (vhost) NE vrši www-data ili root ili bilo tko sličan, već korisnik kojeg mi prethodno definirano.

Ovdje ću vam pokazati izlaz a ps aux | grep fpm na jednom od servera mog čvora:

ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S30. Mart 0:00 php-fpm: e-knjiga bazena 589 0.0 0.0 349360 1204? S30. Mart 0:00 php-fpm: e-knjiga bazena www 608 0.0 0.2 350084 5008? S Ožujak 30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048 30? S Ožujak 0 00:3 php-fpm: pool www tv611 0.0 0.0 349360 1204 30? S0. Mart 00:3 php-fpm: bazen tv3 tv615 0.0 0.0 349360 1204 30? S Ožujak 0:00 3:1818 php-fpm: pool tv1.7 magazine 1.7 437576 36396 09 55? S 0:46 2264:1.9 php-fpm: magazine magazine pool 1.7 437332 35884 10 15? S 0:26 2338:4.3 php-fpm: učenik časopisa za bazene 1.0 428992 22196 10 18? S 0:53 2413:1.8 php-fpm: magazin zjenica bazena 1.7 437764 36152 10 22? S 0:18 2754:3.5 php-fpm: magazine gutl pool 1.3 356724 27164 10 38? S 0:00 5624:0.0 php-fpm: bazen gutl cgr 1.0 365168 22696 28 0? S 16. april 7900:0.3 php-fpm: bazen cgr učenik 2.5 457052 52444 25 20? S 23. april 11021:0.4 php-fpm: zjenica zjenice bazena 2.5 458316 52864 28 5? S 57. april 11254:0.0 php-fpm: učenik bazena cgr 1.0 363152 21708 28 0? S 12. april 13184:0.0 php-fpm: bazen cgr cgr 1.0 362872 21360 28 0? S 08. april XNUMX:XNUMX php-fpm: bazen cgr

Kao što vidite ... razdvajanje PHP obrade od strane korisnika koji koriste Nginx + PHP-FPM je zaista jednostavno, tamo vidite da postoji nekoliko spremišta, jer postoji nekoliko korisnika.

ZAKLJUČCI

Što se tiče servera, nikad niste dovoljno paranoični ... sa sigurnošću se ne treba igrati, što više uvijek pokušavamo poboljšati sigurnost svojih servera i njihovih usluga, to će nas manje uspjeti (uspješan) pokušaj hakiranja ili nešto slično 😉


9 komentara, ostavi svoj

Ostavite komentar

Vaša e-mail adresa neće biti objavljena. Obavezna polja su označena sa *

*

*

  1. Za podatke odgovoran: Miguel Ángel Gatón
  2. Svrha podataka: Kontrola neželjene pošte, upravljanje komentarima.
  3. Legitimacija: Vaš pristanak
  4. Komunikacija podataka: Podaci se neće dostavljati trećim stranama, osim po zakonskoj obavezi.
  5. Pohrana podataka: Baza podataka koju hostuje Occentus Networks (EU)
  6. Prava: U bilo kojem trenutku možete ograničiti, oporaviti i izbrisati svoje podatke.

  1.   dhunter rekao je

    Gaara, u današnje vrijeme ove bi stvari trebale biti automatizirane što je više moguće, preporučujem ti da probaš Ansible. Bez agenta, potreban vam je samo python na udaljenom hostu, vrlo jednostavan za konfiguriranje, yaml datoteke, Jinja predlošci.

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

    1.    KZKG ^ Gaara rekao je

      Da vidimo, to nije uvijek samo za WordPress stranice, i ... haha ​​možda Ansible klikne volao, ali više volim znati točno kako sve funkcionira na serveru, čak i ako moram potrošiti 1 minutu na stvaranje novih čarapa i novi VHost 😀

      1.    dhunter rekao je

        Uz Ansible automatizirate sve, radite praktički sve što želite, prednost ove metode je u tome što inkapsulirate praksu, a zatim izvršavate po volji, zamislite da imate jako opterećenu web lokaciju i želite izvršiti balansiranje opterećenja između aplikacijskih servera. morate biti konfigurirani potpuno isto, ne možete preskočiti korak ili učiniti nešto drugačije u jednom od njih, možete li zamisliti da postupak radite korak po korak 4 puta? Uz Ansible je jednostavno poput dodavanja imena hosta u datoteku inventara i Voilá !!

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

      2.    dhunter rekao je

        Žao nam je zbog kulta Ansible, ali to je jedna od ovih tehnologija koju otkrivate i želite da je svi sada koriste, jer je tako cool i praktična, to je kao kad otkrijete NGINX i želite da svi vaši prijatelji odmah napuste Apache.

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

  2.   mstaaravin rekao je
  3.   rots87 rekao je

    Ja sam (ili želim studirati) programer i sa NGIX-om sam imao puno problema prilikom konfiguriranja nginx + php-fpm. Znam da Archlinux distro nije najbolje napraviti ga kao server, ali svaki put kad bih ažurirao verziju ngixa ili php-a, sve se uvijek srušilo pa sam odustao od pokušaja lol ... Za danas ostajem kod klasičnog Apache + PHP, ali vidjet ću hoću li ponovo zaobići NGIX ... možda na virtualnoj mašini

    1.    dhunter rekao je

      Mentalitet se malo mijenja, nginx služi statičnom sadržaju i služi kao obrnuti proxy za php-fpm koji je taj koji pokreće pravi PHP, morate započeti u dijelovima i postići implementaciju korak po korak, potražite vodič za implementaciju okvir s kojim radite, svaki ima svoje detalje po imenima javnosti, statičkim, resursima itd ...

  4.   Anónimo rekao je

    Čini li zajednici veliku uslugu napuštanjem riječi "hostear", koja ne postoji. Bogami, je li tako teško reći "domaćin"?

  5.   Wil rekao je

    Pozdrav, slijedeći vaš primjer, volio bih znati da li bi se spremište moglo napraviti samo za wordpress backen, to jest za wp-administratora koji je napravio novu utičnicu za dolazne veze na pozadinu

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