Isännöi useita VHosts-käyttäjiä eri käyttäjillä Nginxissä

Normaalin asia maailmassa, kun sinulla on palvelin, on ajatella turvallisuudesta ja lisää turvallisuutta, et voi koskaan olla tarpeeksi vainoharhainen 😉

Hieman yleinen käytäntö ja MITÄÄN ei suositella, on käyttää samaa käyttäjää kaikissa tietokannoissa, pahempaa, jos käytetään juuria, mikä on niin uskomatonta kuin se saattaa tuntua, on niitä, jotka (väärennösten tai tietämättömyyden takia) tee tämä, puhuin jo siitä, miksi sinun ei pitäisi toimia näin toinen viestiNyt on aika selittää, miten ja miksi on parempi erottaa verkkopalvelimen käsittely eri käyttäjiltä, ​​tällä kertaa se käyttää nginx.

DedicatedServer_SubImage

Mitä käyttäjät ja verkkopalvelin ovat?

Selittämään se lyhyellä ja yksinkertaisella tavalla web-palvelimen (apache, nginx, mikä tahansa) on avattava prosessit järjestelmässä, prosessit, jotka ottavat tiedostot kiintolevyltä (kuvat jne.) Ja asettavat ne asiakkaan selaimen saataville. . Verkkopalvelin ei voi vain ottaa tiedostoja ja manipuloida niitä olemaan kukaan, toisin sanoen, se tarvitsee käyttäjän, joka tekee kaiken tämän lopulta, ja kyseinen käyttäjä on se, josta puhun, ymmärrätkö?

Mitä erottaa useissa käyttäjissä?

Oletetaan, että palvelimellamme on 2 verkkosivustoa, oma, joka on henkilökohtainen projekti, ja toinen (Kuvitellaan, että se on tyttöystävän tai veljemme). Vaikka käytämme erillisiä tietokantoja ja eri käyttäjiä pääsemään niihin, loppujen lopuksi sama käyttäjä manipuloi molempien verkkosivustojen tiedostoja, sama käyttäjä hallinnoi PHP-käsittelyä kaikille sivustoille (yleensä www-data). Tämä ei ole suositeltava käytäntö, on parempi, että kaikki erotetaan hyvin, kuten vanhassa sanonnassa sanotaan, on parempi olla turvallinen kuin pahoillani.

Ok Ymmärrän, miten teen sen Nginxin kanssa

2000px-Nginx_logo.svg

Ensinnäkin on huomattava, että Nginxillä ei ole omaa moduulia, joka käsittelee PHP-käsittelyä kuten Apache, Nginxille meidän on käytettävä PHP-CGI: ta tai PHP-FPM: ää, joka toimii yhtä hyvin (tai paremmin) kuin Apache. Joten erottaaksemme PHP-prosessoinnin eri käyttäjiltä, ​​meidän on vaihdettava rivejä PHP-määritystiedostoissa (CGI tai FPM), ei itse Nginxissä.

Oletetaan, että käytät PHP-FPM, luomme kokoonpanotiedoston pool tietylle sivustolle, toisin sanoen pooli on tapa erottaa PHP-käsittely PHP-FPM: stä, mutta menemme osittain.

1. Meidän on ensin tiedettävä, mitä järjestelmän käyttäjää käytämme. Oletan, että meillä ei vielä ole luotuja ja hyvin, luodaan se:

Kaikki seuraavat komennot TÄYTYY suorittaa järjestelmänvalvojan oikeuksilla, joko suoralla juurella tai sudolla

adduser blog

Aloitamme normaalin käyttäjän luomisprosessin, annamme salasanan jne.

Blogin käyttäjälle vain seuratakseni esimerkkiä, että ensimmäinen isännöimämme sivusto on blogi, ja että ... tietää jokaisen käyttäjän, johon sivusto liittyy

1. Mennään ensin osoitteeseen /etc/php5/fpm/pool.d/:

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

2. Nyt luomme tiedoston nimeltä blog.conf:

touch blog.conf

3. Nyt laitamme kokoonpanon, jota käytämme VHost-blogiin:

Muokkaa blog.conf-tiedostoa nanolla ... esimerkiksi: sudo nanoblog.conf
[blogi] käyttäjä = blogi
ryhmä = blogi
kuuntele = / var / run / php5-fpm-blogi. sukka kuuntele. omistaja = blogi
kuuntele.ryhmä = blogi
pm = ondemand pm.max_children = 96 chdir = /

Huom: Merkitsen ne punaisella, mitä heidän on muokattava riippuen aiemmin luomastaan ​​käyttäjästä. Esimerkiksi, jos he luovat toisen VHostin toisen käyttäjän kanssa (foorumi esimerkiksi), sitten blogin sijaan yksinkertaisesti laita foorumi kullekin riville, ymmärretäänkö se?

4. Kun uuden poolin kokoonpano (juuri luomamme ja muokkaamamme blog.conf-tiedosto), on vuoro kertoa Nginx VHostille, että hän käyttää eri sukkaa tälle sivustolle. Käytettävä sukka on aiemmin ilmoittamamme sukka (/var/run/php5-fpm-blog.sock). Muokkaamme Nginx VHostia ja osoitamme PHP-käsittelyosassa, että käytät näitä sukkia. Esimerkiksi:

sijainti ~ \ .php $ {if (! -f $ request_tiedostonimi) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blogi.sukka;
sisältää fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Kuten näette, ilmoitan, että kyseisen VHostin (nämä rivit ovat esimerkiksi / etc / nginx / sites-enabled / vhost-blogin sisällä) tee se sukilla, jotka löytyvät tiedostosta /var/run/php5-fpm-blog.sock ... joka on aiemmin luoma muokkaamalla tiedostoa /etc/php5/fpm/pool.d/blog.conf ... ymmärretäänkö ei ?

5. Kun tämä on tehty, käynnistämme uudelleen sekä palvelut (php5-fpm ja nginx) että voila, näemme, että kyseisen sivuston (vhost) käsittelyä EI tee www-data tai root tai kukaan muu vastaava, vaan aiemmin määrittelemämme käyttäjä .

Tässä näytän sinulle a: n tuloksen ps aux | grep fpm yhdessä solmuni palvelimista:

ps aux | grep fpm e-kirja 586 0.0 0.0 349360 1204? S maaliskuu 30 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S maaliskuu 30 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S maaliskuu 30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048 30? S maaliskuu 0 00:3 php-fpm: pool www tv611 0.0 0.0 349360 1204? S maaliskuu 30 0:00 php-fpm: pool tv3 tv3 615 0.0 0.0 349360 1204? S maaliskuu 30 0:00 php-fpm: pool tv3 -lehti 1818 1.7 1.7 437576 36396? S 09:55 0:46 php-fpm: pool-lehden aikakauslehti 2264 1.9 1.7 437332 35884? S 10:15 0:26 php-fpm: poolilehden oppilas 2338 4.3 1.0 428992 22196? S 10:18 0:53 php-fpm: uima-altaan oppilaslehti 2413 1.8 1.7 437764 36152? S 10:22 0:18 php-fpm: pool gutl -lehti 2754 3.5 1.3 356724 27164? S 10:38 0:00 php-fpm: altaan suolisto cgr 5624 0.0 1.0 365168 22696? S 28. huhtikuuta 0:16 php-fpm: pool cgr pupill 7900 0.3 2.5 457052 52444? S 25. huhtikuuta 20:23 php-fpm: uima-altaan oppilaan oppilas 11021 0.4 2.5 458316 52864? S 28. huhtikuuta 5:57 php-fpm: altaan oppilas cgr 11254 0.0 1.0 363152 21708? S 28. huhtikuuta 0:12 php-fpm: pool cgr cgr 13184 0.0 1.0 362872 21360? S 28. huhtikuuta 0:08 php-fpm: pool cgr

Kuten näette ... PHP-käsittelyn erottaminen käyttäjiltä Nginx + PHP-FPM: n avulla on todella helppoa, siellä näet, että pooleja on useita, koska käyttäjiä on useita.

Päätelmät

Palvelimien suhteen et ole koskaan tarpeeksi vainoharhainen ... turvallisuutta ei ole pelattavaa, sitä enemmän yritämme aina parantaa palvelimiemme ja heidän palvelujensa turvallisuutta, sitä vähemmän todennäköisesti pelkäämme (onnistuneesta) hakkerointiyrityksestä tai mitään vastaavaa 😉


9 kommenttia, jätä omasi

Jätä kommentti

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *

*

*

  1. Vastuussa tiedoista: Miguel Ángel Gatón
  2. Tietojen tarkoitus: Roskapostin hallinta, kommenttien hallinta.
  3. Laillistaminen: Suostumuksesi
  4. Tietojen välittäminen: Tietoja ei luovuteta kolmansille osapuolille muutoin kuin lain nojalla.
  5. Tietojen varastointi: Occentus Networks (EU) isännöi tietokantaa
  6. Oikeudet: Voit milloin tahansa rajoittaa, palauttaa ja poistaa tietojasi.

  1.   metsästäjä dijo

    Gaara, nykyisin nämä asiat tulisi automatisoida mahdollisimman paljon, suosittelen kokeilemaan Ansibleia. Ilman edustajaa tarvitset vain pythonin etäisännässä, erittäin helppo määrittää, yaml-tiedostot, Jinja-mallit.

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

    1.    KZKG ^ Gaara dijo

      Katsotaanpa, että se ei aina koske vain WordPress-sivustoja, ja ... haha ​​ehkä Ansible napsauttaa volao, mutta mieluummin tiedän tarkalleen, miten kaikki toimii palvelimella, vaikka minun pitäisi käyttää 1 minuutti uusien sukkien ja uusi VHost 😀

      1.    metsästäjä dijo

        Ansible-sovelluksen avulla automatisoit kaiken, teet käytännössä mitä haluat. Tämän menetelmän etuna on, että kapseloit harjoituksen ja suoritat sen sitten haluamallasi tavalla, kuvittele, että sinulla on paljon ladattu sivusto ja haluat tasapainottaa sovelluspalvelimien välillä, näiden on oltava määritetty täsmälleen samalla tavalla, et voi ohittaa vaihetta tai tehdä jotain erilaista yhdessä niistä, voitko kuvitella suorittavan toimenpiteen vaihe vaiheelta 4 kertaa? Ansible-sovelluksen kanssa se on yhtä helppoa kuin lisätä isäntänimi inventaariotiedostoon ja Voilá !!

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

      2.    metsästäjä dijo

        Anteeksi Ansible-kultista, mutta se on yksi näistä tekniikoista, jotka löydät ja haluat kaikkien käyttävän sitä nyt, koska se on niin siistiä ja käytännöllistä, se on kuin kun löydät NGINXin ja haluat kaikkien ystäviesi poistuvan Apache-laitteesta välittömästi.

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

  2.   mstaaravin dijo

    Olen varma, että viestini täydentää tätä ...
    http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/

  3.   Mätät87 dijo

    Olen (tai opiskelen) kehittäjäksi ja NGIX: n kanssa minulla oli paljon ongelmia määritettäessä nginx + php-fpm. Tiedän, että archlinux distro ei ole paras tehdä siitä palvelin, mutta joka kerta kun päivitin ngix- tai php-version, se kaatui aina kaiken, joten hylkäsin yrityksen lol ... Tänään jäin klassiseen Apache + PHP: hen mutta näen kävelenkö uudelleen NGIX: n ympärillä ... ehkä virtuaalikoneella

    1.    metsästäjä dijo

      Mentaliteetti muuttuu hieman, nginx palvelee staattista sisältöä ja toimii käänteisenä välityspalvelimena php-fpm: lle, joka on todellisen PHP: n johtaja, sinun on aloitettava osittain ja saavutettava käyttöönotto vaihe vaiheelta, etsittävä opas käyttöönottoa varten kehyksessä, jolla työskentelet, jokaisella on yksityiskohdat yleisön, staattisen, resurssien jne. nimillä ...

  4.   anonyymi dijo

    Tee yhteisölle suuri suositus sanan "hostear" hylkäämisestä, jota ei ole olemassa. Onko Jumalan niin vaikea sanoa "isäntä"?

  5.   Wil dijo

    Terveisiä, esimerkkisi perusteella haluaisin tietää, voisiko allas muodostaa vain wordpress backenille, toisin sanoen wp-järjestelmänvalvojalle, joka muodostaa uuden liitännän tuleville yhteyksille backendiin

    location / wp-admin {
    root /var/www/sivustosi.com/wp-admin;
    index index.php index.html index.htm;
    sijainti ~ ^ / wp-admin /(.+. php) $ {
    try_files $ uri = 404;
    root /var/www/sivustosi.com/wp-admin;
    sisältää / 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/;
    }
    }