Autorisations de fichier correctes pour WordPress
J'ai jeté un œil sur ici mais je n'ai trouvé aucun détail sur les meilleures autorisations de fichiers. J'ai aussi jeté un coup d'œil à certaines des questions du formulaire de WordPress à propos de ici aussi , mais quiconque suggère 777 a évidemment besoin d'une petite leçon de sécurité.
En bref, ma question est la suivante. Quelles autorisations dois-je avoir pour les éléments suivants:
- dossier racine contenant tout le contenu WordPress
- wp-admin
- wp-content
- wp-comprend
et puis tous les fichiers dans chacun de ces dossiers?
Lorsque vous installez WP, vous (le serveur Web) avez peut-être besoin d'un accès en écriture aux fichiers. Ainsi, les droits d'accès devront peut-être être perdus.
chown www-data:www-data -R * # Let Apache be owner
find . -type d -exec chmod 755 {} \; # Change directory permissions rwxr-xr-x
find . -type f -exec chmod 644 {} \; # Change file permissions rw-r--r--
Après l'installation, vous devriez resserrer les droits d'accès , conformément à durcissement WordPress = tous les fichiers, à l'exception de wp-content, ne doivent être accessibles en écriture que par votre compte d'utilisateur. wp-content doit être accessible en écriture pour www-data également.
chown <username>:<username> -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let Apache be owner of wp-content
Peut-être que vous souhaitez modifier le contenu de wp-content ultérieurement. Dans ce cas, vous pourriez
- changer temporairement l'utilisateur www-data avec
su, - donnez un accès en écriture au groupe wp-content 775 et rejoignez le groupe www-data ou
- donnez à votre utilisateur les droits d'accès au dossier à l'aide de ACL .
Quoi que vous fassiez, assurez-vous que les fichiers disposent des autorisations rw pour www-data .
Donner un accès complet à tous les fichiers wp à l'utilisateur www-data (qui est dans ce cas l'utilisateur du serveur Web) peut être dangereux. Donc plutôt PAS faites ceci:
chown www-data:www-data -R *
Cela peut toutefois être utile au moment où vous installez ou mettez à niveau WordPress et ses plug-ins. Mais lorsque vous avez terminé, ce n’est plus une bonne idée de conserver les fichiers wp appartenant au serveur Web.
Il permet essentiellement au serveur Web de mettre ou d’écraser n’importe quel fichier de votre site Web. Cela signifie qu'il est possible de reprendre votre site si quelqu'un parvient à utiliser le serveur Web (ou un trou de sécurité dans un script .php) pour mettre des fichiers sur votre site Web.
Pour protéger votre site contre une telle attaque, vous devez:
Tous les fichiers doivent appartenir à votre compte d'utilisateur et être inscriptibles par vous. Tout fichier nécessitant un accès en écriture à partir de WordPress doit être accessible en écriture pour le serveur Web. Si votre configuration d'hébergement le requiert, cela peut signifier que ces fichiers doivent appartenir à un groupe appartenant au compte d'utilisateur utilisé par le serveur Web. processus.
/Le répertoire racine WordPress: tous les fichiers ne doivent être accessibles en écriture que par votre compte d'utilisateur, à l'exception de .htaccess si vous souhaitez que WordPress génère automatiquement des règles de réécriture.
/wp-admin/La zone d'administration WordPress: tous les fichiers ne doivent être accessibles en écriture que par votre compte utilisateur.
/wp-includes/La majeure partie de la logique de l’application WordPress: tous les fichiers ne doivent être accessibles en écriture que par votre compte utilisateur.
/wp-content/Contenu fourni par l'utilisateur: conçu pour être accessible en écriture pour votre compte utilisateur et le processus du serveur Web.
Dans
/wp-content/, vous trouverez:
/wp-content/themes/Fichiers de thème. Si vous souhaitez utiliser l'éditeur de thème intégré, tous les fichiers doivent être accessibles en écriture par le processus du serveur Web. Si vous ne souhaitez pas utiliser l'éditeur de thème intégré, tous les fichiers ne peuvent être écrits que par votre compte d'utilisateur.
/wp-content/plugins/Fichiers plug-in: tous les fichiers ne doivent être accessibles en écriture que par votre compte utilisateur.
Les autres répertoires pouvant être présents avec
/wp-content/devraient être documentés par le plug-in ou le thème qui les requiert. Les autorisations peuvent varier.
Source et informations supplémentaires: http://codex.wordpress.org/Hardening_WordPress
Pour ceux qui ont leur dossier racine wordpress sous leur dossier personnel:
** Ubuntu/Apache
- Ajoutez votre utilisateur au groupe www-data:
CREDIT Octroi d'autorisations d'écriture sur le groupe www-data
Vous voulez appeler usermod sur votre utilisateur. Donc ce serait:
_Sudo usermod -aG www-data yourUserName
_** En supposant que _www-data_ groupe existe
Vérifiez que votre utilisateur est dans le groupe _
www-data_:_
groups yourUserName_
Vous devriez obtenir quelque chose comme:
_youUserName : youUserGroupName www-data
_** youUserGroupName est généralement similaire à votre nom d'utilisateur
Changer récursivement la propriété de groupe du dossier wp-content en conservant la propriété de l'utilisateur
_
chown yourUserName:www-data -R youWebSiteFolder/wp-content/*_Changer de répertoire en youWebSiteFolder/wp-content /
_
cd youWebSiteFolder/wp-content_Modifiez de manière récursive les autorisations de groupe des dossiers et sous-dossiers pour activer les autorisations en écriture:
_
find . -type d -exec chmod -R 775 {} \;_
** Le mode "/ home/votreNomUtilisateur/youWebSiteFolder/wp-content /" est passé de 0755 (rwxr-xr-x) à 0775 (rwxrwxr-x).
Modifiez de manière récursive les autorisations de groupe des fichiers et des sous-fichiers pour activer les autorisations d'écriture:
_
find . -type f -exec chmod -R 664 {} \;_
Le résultat devrait ressembler à quelque chose comme:
_WAS:
-rw-r--r-- 1 yourUserName www-data 7192 Oct 4 00:03 filename.html
CHANGED TO:
-rw-rw-r-- 1 yourUserName www-data 7192 Oct 4 00:03 filename.html
_Équivalent à:
chmod -R ug + rw nom d'utilisateur
Les autorisations seront comme 664 pour les fichiers ou 775 pour les répertoires.
P.s. si quelqu'un rencontre une erreur _'could not create directory'_ lors de la mise à jour d'un plugin, faites:
_server@user:~/domainame.com$ Sudo chown username:www-data -R wp-content_
lorsque vous êtes à la racine de votre domaine.
En supposant que: wp-config.php a
informations d'identification FTP sur LocalHostdefine('FS_METHOD','direct');
Il est préférable de lire la documentation wordpress sur ce sujet https://codex.wordpress.org/Changing_File_Permissions
- Tous les fichiers doivent appartenir au compte de l'utilisateur réel, pas au compte d'utilisateur utilisé pour le processus httpd.
- La propriété de groupe n'est pas pertinente, sauf si des exigences de groupe spécifiques sont définies pour la vérification des autorisations de processus du serveur Web. Ce n'est généralement pas le cas.
- Tous les répertoires doivent être 755 ou 750.
- Tous les fichiers doivent être au format 644 ou 640. Exception: wp-config.php doit avoir la valeur 440 ou 400 pour empêcher les autres utilisateurs du serveur de le lire.
- Aucun répertoire ne devrait jamais recevoir 777, même les répertoires de téléchargement. Comme le processus php est exécuté en tant que propriétaire des fichiers, il obtient les autorisations de ces propriétaires et peut même écrire dans un répertoire 755.
Je mets les permissions sur:
# Set all files and directories user and group to wp-user
chown wp-user:wp-user -R *
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
Dans mon cas, j'ai créé un utilisateur spécifique pour WordPress, différent de l'utilisateur par défaut d'Apache, qui empêche l'accès à partir du Web aux fichiers appartenant à cet utilisateur.
Ensuite, il donne la permission à l'utilisateur Apache de gérer le dossier de téléchargement et de définir enfin des autorisations suffisamment sécurisées pour les fichiers et les dossiers.
ÉDITÉ
Si vous utilisez le cache total du W3C, vous devriez faire la prochaine aussi:
chmod 777 wp-content/w3tc-config
chmod 777 wp-content/cache
rm -rf wp-content/cache/config
rm -rf wp-content/cache/object
rm -rf wp-content/cache/db
rm -rf wp-content/cache/minify
rm -rf wp-content/cache/page_enhanced
Alors ça va marcher!
ÉDITÉ
Après un certain temps en développant WordPress sites, je vous recommanderais différentes autorisations sur les fichiers par environnement:
En production, je ne donnerais pas accès aux utilisateurs pour modifier le système de fichiers, je leur permettrai seulement de télécharger des ressources et de donner accès à des dossiers spécifiques de plugins pour faire des sauvegardes, etc. Mais gérer des projets sous Git et utiliser des clés de déploiement sur le serveur, ce ne sont pas de bons plugins de mise à jour lors de la mise en scène ou de la production. Je laisse ici la configuration du fichier de production:
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/
www-data: www-data = utilisateur et groupe Apache ou nginx
Staging partagera les mêmes autorisations de production car il devrait en être un clone.
Enfin, l’environnement de développement aura accès à la mise à jour des plugins, des traductions, etc.
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/
# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/themes
# Set uploads folder user and group to www-data
chown your-user:root-group -R wp-content/plugins/your-plugin
www-data: www-data = utilisateur et groupe Apache ou nginx votre-utilisateur: groupe-racine = votre utilisateur actuel et le groupe racine
Ces autorisations vous permettront d’accéder au développement dans les dossiers themes et your-plugin sans demander d’autorisation. Le reste du contenu appartiendra à l'utilisateur Apache ou Nginx pour permettre à WP de gérer le système de fichiers.
Avant de créer un repo git, lancez d'abord ces commandes:
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
Les autorisations correctes pour le fichier sont 644 Les autorisations correctes pour le dossier sont 755
Pour modifier les autorisations, utilisez les commandes terminal et suivantes.
find foldername -type d -exec chmod 755 {} \;
find foldername -type f -exec chmod 644 {} \;
755 pour les dossiers et 644 pour les fichiers.
Cela dépend en fait des plugins que vous prévoyez d'utiliser car certains plugins changent le document racine de wordpress. mais en général, je recommande quelque chose comme ceci pour le répertoire wordpress.
Cela assignera la "racine" (ou quel que soit l'utilisateur que vous utilisez) en tant qu'utilisateur dans chaque fichier/dossier, R signifie récursif, afin qu'il ne s'arrête pas au dossier "html". si vous n'avez pas utilisé R, il ne s'applique qu'au répertoire "html".
Sudo chown -R root:www-data /var/www/html
Cela définira le propriétaire/groupe de "wp-content" sur "www-data", permettant ainsi au serveur Web d'installer les plugins via le panneau d'administration.
chown -R www-data:www-data /var/www/html/wp-content
Cela définira la permission de chaque fichier du dossier "html" (y compris les fichiers des sous-répertoires) sur 644, afin que les personnes extérieures ne puissent exécuter aucun fichier, modifier aucun fichier, aucun groupe ne puisse exécuter aucun fichier, modifier aucun fichier et uniquement. l'utilisateur est autorisé à modifier/lire des fichiers, mais même l'utilisateur ne peut exécuter aucun fichier. Ceci est important car cela empêche toute exécution dans le dossier "html", également parce que le propriétaire du dossier html et tous les autres dossiers sauf le dossier wp-content sont "root" (ou votre utilisateur), le fichier www-data peut " Ne modifiez aucun fichier en dehors du dossier wp-content. Ainsi, même en cas de vulnérabilité du serveur Web et si une personne accède au site de manière non autorisée, elle ne peut pas supprimer le site principal, à l'exception des plug-ins.
Sudo find /var/www/html -type f -exec chmod 644 {} +
Ceci limitera la permission d'accès à "wp-config.php" à l'utilisateur/groupe avec rw-r ----- ces permissions.
chmod 640 /var/www/html/wp-config.php
Et si un plugin ou une mise à jour s'est plaint, il ne peut pas mettre à jour, puis accédez à SSH et utilisez cette commande, puis accordez le droit temporaire à "www-data" (serveur Web) de mettre à jour/installer via le panneau d'administration, puis de revenir en arrière. Retour à la "racine" ou votre utilisateur une fois qu'il est terminé.
chown -R www-data /var/www/html
Et dans Nginx (même procédure que pour Apache), protégez le dossier wp-admin contre les accès non autorisés et les vérifications. Apache2-utils est requis pour chiffrer le mot de passe même si vous avez installé nginx, omettez c si vous prévoyez d'ajouter plus d'utilisateurs au même fichier.
Sudo apt-get install Apache2-utils
Sudo htpasswd -c /etc/nginx/.htpasswd userName
Maintenant, visitez ce lieu
/etc/nginx/sites-available/
Utilisez ces codes pour protéger le dossier "wp-admin" avec un mot de passe. Il demandera maintenant le mot de passe/nom d'utilisateur si vous avez essayé d'accéder au "wp-admin". Notez que vous utilisez ici le fichier ".htpasswd" qui contient le mot de passe crypté.
location ^~ /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
index index.php index.html index.htm;
}
Maintenant, redémarrez le nginx.
Sudo /etc/init.d/nginx restart
Je pense que les règles ci-dessous sont recommandées pour un site par défaut wordpress:
Pour les dossiers de wp-content, définissez les autorisations 0755:
plugins chmod -R 0755
chmod -R 0755 uploads
mise à niveau de chmod -R 0755
Laissez l'utilisateur Apache être le propriétaire des répertoires ci-dessus de wp-content:
téléchargements d'Apache chown
mise à niveau Apache chown
plugins Apache chown
chown -Rv www-data:www-data
chmod -Rv 0755 wp-includes
chmod -Rv 0755 wp-admin/js
chmod -Rv 0755 wp-content/themes
chmod -Rv 0755 wp-content/plugins
chmod -Rv 0755 wp-admin
chmod -Rv 0755 wp-content
chmod -v 0644 wp-config.php
chmod -v 0644 wp-admin/index.php
chmod -v 0644 .htaccess
Commandes:
chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
Où ftp-user est quel utilisateur vous utilisez pour télécharger les fichiers
chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content
Pour vous assurer absolument que votre site Web est sécurisé et que vous utilisez les autorisations appropriées pour vos dossiers, utilisez un plugin de sécurité comme celui-ci:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
Ces plugins analyseront votre installation Wordpress et vous informeront de tout problème potentiel. Cela vous avertira également de toute autorisation de dossier non sécurisé. En plus de cela, ces plugins vous recommanderont quelles autorisations devraient être attribuées aux dossiers.
Pour OS X, utilisez cette commande:
Sudo chown -R www:www /www/folder_name
Définir dans le fichier wp_config.
/var/www/html/Your-Project-File/wp-config.php
define( 'FS_METHOD', 'direct' );
chown - change la propriété des fichiers/répertoires. C'est à dire. le propriétaire du fichier/répertoire change en celui spécifié, mais il ne modifie pas les permissions.
Sudo chown -R www-data:www-data /var/www
Je ne peux pas vous dire si cela est correct ou non, mais j'utilise une image Bitnami sur Google Compute App Engine. J'ai des problèmes avec les plugins et la migration, et après avoir gâché les choses en modifiant les autorisations, j'ai trouvé ces trois lignes qui ont résolu tous mes problèmes. Je ne sais pas si c'est la bonne façon mais cela a fonctionné pour moi.
Sudo chown -R bitnami:daemon /opt/bitnami/apps/wordpress/htdocs/
Sudo find /opt/bitnami/apps/wordpress/htdocs/ -type f -exec chmod 664 {} \;
Sudo find /opt/bitnami/apps/wordpress/htdocs/ -type d -exec chmod 775 {} \;
Sur la base de toutes les lectures et de mes angoisses sur mes propres sites et après avoir été piraté, je viens avec la liste ci-dessus qui inclut les autorisations pour un plugin de sécurité pour Wordpress appelé Wordfence. (Non affilié à cela)
Dans notre exemple, la racine du document wordpress est /var/www/html/example.com/public_html.
Ouvrez les autorisations pour que www-data puisse écrire dans la racine du document comme suit:
cd /var/www/html/example.com
Sudo chown -R www-data:www-data public_html/
Maintenant, à partir du tableau de bord de votre site, en tant qu'administrateur, vous pouvez effectuer des mises à jour.
Secure Site après la fin des mises à jour en procédant comme suit:
Sudo chown -R wp-user:wp-user public_html/
La commande ci-dessus modifie les autorisations de tous les éléments de l'installation wordpress sur l'utilisateur wordpress FTP.
cd public_html/wp-content
Sudo chown -R www-data:wp-user wflogs
Sudo chown -R www-data:wp-user uploads
La commande ci-dessus garantit que le plug-in de sécurité Wordfence a accès à ses journaux. Le répertoire de téléchargement est également accessible en écriture sur www-data.
cd plugins
Sudo chown -R www-data:wp-user wordfence/
La commande ci-dessus garantit également que le plug-in de sécurité a requis un accès en lecture-écriture pour fonctionner correctement.
Autorisations de répertoire et de fichiers
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} \;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} \;
Définissez les autorisations pour wp-config.php sur 640 afin que seul l'utilisateur wp puisse lire ce fichier et personne d'autre. Les autorisations de 440 ne fonctionnaient pas pour moi avec la propriété de fichier ci-dessus.
Sudo chmod 640 wp-config.php
Les mises à jour automatiques de Wordpress utilisant SSH fonctionnaient correctement avec PHP5 mais rompaient avec PHP7.0 en raison de problèmes liés à php7.0-ssh2 associé à Ubuntu 16.04 et je ne trouvais pas comment installer la bonne version et la faire fonctionner. Heureusement, un plugin très fiable appelé ssh-sftp-updater-support (gratuit) permet les mises à jour automatiques à l'aide de SFTP sans avoir besoin de libssh2. Ainsi, les autorisations ci-dessus ne doivent jamais être libérées, sauf dans de rares cas, au besoin.