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

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

Pomalo uobičajena 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 nevjerojatno izgledalo, ima onih koji (zbog skitnice ili neznanja) učini ovo, već sam govorio o tome zašto se NE bi trebao ponašati ovako još jedan post, sada je vrijeme da objasnimo kako i zašto je bolje razdvojiti obradu web poslužitelja od različitih korisnika, ovaj put će se on koristiti Nginx.

DedicatedServer_SubImage

Što je to od korisnika i web poslužitelja?

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

Što je to razdvajanje kod nekoliko korisnika?

Pretpostavimo da na našem poslužitelju 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 za pristup koristimo zasebne baze podataka i različite korisnike, na kraju datotekama obje web stranice manipulira isti korisnik, PHP-ovom obradom upravlja isti korisnik za sve web stranice (obično www-podaci). Ovo nije preporučljiva praksa, bolje je da sve bude dobro odvojeno, kako kaže stara poslovica, bolje je biti siguran nego žaliti.

Ok, razumijem, kako to mogu učiniti s Nginxom

2000px-Nginx_logo.svg

Prvo što treba napomenuti je da Nginx nema vlastiti modul koji se bavi PHP-ovom obradom kao Apache, za Nginx trebamo koristiti PHP-CGI ili PHP-FPM, koji djeluje jednako dobro (ili bolje) od Apachea. 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 sustava ćemo koristiti, pretpostavit ću da još uvijek nemamo nijednog stvorenog i dobro, kreirajmo ga:

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

adduser blog

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

Blogiram korisnika samo da slijedim primjer, da će prva web lokacija koju ćemo ugostiti biti blog, pa da ... da znam svakog korisnika s kojim je web mjestom povezano

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 nano blog.conf
[blog] korisnik = blog
grupa = blog
preslušaj = / var / run / php5-fpm-blog.čarapa slušaj.vlasnik = blog
slušaj.grupa = 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 stvore drugi VHost s drugim korisnikom (foruma na primjer) onda umjesto bloga jednostavno stavite forum u svaki red, nije li razumljivo?

4. Jednom kada se konfigurira novi bazen (datoteku blog.conf koju smo upravo stvorili i uredili), red je da kažete Nginx VHost-u da koristi drugu čarapu za taj VHost, za ovu stranicu. Upotrijebit će se čarapa koju smo prethodno prijavili (/var/run/php5-fpm-blog.sock). Uredimo Nginx VHost i u dijelu za obradu PHP-a naznačujemo upotrebu 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 (ti su retci na primjer unutar / etc / nginx / sites-enabled / vhost-blog) napravite to s čarapama koje se nalaze u /var/run/php5-fpm-blog.sock ... koja je prethodno kreirana prilikom uređivanja /etc/php5/fpm/pool.d/blog.conf ... razumije li se to ne ?

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

Ovdje ću vam pokazati izlaz a ps pomoćni | grep fpm na jednom od poslužitelja mog čvora:

ps pomoćni | grep fpm ebook 586 0.0 0.0 349360 1204? S 30. ožujka 0:00 php-fpm: e-knjiga bazena e-knjiga 589 0.0 0.0 349360 1204? S 30. ožujka 0:00 php-fpm: e-knjiga bazena www 608 0.0 0.2 350084 5008? S 30. ožujka 0:00 php-fpm: bazen www www 609 0.0 0.2 350600 5048 30? S 0. ožujka 00:3 php-fpm: bazen www tv611 0.0 0.0 349360 1204 30? S 0. ožujka 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: magazin magazina za bazen 1.7 437332 35884 10 15? S 0:26 2338:4.3 php-fpm: učenik časopisa bazena 1.0 428992 22196 10 18? S 0:53 2413:1.8 php-fpm: časopis za zjenice bazena 1.7 437764 36152 10 22? S 0:18 2754:3.5 php-fpm: časopis gutl za bazen 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. travnja 7900:0.3 php-fpm: bazen cgr učenik 2.5 457052 52444 25 20? S 23. travnja 11021:0.4 php-fpm: zjenica zjenice bazena 2.5 458316 52864 28 5? S 57. travnja 11254:0.0 php-fpm: zjenica bazenagrgr 1.0 363152 21708 28 0? S 12. travnja 13184:0.0 php-fpm: bazen cgr cgr 1.0 362872 21360 28 0? S 08. travnja XNUMX:XNUMX php-fpm: bazen cgr

Kao što vidite ... razdvajanje PHP obrade od strane korisnika pomoću Nginx + PHP-FPM-a je stvarno jednostavno, tamo vidite da postoji nekoliko spremišta, jer postoji nekoliko korisnika.

Zaključci

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


Sadržaj članka pridržava se naših načela urednička etika. Da biste prijavili pogrešku, kliknite ovdje.

9 komentara, ostavi svoj

Ostavite svoj komentar

Vaša email adresa neće biti objavljen. Obavezna polja su označena s *

*

*

  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 obvezi.
  5. Pohrana podataka: Baza podataka koju hostira Occentus Networks (EU)
  6. Prava: U bilo kojem trenutku možete ograničiti, oporaviti i izbrisati svoje podatke.

  1.   dhunter dijo

    Gaara, u sadašnje vrijeme te 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 dijo

      Da vidimo, to nije uvijek samo za WordPress web stranice, i ... haha ​​možda Ansible klikne volao, ali više volim znati točno kako sve funkcionira na poslužitelju, čak i ako moram potrošiti 1 minutu stvarajući nove čarape i novi VHost 😀

      1.    dhunter dijo

        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 učitanu stranicu i želite izvršiti uravnoteženje opterećenja između aplikacijskih poslužitelja, oni moraju biti konfigurirani potpuno isti, 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? S Ansible je jednostavno poput dodavanja imena hosta u datoteku inventara i Voilá !!

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

      2.    dhunter dijo

        Ž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.   Truleži87 dijo

    Ja sam (ili želim studirati) programer i s NGIX-om sam imao puno problema prilikom konfiguriranja nginx + php-fpm. Znam da Archlinux distro nije najbolje napraviti ga kao poslužitelj, 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 s klasičnim Apache + PHP-om, ali Vidjet ću hoću li ponovno obići NGIX ... možda u virtualnom stroju

    1.    dhunter dijo

      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 ...

  3.   anoniman dijo

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

  4.   Wil dijo

    Pozdrav, slijedeći vaš primjer, želio bih znati da li bi se bazen mogao 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;
    index 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/;
    }
    }