Het normaalste in de wereld als je een server hebt, is om na te denken over beveiliging en meer beveiliging, je kunt nooit paranoïde genoeg zijn
Een enigszins gangbare praktijk en NIETS aanbevolen, is om dezelfde gebruiker te gebruiken voor alle databases, erger nog als root wordt gebruikt, wat hoe ongelooflijk het ook mag lijken, er zijn die (door landloperij of onwetendheid) dit doen, heb ik al gesproken over waarom je NIET zo zou moeten handelen in een ander bericht, nu is het tijd om uit te leggen hoe en waarom het beter is om de webserververwerking in verschillende gebruikers te scheiden, deze keer gebruikt het Nginx.
Wat is dat van gebruikers en webserver?
Om het op een korte en eenvoudige manier uit te leggen, moet de webserver (apache, nginx, wat dan ook) processen in het systeem openen, processen die de bestanden van de harde schijf halen (afbeeldingen, enz.) En ze maken. beschikbaar voor de browser van de klant. De webserver kan de bestanden niet zomaar nemen en manipuleren als niemand, dat wil zeggen, hij heeft een gebruiker nodig die dit uiteindelijk allemaal zal doen, en die gebruiker is degene waar ik het over heb, begrijp je dat?
Wat is het scheiden in meerdere gebruikers?
Stel dat we op onze server 2 websites hebben, de onze is een persoonlijk project en een andere (Laten we ons voorstellen dat het onze vriendin of broer is). Zelfs als we afzonderlijke databases en verschillende gebruikers gebruiken om ze te openen, worden de bestanden van beide websites uiteindelijk door dezelfde gebruiker gemanipuleerd, wordt de PHP-verwerking beheerd door dezelfde gebruiker voor alle sites (het zijn meestal www-data). Dit is een niet aanbevolen praktijk, het is beter om alles goed gescheiden te hebben, zoals een oud gezegde luidt: het is beter om veilig te zijn dan sorry.
Oké, ik begrijp het, hoe doe ik het met Nginx
Het eerste om op te merken is dat Nginx geen eigen module heeft die PHP-verwerking afhandelt zoals Apache doet, voor Nginx moeten we PHP-CGI of PHP-FPM gebruiken, die net zo goed (of beter) werkt dan Apache. Dus om PHP-verwerking over verschillende gebruikers te scheiden, moeten we regels in PHP-configuratiebestanden (CGI of FPM) wijzigen, niet in Nginx zelf.
Stel dat je gebruikt PHP-FPM, maken we een configuratiebestand van zwembad Voor een specifieke site is een pool de manier om PHP-verwerking te scheiden van PHP-FPM, maar we gaan in delen.
1. Eerst moeten we weten welke gebruiker van het systeem we zullen gebruiken, ik ga ervan uit dat we er nog steeds geen hebben gemaakt en laten we het maken:
adduser blog
We starten het normale proces van het aanmaken van een gebruiker, voeren het wachtwoord in, enz.
1. Laten we eerst naar /etc/php5/fpm/pool.d/ gaan:
cd /etc/php5/fpm/pool.d/
2. Nu gaan we een bestand maken met de naam blog.conf:
touch blog.conf
3. Nu zullen we de configuratie plaatsen van de pool die we zullen gebruiken voor de VHost-blog:
[blog] gebruiker = blog groep = blog luister = / var / run / php5-fpm-blog.sock listen.owner = blog luister.groep = blog pm = ondemand pm.max_children = 96 chdir = /
Opmerking: Wat ik ze in rood markeer, is wat ze moeten wijzigen, afhankelijk van de gebruiker die ze eerder hebben gemaakt. Als ze bijvoorbeeld een andere VHost maken met een andere gebruiker (forum bijvoorbeeld) plaats dan in plaats van blog gewoon een forum in elk van de regels, wordt het begrepen?
4. Zodra de configuratie van de nieuwe pool (het blog.conf-bestand dat we zojuist hebben gemaakt en bewerkt), is het de beurt om de Nginx VHost te vertellen om een andere sok te gebruiken voor die VHost, voor deze site. De sok die zal worden gebruikt, is degene die we eerder hebben gedeclareerd (/var/run/php5-fpm-blog.sock). Laten we de Nginx VHost bewerken en in het PHP-verwerkingsgedeelte geven we aan om die sokken te gebruiken. Bijvoorbeeld:
locatie ~ \ .php $ {if (! -f $ request_filename) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blog.sok;
inclusief fastcgi_params; fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name; fastcgi_read_timeout 300; }
Zoals je kunt zien, geef ik aan dat de PHP-verwerking van die VHost (die regels staan bijvoorbeeld in / etc / nginx / sites-enabled / vhost-blog) doe het met de sokken gevonden in /var/run/php5-fpm-blog.sock ... dat is degene die we eerder hebben gemaakt bij het bewerken van /etc/php5/fpm/pool.d/blog.conf ... is het niet begrepen ?
5. Zodra dit is gebeurd, herstarten we beide services (php5-fpm en nginx) en voila, we zullen zien dat de verwerking van die site (vhost) NIET wordt gedaan door www-data of root of iets dergelijks, maar door de gebruiker die we eerder gedefinieerd.
Hier laat ik je de output zien van een ps aux | grep fpm op een van de servers van mijn node:
ps aux | grep fpm e-boek 586 0.0 0.0 349360 1204? S maart 30 0:00 php-fpm: pool ebook ebook 589 0.0 0.0 349360 1204? S maart 30 0:00 php-fpm: pool ebook www 608 0.0 0.2 350084 5008? S mrt30 0:00 php-fpm: pool www www 609 0.0 0.2 350600 5048? S maart 30 0:00 php-fpm: pool www tv3 611 0.0 0.0 349360 1204? S maart 30 0:00 php-fpm: pool tv3 tv3 615 0.0 0.0 349360 1204? S maart 30 0:00 php-fpm: pool tv3 magazine 1818 1.7 1.7 437576 36396? S 09:55 0:46 php-fpm: pool magazine magazine 2264 1.9 1.7 437332 35884? S 10:15 0:26 php-fpm: pool magazine leerling 2338 4.3 1.0 428992 22196? S 10:18 0:53 php-fpm: pool pupil magazine 2413 1.8 1.7 437764 36152? S 10:22 0:18 php-fpm: pool gutl magazine 2754 3.5 1.3 356724 27164? S 10:38 0:00 php-fpm: pool gutl cgr 5624 0.0 1.0 365168 22696? S Apr28 0:16 php-fpm: pool cgr leerling 7900 0.3 2.5 457052 52444? S Apr25 20:23 php-fpm: pool pupil leerling 11021 0.4 2.5 458316 52864? S april 28 5:57 php-fpm: pool pupil cgr 11254 0.0 1.0 363152 21708? S Apr28 0:12 php-fpm: zwembad cgr cgr 13184 0.0 1.0 362872 21360? S Apr28 0:08 php-fpm: zwembad cgr
Zoals je kunt zien ... het scheiden van de PHP-verwerking door gebruikers die Nginx + PHP-FPM gebruiken, is heel eenvoudig, daar zie je dat er verschillende pools zijn, omdat er meerdere gebruikers zijn.
Conclusies
Als het om servers gaat, ben je nooit paranoïde genoeg ... beveiliging is niet iets om mee te spelen, hoe meer we altijd proberen om de beveiliging van onze servers en hun diensten te verbeteren, hoe kleiner de kans dat we bang zullen zijn voor een (succesvolle) hackpoging of iets dergelijks 😉
Gaara, in de huidige tijd moeten deze dingen zoveel mogelijk worden geautomatiseerd, ik raad je aan Ansible te proberen. Zonder agent heb je alleen python nodig op de externe host, heel eenvoudig te configureren, yaml-bestanden, Jinja-sjablonen.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Eens kijken, dat is niet altijd alleen voor WordPress-sites, en ... haha misschien klikt Ansible volao, maar ik geef er de voorkeur aan om precies te weten hoe alles werkt op de server, ook al moet ik 1 minuut besteden aan het maken van een nieuwe sokken en een nieuwe VHost 😀
Met Ansible automatiseer je alles, je doet praktisch wat je wilt, het voordeel van deze methode is dat je de praktijk inkapselt en vervolgens naar believen uitvoert, stel je voor dat je een zwaar belaste site hebt en je wilt load balancing doen tussen applicatieservers, deze moeten exact hetzelfde worden geconfigureerd, je kunt geen stap overslaan of iets anders doen in een van de twee, kun je je voorstellen dat je de procedure stap voor stap 4 keer zou moeten doen? Met Ansible is het net zo eenvoudig als het toevoegen van de hostnaam aan het inventarisbestand en Voilá !!
http://www.ansible.com/how-ansible-works
Sorry voor de Ansible-sekte, maar het is een van deze technologieën die je ontdekt en je wilt dat iedereen het nu gebruikt omdat het zo cool en praktisch is, het is net als wanneer je NGINX ontdekt en je wilt dat al je vrienden Apache onmiddellijk verlaten.
https://speakerdeck.com/slok/ansible-all-the-things
Ik weet zeker dat mijn bericht hier een aanvulling op is ...
http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/
Ik ben (of studeer) een ontwikkelaar en met NGIX had ik veel problemen bij het configureren van nginx + php-fpm. Ik weet dat de archlinux distro niet de beste is om het als server te maken, maar elke keer dat ik een versie van ngix of php bijwerkte, crashte alles altijd, dus ik gaf de poging op lol ... Voor vandaag blijf ik bij de klassieke Apache + PHP maar ik zal zien of ik weer rond NGIX loop ... misschien op een virtuele machine
De mentaliteit verandert een beetje, nginx bedient de statische inhoud en dient als een reverse proxy voor de php-fpm die de echte PHP draait, je moet in delen beginnen en de implementatie stap voor stap bereiken, zoek een gids om te implementeren het raamwerk waarmee u werkt, elk heeft zijn detail door de namen van het publiek, statisch, bronnen, enz ...
Doe de gemeenschap een grote gunst door het woord "hostear", dat niet bestaat, te laten varen. Bij God, is het zo moeilijk om "gastheer" te zeggen?
Groeten, in navolging van uw voorbeeld zou ik graag willen weten of er alleen een pool gemaakt kan worden voor de wordpress backen, dat wil zeggen, voor de wp-admin die een nieuwe socket maakt voor inkomende verbindingen met de backend
locatie / wp-admin {
root /var/www/yoursite.com/wp-admin;
index index.php index.html index.htm;
locatie ~ ^ / 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/;
}
}