La chose la plus normale au monde quand on a un serveur, c'est de penser à la sécurité et plus de sécurité, on ne peut jamais être assez paranoïaque
Une pratique quelque peu courante et RIEN recommandée, est d'utiliser le même utilisateur pour toutes les bases de données, pire si root est utilisé, ce qui aussi incroyable que cela puisse paraître, il y a ceux qui (par vagabondage ou ignorance) faites ceci, j'ai déjà expliqué pourquoi vous ne devriez PAS agir comme ça dans un autre posteIl est maintenant temps d'expliquer comment et pourquoi il est préférable de séparer le traitement du serveur Web entre différents utilisateurs, cette fois, il utilisera Nginx.
Quelle est celle des utilisateurs et du serveur Web?
Pour l'expliquer de manière brève et simple, le serveur Web (apache, nginx, peu importe) a besoin d'ouvrir des processus dans le système, processus qui seront ceux qui prendront les fichiers du disque dur (images, etc.) et les créeront disponible pour le navigateur du client. Le serveur Web ne peut pas simplement prendre les fichiers et les manipuler en étant personne, c'est-à-dire qu'il a besoin d'un utilisateur qui sera celui qui fera tout cela à la fin, et cet utilisateur est celui dont je parle, vous comprenez?
Qu'est-ce que la séparation en plusieurs utilisateurs?
Supposons que sur notre serveur nous ayons 2 sites Web, le nôtre qui est un projet personnel, et un autre (imaginons que c'est notre petite amie ou notre frère). Même lorsque nous utilisons des bases de données distinctes et des utilisateurs différents pour y accéder, au final les fichiers des deux sites sont manipulés par le même utilisateur, le traitement PHP est géré par le même utilisateur pour tous les sites (il s'agit généralement de www-data). C'est une pratique non recommandée, il vaut mieux que tout soit bien séparé, comme le dit un vieil adage, il vaut mieux prévenir que guérir.
Ok je comprends, comment puis-je le faire avec Nginx
La première chose à noter est que Nginx n'a pas son propre module qui gère le traitement PHP comme le fait Apache, pour Nginx nous devons utiliser PHP-CGI ou PHP-FPM, qui fonctionne aussi bien (ou mieux) qu'Apache. Donc, pour séparer le traitement PHP entre différents utilisateurs, nous devrons changer les lignes dans les fichiers de configuration PHP (CGI ou FPM), pas Nginx lui-même.
Supposons que vous utilisiez PHP FPM, nous allons créer un fichier de configuration de pool Pour un site spécifique, c'est-à-dire, un pool est le moyen de séparer le traitement PHP de PHP-FPM, mais nous y allons par parties.
1. Nous devons d'abord savoir quel utilisateur du système nous allons utiliser, je suppose que nous n'en avons toujours pas créé et bien, créons-le:
adduser blog
Nous allons démarrer le processus normal de création d'un utilisateur, entrer le mot de passe, etc.
1. Allons d'abord à /etc/php5/fpm/pool.d/:
cd /etc/php5/fpm/pool.d/
2. Maintenant, nous allons créer un fichier appelé blog.conf:
touch blog.conf
3. Nous allons maintenant mettre la configuration du pool que nous allons utiliser pour le blog VHost:
[blogue] utilisateur = blogue groupe = blogue écoute = / var / run / php5-fpm-blogue.sock listen.owner = blogue ecoute.groupe = blogue pm = à la demande pm.max_children = 96 chdir = /
Observation: Ce que je les marque en rouge, c'est ce qu'ils doivent modifier en fonction de l'utilisateur qu'ils ont précédemment créé. Par exemple, s'ils créent un autre VHost avec un autre utilisateur (forum par exemple) alors au lieu de blog, mettez simplement forum dans chacune des lignes, est-ce compris?
4. Une fois la configuration du nouveau pool (le fichier blog.conf que nous venons de créer et de modifier), c'est au tour de dire au Nginx VHost d'utiliser une chaussette différente pour ce VHost, pour ce site. La chaussette qui sera utilisée sera celle que nous avons précédemment déclarée (/var/run/php5-fpm-blog.sock). Modifions le Nginx VHost et dans la partie traitement PHP, nous indiquons d'utiliser ces chaussettes. Par exemple:
location ~ \ .php $ {if (! -f $ nom_fichier_demande) {return 404; }
fastcgi_pass unix: / var / run / php5-fpm-blogue.chaussette;
inclure fastcgi_params; fastcgi_param SCRIPT_FILENAME $ racine_document $ fastcgi_script_name; fastcgi_read_timeout 300; }
Comme vous pouvez le voir, j'indique que le traitement PHP de ce VHost (ces lignes sont par exemple dans / etc / nginx / sites-enabled / vhost-blog) faites-le avec les chaussettes trouvées dans /var/run/php5-fpm-blog.sock ... qui est celle que nous avons précédemment créée lors de l'édition de /etc/php5/fpm/pool.d/blog.conf ... n'est-ce pas compris ?
5. Une fois que cela est fait, nous redémarrons les deux services (php5-fpm et nginx) et voila, nous verrons que le traitement de ce site (vhost) n'est PAS effectué par www-data ou root ou toute autre personne similaire, mais par l'utilisateur que nous défini précédemment.
Ici, je vous montre la sortie d'un psaux | grep fpm sur l'un des serveurs de mon nœud:
ps aux | grep fpm ebook 586 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: ebook pool ebook 589 0.0 0.0 349360 1204? S Mar30 0:00 php-fpm: ebook pool www 608 0.0 0.2 350084 5008? S 30 mars 0:00 php-fpm: piscine www www 609 0.0 0.2 350600 5048 30? S 0 mars 00:3 php-fpm: piscine www tv611 0.0 0.0 349360 1204 30? S 0 mars 00:3 php-fpm: piscine tv3 tv615 0.0 0.0 349360 1204 30? S 0 mars 00:3 php-fpm: magazine pool tv1818 1.7 1.7 437576 36396 09? S 55:0 46:2264 php-fpm: magazine magazine pool 1.9 1.7 437332 35884 10? S 15:0 26:2338 php-fpm: élève du magazine de la piscine 4.3 1.0 428992 22196 10? S 18:0 53:2413 php-fpm: magazine des élèves de la piscine 1.8 1.7 437764 36152 10? S 22:0 18:2754 php-fpm: magazine pool 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 avril 16:7900 php-fpm: élève cgr pool 0.3 2.5 457052 52444 25? S 20 avril 23:11021 php-fpm: élève de la piscine 0.4 2.5 458316 52864 28? S 5 avril 57:11254 php-fpm: élève de la piscine cgr 0.0 1.0 363152 21708 28? S 0 avril 12:13184 php-fpm: pool cgr cgr 0.0 1.0 362872 21360 28? S 0 avril 08:XNUMX php-fpm: pool cgr
Comme vous pouvez le voir ... séparer le traitement PHP par les utilisateurs utilisant Nginx + PHP-FPM est vraiment facile, là vous voyez qu'il y a plusieurs pools, car il y a plusieurs utilisateurs.
Conclusions
En ce qui concerne les serveurs, vous n'êtes jamais assez paranoïaque ... la sécurité n'est pas quelque chose avec quoi jouer, plus nous essayons toujours d'améliorer la sécurité de nos serveurs et de leurs services, moins nous aurons peur d'un (succès) tentative de piratage ou quelque chose de similaire
Gaara, à l'heure actuelle, ces choses devraient être automatisées autant que possible, je vous recommande d'essayer Ansible. Sans agent, vous n'avez besoin que de python sur l'hôte distant, très simple à configurer, de fichiers yaml, de modèles Jinja.
https://github.com/ansible/ansible-examples/tree/master/wordpress-nginx
Voyons voir, ce n'est pas toujours uniquement pour les sites WordPress, et ... haha peut-être Ansible clique sur volao, mais je préfère savoir exactement comment tout fonctionne sur le serveur, même si je dois passer 1 minute à créer de nouvelles chaussettes et un nouveau VHost 😀
Avec Ansible vous automatisez tout, vous faites pratiquement tout ce que vous voulez, l'avantage de cette méthode est que vous encapsulez la pratique puis que vous l'exécutez à volonté, imaginez que vous avez un site très chargé et que vous souhaitez faire un équilibrage de charge entre les serveurs d'applications, ces doivent être configurés exactement de la même manière, vous ne pouvez pas sauter une étape ou faire quoi que ce soit de différent dans l'un d'entre eux, pouvez-vous imaginer faire la procédure étape par étape 4 fois? Avec Ansible, c'est aussi simple que d'ajouter le nom d'hôte au fichier d'inventaire et Voilá !!
http://www.ansible.com/how-ansible-works
Désolé pour le culte Ansible, mais c'est l'une de ces technologies que vous découvrez et vous voulez que tout le monde l'utilise maintenant car c'est tellement cool et pratique, c'est comme quand vous découvrez NGINX et que vous voulez que tous vos amis quittent Apache immédiatement.
https://speakerdeck.com/slok/ansible-all-the-things
Je suis sûr que mon message complète cela ...
http://blog.ngen.com.ar/configuracion-segura-de-un-webserver-con-nginx-php-fpm/
Je suis (ou étudie pour être) un développeur et avec NGIX j'ai eu beaucoup de problèmes lors de la configuration de nginx + php-fpm. Je sais que la distribution archlinux n'est pas la meilleure pour en faire un serveur, mais à chaque fois que je mettais à jour une version de ngix ou php, tout tombait toujours en panne alors j'ai abandonné la tentative lol ... Pour aujourd'hui, je reste avec le classique Apache + PHP mais je verrai si je contournerai à nouveau NGIX ... peut-être dans une machine virtuelle
La mentalité change un peu, nginx sert le contenu statique et sert de proxy inverse pour le php-fpm qui exécute le vrai PHP, vous devez commencer par parties et réaliser le déploiement étape par étape, cherchez un guide pour déployer le framework avec lequel vous travaillez, chacun a son détail par les noms du public, statique, ressources, etc ...
Faites à la communauté la grande faveur d'abandonner le mot "hostear", qui n'existe pas. Par Dieu, est-il si difficile de dire «hôte»?
Salutations, en suivant votre exemple, je voudrais savoir si un pool pourrait être créé uniquement pour le backen wordpress, c'est-à-dire pour le wp-admin créant un nouveau socket pour les connexions entrantes au backend
location / wp-admin {
root /var/www/yoursite.com/wp-admin;
index index.php index.html index.htm;
emplacement ~ ^ / wp-admin /(.+. php) $ {
try_files $ uri = 404;
root /var/www/yoursite.com/wp-admin;
inclure / 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/;
}
}