A legnormálisabb dolog a világon, amikor szerver van, a biztonságra és a nagyobb biztonságra gondolni, soha nem lehet elég paranoiás 😉
Kissé elterjedt gyakorlat és SEMMI sem ajánlott, hogy ugyanazt a felhasználót kell használni minden adatbázisban, ami még rosszabb, ha root-t használunk, ami bármennyire is hihetetlen, vannak, akik (csavargás vagy tudatlanság miatt) tedd ezt, már beszéltem arról, hogy miért NEM szabad így cselekedned egy másik bejegyzésItt az ideje, hogy elmagyarázza, hogyan és miért jobb elkülöníteni a webkiszolgáló feldolgozását a különböző felhasználóknál, ezúttal ezt fogja használni nginx.
Mi a felhasználók és a webszerver?
Rövid és egyszerű magyarázatához a webszervernek (apache, nginx, bármi más) meg kell nyitnia a rendszerben a folyamatokat, azokat a folyamatokat, amelyek a fájlokat a HDD-ről (képek stb.) Veszik át, és elérhetővé teszik az ügyfél böngészője számára. . A webszerver nem képes egyszerűen úgy elvenni a fájlokat és manipulálni őket, hogy senki nem létezik, vagyis olyan felhasználóra van szüksége, aki a végén megteszi mindezt, és ez a felhasználó az, akiről beszélek.
Mi az, ha különválasztjuk a felhasználókat?
Tegyük fel, hogy a szerverünkön van 2 webhely, a miénk, ami egy személyes projekt, és egy másik (képzeljük el, hogy a barátnőnk vagy a testvérünké). Még akkor is, ha külön adatbázisokat és különböző felhasználókat használunk a hozzáférésükhöz, végül mindkét weboldal fájljait ugyanaz a felhasználó manipulálja, a PHP-feldolgozást ugyanaz a felhasználó kezeli az összes webhelyhez (általában www-data). Ez nem ajánlott gyakorlat, jobb, ha mindent jól elkülönítenek, ahogy egy régi mondás tartja, jobb biztonságban lenni, mint sajnálni.
Ok, megértem, hogy tudom csinálni az Nginx-szel
Először is meg kell jegyezni, hogy az Nginx-nek nincs saját modulja, amely a PHP-feldolgozást úgy kezeli, mint az Apache, az Nginx-hez pedig a PHP-CGI-t vagy a PHP-FPM-et kell használnunk, amelyek ugyanolyan jól (vagy jobban) működnek, mint az Apache. Tehát ahhoz, hogy a PHP feldolgozást elkülönítsük a különböző felhasználóktól, meg kell változtatnunk a sorokat a PHP konfigurációs fájlokban (CGI vagy FPM), nem pedig maga az Nginx.
Tegyük fel, hogy használja PHP-FPM, létrehozunk egy konfigurációs fájlt a medence Egy adott webhely, azaz a pool segítségével különíthetjük el a PHP-feldolgozást a PHP-FPM-től, de részenként haladunk.
1. Először tudnunk kell, hogy a rendszer melyik felhasználóját fogjuk használni, feltételezem, hogy még mindig nincs létrehozott és jól létrehozott:
adduser blog
Elkezdjük a felhasználó létrehozásának szokásos folyamatát, megadjuk a jelszót stb.
1. Először menjünk az /etc/php5/fpm/pool.d/ oldalra:
cd /etc/php5/fpm/pool.d/
2. Most létrehozunk egy blog.conf nevű fájlt:
touch blog.conf
3. Most feltesszük a készlet konfigurációját, amelyet a VHost bloghoz fogunk használni:
[blog] felhasználó = blog csoport = blog hallgat = / var / run / php5-fpm-blog.zokni figyelj.tulajdonos = blog figyelj.csoport = blog pm = ondemand pm.max_children = 96 chdir = /
Megjegyzés: Amit piros színnel jelölök, azt meg kell változtatniuk a korábban létrehozott felhasználótól függően. Például, ha másik VHostot hoznak létre egy másik felhasználóval (fórum például), akkor a blog helyett egyszerűen tegyél fórumot az egyes sorokba, nem érted?
4. Miután konfigurálta az új készletet (az imént létrehozott és szerkesztett blog.conf fájl), itt a sor, hogy elmondjuk az Nginx VHost-nak, hogy más zoknit használjon az adott VHost számára, ehhez a webhelyhez. A használt zokni lesz az, amit korábban deklaráltunk (/var/run/php5-fpm-blog.sock). Szerkesszük az Nginx VHost-ot, és a PHP feldolgozó részben jelezzük, hogy használjuk ezt a zoknit. Például:
hely ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.zokni;
közé tartozik a fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }
Amint láthatja, jelzem, hogy az adott VHost (ezek a sorok például az / etc / nginx / sites-enabled / vhost-blog belsejében találhatók) csináld a /var/run/php5-fpm-blog.sock fájlban található zoknikkal ... amelyet korábban létrehoztunk az /etc/php5/fpm/pool.d/blog.conf szerkesztésekor ... nem értette?
5. Ha ez megtörtént, újraindítjuk mind a szolgáltatásokat (php5-fpm és nginx), mind a voila-t, látni fogjuk, hogy az adott webhely (vhost) feldolgozását NEM a www-data vagy a root vagy bárki hasonló végzi, hanem az a felhasználó, amelyet korábban definiáltunk .
Itt mutatom meg az a kimenetét ps aux | grep fpm a csomópontom egyik szerverén:
ps aux | grep fpm e-könyv 586 0.0 0.0 349360 1204? S március 30. 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S március 30. 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S március 30. 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048 30? S március 0. 00:3 php-fpm: pool www tv611 0.0 0.0 349360 1204 30? S március 0. 00:3 php-fpm: pool tv3 tv615 0.0 0.0 349360 1204 30? S március 0, 00:3 php-fpm: pool tv1818 magazin 1.7 1.7 437576 36396 09 55? S 0:46 2264:1.9 php-fpm: pool magazin magazin 1.7 437332 35884 10 15? S 0:26 2338:4.3 php-fpm: pool magazin tanuló 1.0 428992 22196 10 18? S 0:53 2413:1.8 php-fpm: pool pupill magazin 1.7 437764 36152 10 22? S 0:18 2754:3.5 php-fpm: pool gutl magazin 1.3 356724 27164 10 38? S 0:00 5624:0.0 php-fpm: pool gutl cgr 1.0 365168 22696 28 0? S április 16. 7900:0.3 php-fpm: pool cgr pupilla 2.5 457052 52444 25 20? S ápr. 23, 11021:0.4 php-fpm: pool pupill pupilla 2.5 458316 52864 28 5? S ápr. 57, 11254:0.0 php-fpm: medence pupilla cgr 1.0 363152 21708 28 0? S április 12. 13184:0.0 php-fpm: pool cgr cgr 1.0 362872 21360 28 0? S ápr08 XNUMX:XNUMX php-fpm: pool cgr
Mint látható ... a PHP-feldolgozás szétválasztása a felhasználók által az Nginx + PHP-FPM használatával nagyon egyszerű, ott látja, hogy több készlet van, mivel több felhasználó is van.
Következtetések
Ha a szerverekről van szó, soha nem vagy elég paranoiás ... a biztonságot nem kell játszani, minél többet próbálunk javítani a szervereink és szolgáltatásaik biztonságán, annál kevésbé valószínű, hogy megijedünk egy (sikeres) feltörési kísérlettől, ill. bármi hasonló 😉
Gaara, a jelenlegi időkben ezeket a dolgokat a lehető legnagyobb mértékben automatizálni kell, javasoljuk, hogy próbáld ki az Ansible-t. Ügynök nélkül csak a távoli állomáson kell python, nagyon egyszerűen konfigurálható, yaml fájlok, Jinja sablonok.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Lássuk, ez nem mindig csak a WordPress-webhelyek esetében érvényes, és ... haha talán az Ansible rákattan a volao-ra, de én jobban tudom, hogy pontosan tudom, hogy minden működik a szerveren, még akkor is, ha 1 percet kell töltenem egy új zokni és egy új VHost 😀
Az Ansible alkalmazással mindent automatizál, gyakorlatilag mindent megtesz, amit csak akar, ennek a módszernek az az előnye, hogy összefoglalja a gyakorlatot, majd tetszés szerint végrehajtja, elképzelheti, hogy erősen megterhelt webhelye van, és terheléselosztást szeretne végezni az alkalmazáskiszolgálók között, ezeket meg kell pontosan ugyanúgy van beállítva, nem hagyhat ki egy lépést sem, vagy bármi mást tehet az egyikben, el tudja képzelni, hogy az eljárást négyszer végezze lépésről lépésre? Az Ansible használatával olyan egyszerű, mint hozzáadni a gazdagépnevet a leltárfájlhoz és a Voilá !!
http://www.ansible.com/how-ansible-works
Elnézést az Ansible kultusz miatt, de ez az egyik ilyen technológia, amelyet felfedez, és azt szeretné, hogy mindenki használja most, mert nagyon klassz és praktikus, olyan, mint amikor felfedezi az NGINX-et, és azt szeretné, ha az összes barátja azonnal elhagyná az Apache-ot.
https://speakerdeck.com/slok/ansible-all-the-things
Biztos vagyok benne, hogy a bejegyzésem kiegészíti ezt ...
http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/
Fejlesztő vagyok (vagy tanulmányozom), és az NGIX-szel sok problémám volt az nginx + php-fpm konfigurálásakor. Tudom, hogy az archlinux disztribúció nem a legjobb szerverként való elkészítéshez, de valahányszor frissítettem egy ngix vagy php verziót, minden mindig összeomlott, így feladtam a kísérletet lol ... Ma a klasszikus Apache + mellett maradok PHP, de meglátom, megnézem-e még egyszer az NGIX-et ... esetleg egy virtuális gépen
A mentalitás kissé megváltozik, az nginx a statikus tartalmat szolgálja, és fordított proxy-ként szolgál a php-fpm számára, vagyis az, aki az igazi PHP-t futtatja. Részben kell elindulnia, és lépésről lépésre el kell érnie a telepítést, útmutatót kell keresnie a telepítéshez a keretrendszer, amellyel dolgozik, mindegyiknek megvan a részletei a nyilvánosság, a statikus, az erőforrások stb. nevével.
Tegye meg a közösségnek azt a nagy szívességet, hogy felhagynak a "hostear" szóval, amely nem létezik. Isten szerint ilyen nehéz azt mondani, hogy "házigazda"?
Üdvözlet, példádat követve szeretném tudni, hogy csak a wordpress backen-hez lehet-e készíteni egy poolot, vagyis azt, hogy a wp-admin új socket-et készítsen a bejövő kapcsolatokhoz a háttérbe
location / wp-admin {
root /var/www/yoursite.com/wp-admin;
index index.php index.html index.htm;
hely ~ ^ / wp-admin /(.+. php) $ {
try_files $ uri = 404;
root /var/www/yoursite.com/wp-admin;
a / 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/;
}
}