Најнормалното нешто на светот кога имате сервер е да размислувате за безбедност и поголема безбедност, никогаш не можете да бидете доволно параноични
Нешто вообичаена практика и НИШТО не се препорачува, е да се користи ист корисник за сите бази на податоци, уште полошо ако се користи root, што колку и да изгледа неверојатно, има и такви кои (поради скитник или незнаење) сторете го ова, јас веќе зборував за тоа зошто НЕ треба да се однесувате вака друг постСега е време да објасниме како и зошто е подобро да се оддели обработката на веб-серверот во различни корисници, овој пат ќе се користи Nginx.
Индекс
Што е тоа на корисниците и веб-серверот?
За да го објасниме тоа на краток и едноставен начин, веб-серверот (apache, nginx, што и да е) треба да отвори процеси во системот, процеси што ќе бидат тие што ќе ги земат датотеките од HDD (слики, итн.) И ќе ги направат достапен на прелистувачот на клиентот. Веб-серверот не може едноставно да ги земе датотеките и да ги манипулира, бидејќи тие не се никој, т.е. му треба корисник кој ќе биде оној што ќе го стори сето ова на крајот, а тој корисник е тој за кој зборувам, разбираш?
Што е тоа за раздвојување во неколку корисници?
Да претпоставиме дека имаме 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-блог. слушај чорап.сопственик = блог слушај.група = блог попладне = по барање попладне.max_children = 96 chdir = /
Забелешка: Она што ги обележувам со црвена боја е она што тие мора да го изменат во зависност од корисникот што претходно го создадоа. На пример, ако создадат друг VHost со друг корисник (форум на пример) тогаш наместо блог едноставно ставете форум во секоја од редовите, не е разбрано?
4. Откако ќе се конфигурира новиот базен (датотеката blog.conf што само што ја создадовме и изменивме), на ред е да му кажете на Nginx VHost да користи различен чорап за тој VHost, за оваа страница. Чорапот што ќе се користи ќе биде оној што претходно го објавивме (/var/run/php5-fpm-blog.sock). Ајде да го уредиме Nginx VHost и во делот за обработка на PHP, посочуваме да ги користиме чорапите. На пример:
локација ~ \ .php $ {ако (! -f $ request_filename) {врати 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-податоци или root или некој сличен, туку од страна на корисникот што ние претходно дефинирани.
Еве ти го покажувам резултатот од а ps aux | grep fpm на еден од серверите на мојот јазол:
ps aux | grep fpm е-книга 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: е-книга за базен е-книга 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: е-книга за базен www 608 0.0 0.2 350084 5008? S Mar30 0:00 php-fpm: базен www www 609 0.0 0.2 350600 5048 30? S Mar0 00:3 php-fpm: базен www tv611 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: базен тв3 тв615 0.0 0.0 349360 1204 30? S Mar0 00:3 php-fpm: магазин за базен тв1818 1.7 1.7 437576 36396 09? С 55:0 46:2264 php-fpm: списание за списанија со базени 1.9 1.7 437332 35884 10? С 15:0 26:2338 php-fpm: ученик за списание со базен 4.3 1.0 428992 22196 10? С 18:0 53:2413 php-fpm: списание за ученици во базенот 1.8 1.7 437764 36152 10? С 22:0 18:2754 php-fpm: списание за гасен базен 3.5 1.3 356724 27164 10? С 38:0 00:5624 php-fpm: базен gutl cgr 0.0 1.0 365168 22696 28? С април 0 16:7900 php-fpm: базен ЦГР ученик 0.3 2.5 457052 52444 25? С апр20 23:11021 php-fpm: ученик на базен 0.4 2.5 458316 52864 28? С април5 57:11254 php-fpm: ученик во базен cgr 0.0 1.0 363152 21708 28? С април 0 12:13184 php-fpm: базен cgr cgr 0.0 1.0 362872 21360 28? С април 0 08:XNUMX php-fpm: базен cgr
Како што можете да видите ... одделувањето на процесирањето PHP од страна на корисниците со употреба на Nginx + PHP-FPM е навистина лесно, таму гледате дека има неколку базени, бидејќи има и неколку корисници.
Заклучоци
Кога станува збор за сервери, вие никогаш не сте доволно параноични ... безбедноста не е нешто со кое треба да се игра, колку повеќе секогаш се обидуваме да ја подобриме безбедноста на нашите сервери и нивните услуги, толку е помала веројатноста да се плашиме од (успешен) обид за хакирање или нешто слично
9 коментари, оставете ги вашите
Гаара, во сегашно време овие работи треба да бидат автоматизирани што е можно повеќе, препорачувам да пробате со Ansible. Без агент, потребен ви е само питон на оддалечениот домаќин, многу едноставен за конфигурирање, yaml-датотеки, шаблони на jaинја.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Ајде да видиме, тоа не е секогаш само за веб-страниците на WordPress и ... хаха можеби Одговорен клик volao, но претпочитам да знам точно како работи сè на серверот, дури и ако треба да потрошам 1 минута создавајќи нови чорапи и нов VHost
Со Ansible автоматизирате сè, правите практично што сакате, предноста на овој метод е тоа што ја капсулирате праксата и потоа извршувате по своја волја, замислете дека имате силно натоварена страница и сакате да направите балансирање на оптоварување помеѓу серверите за апликации, овие мора да бидете конфигурирани исти, не можете да прескокнете чекор или да направите нешто поразлично во некој од нив, дали можете да замислите да ја направите постапката чекор по чекор 4 пати? Со Ansible е едноставно како додавање на името на домаќинот во инвентарната датотека и Voilá !!
http://www.ansible.com/how-ansible-works
Sorал ми е за култот Ансибл, но тоа е една од овие технологии што ја откривате и сакате сите да ја користат сега затоа што е многу кул и практична, тоа е како кога ќе го откриете 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 distro не е најдобро да се направи како сервер, но секогаш кога ажурирав верзија на ngix или php секогаш се расипуваше па се откажував од обидот lol ... За денес останувам со класичниот Apache + PHP, но ќе видам дали повторно ќе заобиколам NGIX ... можеби во виртуелна машина
Менталитетот малку се менува, nginx ја опслужува статичката содржина и служи како обратен полномошник за php-fpm што е тој што ја води вистинската PHP, треба да започнете во делови и да го постигнете распоредувањето чекор по чекор, да побарате водич за распоредување рамката со која работите, секој од нив има детали според имињата на јавноста, статиката, ресурсите, итн ...
Дали заедницата има голема корист да се откаже од зборот „хостеар“, што не постои. Богами, дали е толку тешко да се каже „домаќин“?
Поздрав, следејќи го вашиот пример, би сакал да знам дали може да се направи базен само за заднината на текстот, односно за wp-администраторот што прави нов приклучок за влезни врски со задниот дел
локација / wp-администратор {
корен /var/www/yoursite.com/wp-admin;
индекс индекс.php индекс.html индекс.htm;
локација ~ ^ / wp-администратор /(.+. php) $ {
try_files $ uri = 404;
корен /var/www/yoursite.com/wp-admin;
вклучуваат / итн / 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/;
}
}