Hostuj wiele VHostów z różnymi użytkownikami w Nginx

Najbardziej normalną rzeczą na świecie, gdy masz serwer, jest myślenie o bezpieczeństwie i większym bezpieczeństwie, nigdy nie możesz być wystarczająco paranoikiem

Dość powszechną praktyką i NIC zalecanym jest używanie tego samego użytkownika dla wszystkich baz danych, gorzej, jeśli używany jest root, co może wydawać się niewiarygodne, są tacy, którzy (z powodu włóczęgostwa lub ignorancji) zrób to, już mówiłem o tym, dlaczego NIE powinieneś się tak zachowywać w inny postTeraz czas wyjaśnić, jak i dlaczego lepiej oddzielić przetwarzanie serwera WWW dla różnych użytkowników, tym razem będzie on używany nginx.

DedicatedServer_SubImage

Co to jest z użytkownikami i serwerem WWW?

Aby wyjaśnić to w zwięzły i prosty sposób, serwer WWW (apache, nginx, cokolwiek) musi otwierać procesy w systemie, procesy, które będą tymi, które pobierają pliki z dysku twardego (obrazy itp.) I sprawiają, że dostępne dla przeglądarki klienta. Serwer WWW nie może po prostu pobrać plików i manipulować nimi, będąc nikim, to znaczy potrzebuje użytkownika, który będzie tym, który zrobi to wszystko w końcu, a tym użytkownikiem jest ten, o którym mówię, rozumiesz?

Na czym polega rozdzielanie kilku użytkowników?

Załóżmy, że na naszym serwerze mamy 2 strony internetowe, naszą, która jest projektem osobistym, i drugą (wyobraźmy sobie, że to nasza dziewczyna lub brat). Nawet jeśli używamy oddzielnych baz danych i różnych użytkowników, aby uzyskać do nich dostęp, ostatecznie pliki obu witryn są manipulowane przez tego samego użytkownika, przetwarzanie PHP jest zarządzane przez tego samego użytkownika dla wszystkich witryn (zwykle dane-www). To niezalecana praktyka, lepiej mieć wszystko dobrze oddzielone, jak mówi stare powiedzenie, lepiej być bezpiecznym niż żałować.

Ok, rozumiem, jak mam to zrobić z Nginx

2000px-Nginx_logo.svg

Pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że Nginx nie ma własnego modułu, który obsługuje przetwarzanie PHP tak, jak robi to Apache, w przypadku Nginx musimy użyć PHP-CGI lub PHP-FPM, które działa równie dobrze (lub lepiej) niż Apache. Aby oddzielić przetwarzanie PHP od różnych użytkowników, będziemy musieli zmienić linie w plikach konfiguracyjnych PHP (CGI lub FPM), a nie sam Nginx.

Załóżmy, że używasz PHP FPM, utworzymy plik konfiguracyjny basen Dla konkretnej witryny, to znaczy pula, jest sposobem na oddzielenie przetwarzania PHP od PHP-FPM, ale idziemy w części.

1. Najpierw musimy wiedzieć, z jakiego użytkownika systemu będziemy korzystać, założę, że jeszcze nie mamy żadnego utworzonego i cóż, stwórzmy go:

Wszystkie poniższe polecenia MUSZĄ być wykonywane z uprawnieniami administratora, albo z bezpośrednim rootem, albo przy użyciu sudo

adduser blog

Rozpoczniemy normalny proces tworzenia użytkownika, wpisujemy hasło itp.

Piszę użytkownika na blogu tylko po to, aby naśladować przykład, że pierwsza witryna, którą będziemy hostować, będzie blogiem, no cóż ... żeby wiedzieć, z którą stroną jest powiązana każdy użytkownik

1. Najpierw przejdźmy do /etc/php5/fpm/pool.d/:

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

2. Teraz utworzymy plik o nazwie blog.conf:

touch blog.conf

3. Teraz umieścimy konfigurację puli, której będziemy używać na blogu VHost:

Edytuj plik blog.conf za pomocą nano ... na przykład: sudo nano blog.conf
[blog] user = blog
grupa = blog
Listen = / var / run / php5-fpm-blog.sock listen.owner = blog
Listen.group = blog
pm = na żądanie pm.max_children = 96 chdir = /

Uwaga: Zaznaczam je na czerwono, co muszą modyfikować w zależności od utworzonego wcześniej użytkownika. Na przykład, jeśli utworzą innego VHost z innym użytkownikiem (na przykład forum) to zamiast bloga po prostu wpisuję forum w każdym z wierszy, nie rozumiesz?

4. Po skonfigurowaniu nowej puli (plik blog.conf, który właśnie utworzyliśmy i edytowaliśmy), nadeszła kolej, aby powiedzieć Nginx VHost, aby używał innej skarpety dla tego VHost dla tej witryny. Używana będzie skarpeta, którą wcześniej zadeklarowaliśmy (/var/run/php5-fpm-blog.sock). Edytujmy Nginx VHost iw części przetwarzania PHP wskazujemy, aby używać tych skarpet. Na przykład:

lokalizacja ~ \ .php $ {if (! -f $ nazwa_pliku_żądania) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.skarpetka;
dołącz fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }

Jak widać, wskazuję, że przetwarzanie PHP tego VHosta (te wiersze znajdują się na przykład w / etc / nginx / sites-enabled / vhost-blog) zrób to za pomocą skarpet znajdujących się w /var/run/php5-fpm-blog.sock ... który jest tym, który utworzyliśmy wcześniej podczas edycji /etc/php5/fpm/pool.d/blog.conf ... nie zrozumiał?

5. Gdy to zrobimy, ponownie uruchomimy obie usługi (php5-fpm i nginx) i voila, zobaczymy, że przetwarzanie tej witryny (vhost) NIE jest wykonywane przez dane www, root lub kogokolwiek podobnego, ale przez użytkownika, którego my wcześniej zdefiniowane.

Tutaj pokażę ci wyjście pliku ps aux | grep fpm na jednym z serwerów mojego węzła:

ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: basen ebook ebook 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: basen ebook www 608 0.0 0.2 350084 5008? 30 marca 0:00 php-fpm: basen www www 609 0.0 0.2 350600 5048 30? 0 marca 00:3 php-fpm: pool www tv611 0.0 0.0 349360 1204 30? 0 marca 00:3 php-fpm: basen tv3 tv615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: basen tv1818 magazine 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: magazyn basenowy 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: uczeń magazynu basenowego 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: magazyn uczniowski basen 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: basen gutl magazyn 3.5 1.3 356724 27164 10? S 38:0 00:5624 php-fpm: basen gutl cgr 0.0 1.0 365168 22696 28? S 0 kwietnia 16:7900 php-fpm: basen cgr uczeń 0.3 2.5 457052 52444 25? S 20 kwietnia 23:11021 php-fpm: uczeń z basenu 0.4 2.5 458316 52864 28? S 5 kwietnia 57:11254 php-fpm: basen uczeń cgr 0.0 1.0 363152 21708 28? S 0 kwietnia 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28? S 0 kwietnia 08:XNUMX php-fpm: pool cgr

Jak widać ... rozdzielenie przetwarzania PHP przez użytkowników za pomocą Nginx + PHP-FPM jest naprawdę łatwe, widzisz, że jest kilka pul, ponieważ jest kilku użytkowników.

Wnioski

Jeśli chodzi o serwery, nigdy nie jesteś wystarczająco paranoikiem ... bezpieczeństwo nie jest czymś, czym można się bawić, im bardziej zawsze staramy się poprawić bezpieczeństwo naszych serwerów i ich usług, tym mniej prawdopodobne jest, że będziemy się bać (udanej) próba włamania lub coś podobnego 😉


Treść artykułu jest zgodna z naszymi zasadami etyka redakcyjna. Aby zgłosić błąd, kliknij tutaj.

9 komentarzy, zostaw swoje

Zostaw swój komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

*

*

  1. Odpowiedzialny za dane: Miguel Ángel Gatón
  2. Cel danych: kontrola spamu, zarządzanie komentarzami.
  3. Legitymacja: Twoja zgoda
  4. Przekazywanie danych: Dane nie będą przekazywane stronom trzecim, z wyjątkiem obowiązku prawnego.
  5. Przechowywanie danych: baza danych hostowana przez Occentus Networks (UE)
  6. Prawa: w dowolnym momencie możesz ograniczyć, odzyskać i usunąć swoje dane.

  1.   łowca powiedział

    Gaara, w obecnych czasach te rzeczy powinny być jak najbardziej zautomatyzowane, polecam wypróbowanie Ansible. Bez agenta potrzebujesz tylko Pythona na zdalnym hoście, bardzo prosty w konfiguracji, pliki yaml, szablony Jinja.

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

    1.    KZKG ^ Gaara powiedział

      Zobaczmy, to nie zawsze dotyczy witryn WordPress i ... haha ​​może Ansible klika volao, ale wolę wiedzieć dokładnie, jak wszystko działa na serwerze, nawet jeśli mam spędzić 1 minutę na tworzeniu nowych skarpet i nowy VHost 😀

      1.    łowca powiedział

        Dzięki Ansible automatyzujesz wszystko, robisz praktycznie wszystko, co chcesz, zaletą tej metody jest to, że hermetyzujesz praktykę, a następnie wykonujesz ją dowolnie, wyobraź sobie, że masz mocno obciążoną witrynę i chcesz wyrównać obciążenie między serwerami aplikacji, muszą być skonfigurowane dokładnie tak samo, że nie można pominąć kroku ani zrobić nic innego w jednym z nich, czy możesz sobie wyobrazić wykonanie procedury krok po kroku 4 razy? Z Ansible jest to tak proste, jak dodanie nazwy hosta do pliku inwentarza i Voilá !!

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

      2.    łowca powiedział

        Przepraszam za kult Ansible, ale jest to jedna z tych technologii, które odkrywasz i chcesz, aby wszyscy z niej korzystali, ponieważ jest tak fajna i praktyczna, że ​​to tak, jakbyś odkrywał NGINX i chciał, aby wszyscy twoi przyjaciele natychmiast opuścili Apache.

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

  2.   Mstaaravin powiedział
  3.   Zgnilizny87 powiedział

    Jestem (lub studiuję) programistą iz NGIX miałem wiele problemów podczas konfigurowania nginx + php-fpm. Wiem, że dystrybucja archlinux nie jest najlepsza do zrobienia go jako serwer, ale za każdym razem, gdy aktualizowałem wersję ngix lub php, wszystko zawsze się zawieszało, więc rezygnowałem z próby lol ... Na dziś pozostaję przy klasycznym Apache + PHP, ale zobaczę, czy ponownie obejdę NGIX ... może na maszynie wirtualnej

    1.    łowca powiedział

      Mentalność zmienia się nieco, nginx obsługuje statyczną zawartość i służy jako odwrotne proxy dla php-fpm, czyli tego, który uruchamia prawdziwy PHP, musisz zacząć w częściach i osiągnąć wdrożenie krok po kroku, poszukaj przewodnika po wdrożeniu framework, z którym pracujesz, każdy ma swoje szczegóły pod nazwami publicznymi, statycznymi, zasobami itp.

  4.   anonimowy powiedział

    Wyświadcz społeczności wielką przysługę za porzucenie słowa „gospodarz”, które nie istnieje. Na Boga, czy tak trudno jest powiedzieć „gospodarz”?

  5.   Wil powiedział

    Pozdrowienia, idąc za twoim przykładem, chciałbym wiedzieć, czy pula mogłaby zostać utworzona tylko dla backendu wordpress, to znaczy dla wp-admin tworzącego nowe gniazdo dla połączeń przychodzących do zaplecza

    location / wp-admin {
    root /var/www/yoursite.com/wp-admin;
    index index.php index.html index.htm;
    lokalizacja ~ ^ / 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/;
    }
    }