it-swarm-es.com

Corregir permisos de archivos para WordPress

He echado un vistazo a aquí pero no encontré ningún detalle sobre los mejores permisos de archivos. También eché un vistazo a algunas de las preguntas del formulario de WordPress sobre aquí también pero cualquiera que sugiera que 777 obviamente necesita una pequeña lección de seguridad.

En resumen mi pregunta es esta. Qué permisos debo tener para lo siguiente:

  1. carpeta raíz que almacena todo el contenido de WordPress.
  2. wp-admin
  3. contenido wp
  4. wp-incluye

y luego todos los archivos en cada una de esas carpetas?

345
John Crawford

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, debería apretar 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. wp-content 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

Tal vez quieras cambiar los contenidos en wp-content más adelante. En este caso podrías

  • cambie 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.

413
ManuelSchneid3r

Dar acceso completo a todos los archivos wp al usuario www-data (que en este caso es el usuario del servidor web) puede ser peligroso. Así que más bien hazNOhaz 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 ser escritos 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 proporcionado por el usuario: diseñado para que su cuenta de usuario y el proceso del servidor web puedan escribirlo.

Dentro de /wp-content/ encontrará:

/wp-content/themes/

Archivos de temas. 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 ser documentados por cualquier plugin o tema que los requiera. Los permisos pueden variar.

Fuente e información adicional: http://codex.wordpress.org/Hardening_WordPress

52
Kornel

Para aquellos que tienen su carpeta raíz de wordpress bajo su carpeta de inicio:

** Ubuntu/Apache

  1. Agregue su usuario al grupo de datos www:

CRÉDITO Concesión de 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 www-data group existe

  1. Compruebe que su usuario está en el grupo www-data:

    groups yourUserName

Deberías conseguir algo como:

youUserName : youUserGroupName www-data

** youUserGroupName es generalmente similar a tu nombre de usuario

  1. 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/*

  2. Cambie el directorio a youWebSiteFolder/wp-content /

    cd youWebSiteFolder/wp-content

  3. 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)

  1. 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.

PD. si alguien encuentra el error 'could not create directory' al actualizar un complemento, haga:
[email protected]:~/domainame.com$ Sudo chown username:www-data -R wp-content
cuando estás en la raíz de tu dominio.
Suponiendo:wp-config.phphas
Credenciales de FTP en LocalHost
define('FS_METHOD','direct');

23
Jadeye

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 de archivos y carpetas.

EDITADO

Si está utilizando W3C Total Cache, también debería hacer lo siguiente:

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 hacer copias de seguridad, etc. 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 = usuario y grupo de Apache o nginx

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 para actualizar complementos, 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 grupo your-user: root-group = su usuario actual y el grupo raíz

Estos permisos le darán acceso a desarrollar bajo las carpetas themes y 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 {} \;
15

Lo mejor es leer la documentación de WordPress en esta https://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.
  • A ningún directorio se le debe dar 777, incluso subir directorios. Dado que el proceso php se está ejecutando como propietario de los archivos, obtiene los permisos de los propietarios y puede escribir incluso en un directorio 755.
14
PodTech.io

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.

9
Kappa

En realidad, depende de los complementos que planea usar, ya que algunos modifican 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 tiene permiso para 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" para el 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 completa.

chown -R www-data /var/www/html

Y en Nginx (el mismo procedimiento para 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
7
Don Dilanga

Creo que se recomiendan las siguientes reglas para un sitio de wordpress predeterminado:

  • Para las carpetas dentro de wp-content, establezca 0755 permisos:

    chmod -R 0755 complementos

    chmod -R 0755 subidas

    Chmod -R 0755 mejora

  • Permita que el usuario de Apache sea el propietario de los directorios anteriores de wp-content:

    Chown Apache sube

    Actualización de Chache Apache

    Chown Apache plugins

7
shasi kanth
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
2
Grapehand

Comandos:

chown www-data:www-data -R *
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

Donde ftp-user es el usuario que está utilizando para cargar los archivos

chown -R ftp-user:www-data wp-content
chmod -R 775 wp-content
2
Iacob Vlad-George

Para OS X usa este comando:

Sudo chown -R www:www /www/folder_name
1
Abduhafiz

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
1
Harish Verma

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 de 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 {} \;
1
wayofthefuture

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.

1
user296526

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 él)

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 de 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 función adecuada.

Permisos de directorio y 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 hacerla funcionar. 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 raros, según sea necesario.

0
spinozarabel