Най-нормалното нещо на света, когато имате сървър, е да мислите за сигурност и повече сигурност, никога не можете да бъдете достатъчно параноик
Малко често срещана практика и НИЩО не се препоръчва е да се използва един и същ потребител за всички бази данни, по-лошо, ако се използва root, което колкото и невероятно да изглежда, има и такива,поради блудство или невежество) направи това, аз вече говорих за това защо НЕ трябва да се държиш така в друга публикацияСега е време да обясним как и защо е по-добре да отделим обработката на уеб сървъра от различни потребители, този път той ще използва Nginx.
Какво е това на потребителите и уеб сървъра?
За да го обясни кратко и просто, уеб сървърът (apache, nginx, каквото и да е) трябва да отвори процеси в системата, процеси, които ще бъдат тези, които вземат файловете от твърдия диск (изображения и т.н.) и ги правят достъпни за браузъра на клиента. Уеб сървърът не може просто да вземе файловете и да ги манипулира като никой, тоест той се нуждае от потребител, който в крайна сметка ще направи всичко това, а този потребител е този, за когото говоря, разбира ли се?
Какво представлява разделянето на няколко потребители?
Да предположим, че на нашия сървър имаме 2 уебсайта, нашият, който е личен проект, и още един (нека си представим, че е на нашата приятелка или брат). Дори когато използваме отделни бази данни и различни потребители за достъп до тях, в крайна сметка файловете на двата уебсайта се манипулират от един и същ потребител, обработката на PHP се управлява от един и същ потребител за всички сайтове (обикновено това са www-данни). Това е непрепоръчителна практика, по-добре е всичко да бъде добре разделено, както казва една стара поговорка, по-добре е да сте в безопасност, отколкото да съжалявате.
Добре, разбирам, как да го направя с Nginx
Първото нещо, което трябва да се отбележи, е, че Nginx няма собствен модул, който да обработва PHP обработката, както Apache, за Nginx трябва да използваме PHP-CGI или PHP-FPM, които работят също толкова добре (или по-добре) от Apache. Така че, за да отделим PHP обработката между различни потребители, ще трябва да сменим линиите в PHP конфигурационните файлове (CGI или FPM), а не самия Nginx.
Да предположим, че използвате PHP-FPM, ще създадем конфигурационен файл на басейн За конкретен сайт, тоест пулът е начинът да се отдели PHP обработката от PHP-FPM, но ние вървим на части.
1. Първо трябва да знаем кой потребител на системата ще използваме, ще предположа, че все още нямаме създадени и добре, нека го създадем:
adduser blog
Ще започнем нормалния процес на създаване на потребител, въведете паролата и т.н.
1. Първо да отидем на /etc/php5/fpm/pool.d/:
cd /etc/php5/fpm/pool.d/
2. Сега ще създадем файл, наречен blog.conf:
touch blog.conf
3. Сега ще поставим конфигурацията на пула, която ще използваме за блога на VHost:
[блог] потребител = блог група = блог слушане = / var / run / php5-fpm-блог. чорап Listen.owner = блог Listen.group = блог pm = ondemand pm.max_children = 96 chdir = /
Забележка: Това, което ги маркирам в червено, е това, което те трябва да модифицират в зависимост от потребителя, който преди са създали. Например, ако създадат друг VHost с друг потребител (форум например) тогава вместо блог просто сложете форум във всеки от редовете, разбира ли се?
4. След като конфигурацията на новия пул (файлът blog.conf, който току-що създадохме и редактирахме), дойде ред да кажете на Nginx VHost да използва различен чорап за този VHost, за този сайт. Чорапът, който ще бъде използван, ще бъде този, който предварително декларирахме (/var/run/php5-fpm-blog.sock). Нека редактираме Nginx VHost и в частта за обработка на PHP посочваме да използваме тези чорапи. Например:
местоположение ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-блог. чорап;
включва fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }
Както можете да видите, посочвам, че PHP обработката на този VHost (тези редове са например вътре / etc / nginx / sites-enabled / vhost-blog) направете го с чорапите, намерени в /var/run/php5-fpm-blog.sock ... който е този, който създадохме по-рано при редактиране /etc/php5/fpm/pool.d/blog.conf ... е не разбра ли?
5. След като това стане, рестартираме и двете услуги (php5-fpm и nginx) и voila, ще видим, че обработката на този сайт (vhost) НЕ се извършва от www-data или root или някой подобен, а от потребителя, когото ние предварително дефинирани.
Тук ви показвам резултата от ps aux | grep fpm на един от сървърите на моя възел:
ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S 30 март 0:00 php-fpm: пул ebook ebook 589 0.0 0.0 349360 1204? S 30 март 0:00 php-fpm: електронна книга на пула www 608 0.0 0.2 350084 5008? S 30 март 0:00 php-fpm: басейн www www 609 0.0 0.2 350600 5048 30? S 0 март 00:3 php-fpm: пул www tv611 0.0 0.0 349360 1204 30? S0 март 00:3 php-fpm: pool tv3 tv615 0.0 0.0 349360 1204 30? S 0 март 00:3 php-fpm: пул tv1818 списание 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: списание за басейн списание 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: ученик за списание за басейн 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: списание за ученици на басейна 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: списание за басейн gutl 3.5 1.3 356724 27164 10? S 38:0 00:5624 php-fpm: pool gutl cgr 0.0 1.0 365168 22696 28? S 0 април 16:7900 php-fpm: пул cgr ученик 0.3 2.5 457052 52444 25? S Април 20 23:11021 php-fpm: ученик на пула на зеницата 0.4 2.5 458316 52864 28? S 5 април 57:11254 php-fpm: ученик на басейна cgr 0.0 1.0 363152 21708 28? S 0 април 12:13184 php-fpm: басейн cgr cgr 0.0 1.0 362872 21360 28? S 0 април 08:XNUMX php-fpm: пул cgr
Както можете да видите ... разделянето на PHP обработката от потребители, използващи Nginx + PHP-FPM, е наистина лесно, там виждате, че има няколко пула, тъй като има няколко потребители.
Заключения
Що се отнася до сървърите, никога не сте достатъчно параноични ... сигурността не е нещо, с което да се играе, колкото повече винаги се опитваме да подобрим сигурността на нашите сървъри и техните услуги, толкова по-малко вероятно ще бъдем изплашени от (успешен) опит за хакване или нещо подобно 😉
Гаара, в момента тези неща трябва да бъдат автоматизирани колкото е възможно повече, препоръчвам ти да опиташ Ansible. Без агент се нуждаете само от python на отдалечения хост, много лесен за конфигуриране, yaml файлове, шаблони на Jinja.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Да видим, това не винаги е само за WordPress сайтове и ... хаха може би Ansible щраква volao, но предпочитам да знам как точно работи всичко на сървъра, дори ако трябва да прекарам 1 минута в създаване на нови чорапи и нов VHost 😀
С Ansible вие автоматизирате всичко, правите практически каквото искате, предимството на този метод е, че капсулирате практиката и след това изпълнявате по желание, представете си, че имате силно натоварен сайт и искате да направите балансиране на натоварването между сървърите на приложения, тези трябва да бъде конфигуриран точно по същия начин, не можете да пропуснете стъпка или да направите нещо различно в една от тях, можете ли да си представите да правите процедурата стъпка по стъпка 4 пъти? С Ansible е толкова просто, колкото добавянето на името на хоста към файла с инвентара и Voilá !!
http://www.ansible.com/how-ansible-works
Съжалявам за култа Ansible, но това е една от тези технологии, която откривате и искате всички да я използват сега, защото е толкова готина и практична, все едно когато откриете NGINX и искате всичките ви приятели да напуснат Apache незабавно.
https://speakerdeck.com/slok/ansible-all-the-things
Сигурен съм, че публикацията ми допълва това ...
http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/
Аз съм (или се уча да бъда) разработчик и с NGIX имах много проблеми при конфигурирането на nginx + php-fpm. Знам, че дистрибуцията на archlinux не е най-добрата да я направи като сървър, но всеки път, когато актуализирах версия на ngix или php, всичко винаги се сриваше, така че се отказвах от опита хаха ... За днес оставам с класическия Apache + PHP, но ще видя дали ще обиколя NGIX отново ... може би във виртуална машина
Манталитетът се променя малко, nginx обслужва статичното съдържание и служи като обратен прокси за php-fpm, който изпълнява истинския PHP, трябва да започнете на части и да постигнете внедряването стъпка по стъпка, потърсете ръководство за разполагане рамка, с която работите, всеки има своя детайл по имената на публичното, статичното, ресурсите и т.н. ...
Направете ли общността голямата услуга да изостави думата „домакин“, която не съществува. За бога, толкова ли е трудно да се каже „домакин“?
Поздрави, следвайки вашия пример, бих искал да знам дали може да се направи пул само за wordpress backen, тоест за wp-admin, който прави нов сокет за входящи връзки към бекенда
местоположение / wp-admin {
root /var/www/yoursite.com/wp-admin;
индекс index.php index.html index.htm;
местоположение ~ ^ / wp-admin /(.+. php) $ {
try_files $ uri = 404;
root /var/www/yoursite.com/wp-admin;
включват / 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/;
}
}