php - seguido - reparar wordpress
Corregir permisos de archivos para WordPress (15)
He echado un vistazo here pero no encontré ningún detalle sobre los mejores permisos de archivos. También eché un vistazo a algunas de las preguntas de WordPress aquí, pero cualquiera que sugiera que 777 obviamente necesita una pequeña lección sobre seguridad.
En resumen mi pregunta es esta. ¿Qué permisos debo tener para lo siguiente:
- Carpeta raíz que almacena todo el contenido de WordPress.
- wp-admin
- contenido wp
- wp-incluye
y luego todos los archivos en cada una de esas carpetas?
Basándome en todas las lecturas y agonías en mis propios sitios y después de haber sido pirateado, he creado la lista anterior que incluye permisos para un complemento de seguridad para Wordpress llamado Wordfence. (No afiliado a ella)
En nuestro ejemplo, la raíz del documento de wordpress es /var/www/html/example.com/public_html
Abra los permisos para que www-data pueda escribir en la raíz del documento de la siguiente manera:
cd /var/www/html/example.com
sudo chown -R www-data:www-data public_html/
Ahora, desde el panel de control de su sitio, como administrador puede realizar actualizaciones.
Sitio seguro después de que se completen las actualizaciones siguiendo estos pasos:
sudo chown -R wp-user:wp-user public_html/
El comando anterior cambia los permisos de todo en la instalación de wordpress al usuario FTP de wordpress.
cd public_html/wp-content
sudo chown -R www-data:wp-user wflogs
sudo chown -R www-data:wp-user uploads
El comando anterior garantiza que el complemento de seguridad Wordfence tenga acceso a sus registros. El directorio de cargas también se puede escribir en www-data.
cd plugins
sudo chown -R www-data:wp-user wordfence/
El comando anterior también garantiza que el complemento de seguridad haya requerido acceso de lectura y escritura para su funcionamiento adecuado.
Directorio y permisos de archivos
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} /;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} /;
Establezca los permisos para wp-config.php en 640 para que solo wp-user pueda leer este archivo y nadie más. Los permisos de 440 no me funcionaron con la propiedad del archivo anterior.
sudo chmod 640 wp-config.php
Las actualizaciones automáticas de WordPress con SSH funcionaban bien con PHP5, pero se rompieron con PHP7.0 debido a problemas con el paquete php7.0-ssh2 con Ubuntu 16.04 y no pude encontrar la forma de instalar la versión correcta y hacer que funcione. Afortunadamente, un complemento muy confiable llamado ssh-sftp-updater-support (gratuito) hace posible las actualizaciones automáticas utilizando SFTP sin necesidad de libssh2. Por lo tanto, los permisos anteriores nunca tienen que aflojarse, excepto en casos excepcionales, según sea necesario.
Comandos:
chown www-data:www-data -R *
find . -type d -exec chmod 755 {} /;
find . -type f -exec chmod 644 {} /;
Donde ftp-user es qué usuario está utilizando para cargar los archivos
chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content
Creo que se recomiendan las siguientes reglas para un sitio de wordpress predeterminado:
Para las carpetas dentro de wp-content, configure 0755 permisos:
chmod -R 0755 plugins
chmod -R 0755 subidas
actualización de chmod -R 0755
Deje que el usuario de apache sea el propietario de los directorios anteriores de wp-content:
chown apache subidas
actualización de chown apache
Chown Apache Plugins
Cuando configure WP, usted (el servidor web) puede necesitar acceso de escritura a los archivos. Así que los derechos de acceso deben ser sueltos.
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--
Después de la configuración, debe ajustar los derechos de acceso ; de acuerdo con Hardening WordPress, todos los archivos, excepto el contenido de wp, deben poder escribirse solo en su cuenta de usuario. El contenido de wp debe poder ser escrito por www-data también.
chown <username>:<username> -R * # Let your useraccount be owner
chown www-data:www-data wp-content # Let apache be owner of wp-content
Quizás quieras cambiar los contenidos en wp-content más adelante. En este caso podrías
- Cambiar temporalmente al usuario a www-data con
su
, - dé a wp-content group 775 el acceso de escritura y únase al grupo www-data o
- otorgue a su usuario los derechos de acceso a la carpeta mediante ACLs .
Hagas lo que hagas, asegúrate de que los archivos tengan permisos rw para www-data .
Dar acceso completo a todos los archivos wp al usuario de www-data
(que en este caso es el usuario del servidor web) puede ser peligroso. Así que más bien NO hagas esto:
chown www-data:www-data -R *
Sin embargo, puede ser útil en el momento de instalar o actualizar WordPress y sus complementos. Pero cuando termine, ya no es una buena idea mantener los archivos wp que son propiedad del servidor web.
Básicamente, permite que el servidor web coloque o sobrescriba cualquier archivo en su sitio web. Esto significa que existe la posibilidad de controlar su sitio si alguien administra el uso del servidor web (o un agujero de seguridad en algunas secuencias de comandos .php) para colocar algunos archivos en su sitio web.
Para proteger su sitio contra un ataque de este tipo, debe hacer lo siguiente:
Todos los archivos deben ser propiedad de su cuenta de usuario y deben poder ser escritos por usted. Cualquier archivo que necesite acceso de escritura desde WordPress debe poder ser editado por el servidor web, si su configuración de alojamiento lo requiere, eso puede significar que esos archivos deben ser propiedad de un grupo de la cuenta de usuario utilizada por el proceso del servidor web.
/
El directorio raíz de WordPress: todos los archivos deben poder escribirse solo por su cuenta de usuario, excepto .htaccess si desea que WordPress genere automáticamente reglas de reescritura para usted.
/wp-admin/
El área de administración de WordPress: todos los archivos deben poder escribirse solo por su cuenta de usuario.
/wp-includes/
La mayor parte de la lógica de la aplicación de WordPress: todos los archivos deben poder escribirse solo por su cuenta de usuario.
/wp-content/
Contenido suministrado por el usuario: destinado a ser escribible por su cuenta de usuario y el proceso del servidor web.
Dentro de
/wp-content/
encontrarás:
/wp-content/themes/
Archivos temáticos. Si desea utilizar el editor de temas incorporado, todos los archivos deben poder escribirse mediante el proceso del servidor web. Si no desea utilizar el editor de temas incorporado, todos los archivos solo pueden ser escritos por su cuenta de usuario.
/wp-content/plugins/
Archivos de complemento: todos los archivos deben poder ser escritos solo por su cuenta de usuario.
Otros directorios que puedan estar presentes con
/wp-content/
deben documentarse por cualquier complemento o tema que los requiera. Los permisos pueden variar.
Fuente e información adicional: http://codex.wordpress.org/Hardening_WordPress
Definir en el archivo wp_config.
/var/www/html/Your-Project-File/wp-config.php
define( ''FS_METHOD'', ''direct'' );
chown - cambia la propiedad de los archivos / dirs. Es decir. el propietario del archivo / dir cambia al especificado, pero no modifica los permisos.
sudo chown -R www-data:www-data /var/www
En realidad, depende de los complementos que planea usar, ya que algunos complementan el documento raíz de wordpress. pero generalmente recomiendo algo como esto para el directorio de wordpress.
Esto asignará la "raíz" (o lo que sea el usuario que esté utilizando) como usuario en cada archivo / carpeta, R significa recursivo, por lo que simplemente no se detiene en la carpeta "html". Si no usó R, entonces solo se aplica al directorio "html".
sudo chown -R root:www-data /var/www/html
Esto establecerá el propietario / grupo de "wp-content" en "www-data" y, por lo tanto, permitirá que el servidor web instale los complementos a través del panel de administración.
chown -R www-data:www-data /var/www/html/wp-content
Esto establecerá el permiso de cada archivo en la carpeta "html" (incluidos los archivos en los subdirectorios) a 644, por lo que las personas externas no pueden ejecutar ningún archivo, modificar ningún archivo, el grupo no puede ejecutar ningún archivo, modificar ningún archivo y solo el usuario puede modificar / leer archivos, pero aún así el usuario no puede ejecutar ningún archivo. Esto es importante porque evita cualquier tipo de ejecución en la carpeta "html", ya que el propietario de la carpeta html y todas las demás carpetas excepto la carpeta wp-content son "root" (o su usuario), los datos de www pueden t modificar cualquier archivo fuera de la carpeta wp-content, por lo que incluso si hay alguna vulnerabilidad en el servidor web, y si alguien accedió al sitio sin autorización, no puede eliminar el sitio principal, excepto los complementos.
sudo find /var/www/html -type f -exec chmod 644 {} +
Esto restringirá el permiso de acceso a "wp-config.php" al usuario / grupo con rw-r ----- estos permisos.
chmod 640 /var/www/html/wp-config.php
Y si un complemento o actualización se quejó de que no se puede actualizar, entonces acceda a SSH y use este comando, y otorgue el permiso temporal a "www-data" (servidor web) para actualizar / instalar a través del panel de administración, y luego revertir volver a la "raíz" o su usuario una vez que se complete.
chown -R www-data /var/www/html
Y en Nginx (mismo procedimiento para el apache) para proteger la carpeta wp-admin del acceso no autorizado y el sondeo. apache2-utils es necesario para cifrar la contraseña, incluso si tiene nginx instalado, omita c si planea agregar más usuarios al mismo archivo.
sudo apt-get install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd userName
Ahora visita este lugar
/etc/nginx/sites-available/
Use estos códigos para proteger la carpeta "wp-admin" con una contraseña, ahora le pedirá la contraseña / nombre de usuario si intentó acceder a la "wp-admin". aviso, aquí usa el archivo ".htpasswd" que contiene la contraseña cifrada.
location ^~ /wp-admin {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
index index.php index.html index.htm;
}
Ahora reinicie el nginx.
sudo /etc/init.d/nginx restart
Establecí permisos para:
# 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 {} /;
En mi caso, creé un usuario específico para WordPress que es diferente del usuario predeterminado de apache que impide el acceso desde la web a los archivos que pertenecen a ese usuario.
Luego le da permiso al usuario de Apache para manejar la carpeta de carga y, finalmente, establecer suficientes permisos para archivos y carpetas.
Editado
Si está utilizando W3C Total Cache, debería hacer lo siguiente también:
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
Entonces funcionará!
Editado
Después de un tiempo desarrollando sitios de WordPress, recomendaría diferentes permisos de archivo por entorno:
En producción, no daría acceso a los usuarios para modificar el sistema de archivos, solo les permitiré cargar recursos y dar acceso a algunas carpetas específicas de complementos para realizar copias de seguridad, etc. Pero administrar proyectos en Git y usar las claves de implementación en el servidor, no es bueno actualizar los complementos en la preparación ni la producción. Os dejo aquí la configuración del archivo de producción:
# Set uploads folder user and group to www-data
chown www-data:www-data -R wp-content/uploads/
www-data: www-data = apache o nginx usuario y grupo
La puesta en escena compartirá los mismos permisos de producción que debería ser un clon de la misma.
Finalmente, el entorno de desarrollo tendrá acceso a complementos de actualización, traducciones, todo ...
# 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 = apache o nginx usuario y agrupe a su usuario: root-group = su usuario actual y el grupo raíz
Estos permisos le darán acceso para desarrollar bajo themes
y your-plugin
carpeta de your-plugin
sin pedir permiso. El resto del contenido será propiedad del usuario Apache o Nginx para permitir que WP administre el sistema de archivos.
Antes de crear un git repo primero ejecuta estos comandos:
# Set all directories permissions to 755
find . -type d -exec chmod 755 {} /;
# Set all files permissions to 644
find . -type f -exec chmod 644 {} /;
Lo mejor es leer la documentación de WordPress en este codex.wordpress.org/Changing_File_Permissions
- Todos los archivos deben pertenecer a la cuenta del usuario real, no a la cuenta de usuario utilizada para el proceso httpd
- La propiedad del grupo es irrelevante, a menos que haya requisitos de grupo específicos para la verificación de permisos del proceso del servidor web. Este no suele ser el caso.
- Todos los directorios deben ser 755 o 750.
- Todos los archivos deben ser 644 o 640. Excepción: wp-config.php debe ser 440 o 400 para evitar que otros usuarios en el servidor lo lean.
- Ningún directorio debería recibir 777, ni siquiera subir directorios. Dado que el proceso php se ejecuta como propietario de los archivos, obtiene los permisos de los propietarios y puede escribir incluso en un directorio 755.
Los permisos correctos para el archivo son 644 Los permisos correctos para la carpeta son 755
Para cambiar los permisos, use el terminal y los siguientes comandos.
find foldername -type d -exec chmod 755 {} /;
find foldername -type f -exec chmod 644 {} /;
755 para carpetas y 644 para archivos.
No puedo decirle si esto es correcto o no, pero estoy usando una imagen de Bitnami en Google Compute App Engine. Tengo problemas con los complementos y la migración, y después de desordenar aún más los permisos de chmod''ing, encontré estas tres líneas que resolvieron todos mis problemas. No estoy seguro si es la forma correcta pero funcionó para mí.
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 {} /;
Para OS X usa este comando:
sudo chown -R www:www /www/folder_name
Para aquellos que tienen su carpeta raíz de wordpress bajo su carpeta de inicio:
** Ubuntu / apache
- Agregue su usuario al grupo de datos www:
CRÉDITO Otorgar permisos de escritura al grupo de datos www
Quieres llamar a usermod
en tu usuario. Entonces eso sería:
sudo usermod -aG www-data yourUserName
** Suponiendo que existe un grupo de www-data
Compruebe que su usuario está en el grupo de
www-data
:groups yourUserName
Deberías conseguir algo como:
youUserName : youUserGroupName www-data
** youUserGroupName es usualmente similar a tu nombre de usuario
Cambie recursivamente la propiedad de grupo de la carpeta wp-content manteniendo la propiedad de su usuario
chown yourUserName:www-data -R youWebSiteFolder/wp-content/*
Cambie el directorio a youWebSiteFolder / wp-content /
cd youWebSiteFolder/wp-content
Cambie recursivamente los permisos de grupo de las carpetas y subcarpetas para habilitar los permisos de escritura:
find . -type d -exec chmod -R 775 {} /;
** el modo `/ home / yourUserName / youWebSiteFolder / wp-content / ''cambió de 0755 (rwxr-x-x) a 0775 (rwxrwxr-x)
Cambie recursivamente los permisos de grupo de los archivos y subarchivos para habilitar los permisos de escritura:
find . -type f -exec chmod -R 664 {} /;
El resultado debe verse algo como:
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
Equivalente a:
chmod -R ug + rw foldername
Los permisos serán como 664 para archivos o 775 para directorios.
Sal si alguien encuentra el error ''could not create directory''
al actualizar un complemento, haga:
server@user:~/domainame.com$ sudo chown username:www-data -R wp-content
cuando estás en la raíz de tu dominio.
Suponiendo que: wp-config.php
tiene
Credenciales FTP en LocalHost
define(''FS_METHOD'',''direct'');
Para asegurarse absolutamente de que su sitio web es seguro y de que está usando los permisos correctos para sus carpetas, use un complemento de seguridad como estos:
https://en-ca.wordpress.org/plugins/all-in-one-wp-security-and-firewall/
https://en-ca.wordpress.org/plugins/wordfence/
Estos complementos escanearán su instalación de Wordpress y le notificarán sobre cualquier problema potencial. Estos también le advertirán sobre cualquier permiso de carpeta inseguro. Además de eso, estos complementos le recomendarán qué permisos deben asignarse a las carpetas.
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