Permisos de archivos en WordPress: 644, 755 y propietario

Permisos de archivos en WordPress: el valor seguro en un párrafo

Los permisos de archivos recomendados para WordPress son 755 para los directorios, 644 para los archivos y un 640 o 600, más estricto, para wp-config.php. Nunca use 777. Ahora bien, estas cifras solo protegen si los archivos pertenecen al usuario correcto. Un 644 impecable sobre archivos de la cuenta equivocada rompe las subidas y las actualizaciones, o bien da al servidor web más poder del necesario. Por eso conviene leer la sección sobre el propietario antes de tocar ningún modo.

Propietario, grupo y otros: cómo leer 755 y 644

Ejecute ls -l en la raíz de WordPress y verá líneas como estas:

drwxr-xr-x  5 deploy www-data  4096 Oct 30 09:12 wp-content
-rw-r--r--  1 deploy www-data   405 Oct 30 09:12 index.php
-rw-r-----  1 deploy www-data  3214 Oct 30 09:12 wp-config.php

El primer carácter indica el tipo (d para directorio, - para archivo). Después vienen tres grupos de tres letras: uno para el propietario (deploy), otro para el grupo (www-data) y otro para todos los demás. r significa lectura, w escritura y x ejecución. Cada letra tiene un valor: r = 4, w = 2, x = 1. Si las suma por grupo obtiene el modo octal, de modo que rwxr-xr-x se convierte en 7-5-5.

En un directorio, x significa «se puede entrar». Sin ese bit, PHP no puede abrir los archivos de su interior, aunque sean legibles. Por eso los directorios necesitan 755 y los archivos les basta con 644. En una instalación normal de WordPress ningún archivo necesita el bit de ejecución.

El propietario importa tanto como el modo

Primero averigüe con qué usuario se ejecuta PHP. En un servidor propio, revise los procesos en marcha:

ps -eo user,comm | grep -E 'php-fpm|apache2|httpd' | sort | uniq

Con PHP-FPM, el proceso maestro se ejecuta como root y los procesos de trabajo, como el usuario del pool. Ese usuario se define en el archivo del pool, que en Debian y Ubuntu suele estar en /etc/php/<versión>/fpm/pool.d/:

grep -R -E '^(user|group) *=' /etc/php/*/fpm/pool.d/

La documentación de configuración de PHP-FPM describe estos parámetros. Con Apache y mod_php, PHP se ejecuta directamente como el usuario de Apache: www-data en Debian/Ubuntu y apache en los sistemas basados en RHEL. Entonces todos los sitios del servidor comparten una misma identidad. Un buen alojamiento compartido aísla los sitios: el PHP de cada cuenta se ejecuta con el usuario propio de esa cuenta. Si no puede ejecutar ps, mire Herramientas > Salud del sitio > Información > Permisos del sistema de archivos. Ahí se indica si WordPress puede escribir en su directorio principal, en wp-content, en uploads, en plugins y en temas.

Cuando sepa qué usuario ejecuta PHP, elija uno de los dos modelos de propiedad.

Modelo A: el usuario de PHP es propietario de todo. Es lo habitual en alojamientos compartidos con aislamiento, donde el usuario de su cuenta y el de PHP coinciden. Las actualizaciones desde el escritorio, la instalación de plugins y las subidas funcionan. El inconveniente es que cualquier código que se ejecute como PHP también puede reescribir todos los archivos, incluidos el núcleo, los plugins y wp-config.php.

Modelo B: un usuario de despliegue es propietario y PHP solo lee. Los archivos pertenecen a algo como deploy:www-data, con 755/644. PHP puede leerlo todo, pero solo escribe donde usted lo permita: wp-content/uploads y los directorios de caché. Las actualizaciones se hacen entonces con WP-CLI o SFTP como usuario de despliegue, no desde el escritorio. Esto limita los daños, pero da más trabajo. Si además quiere bloquear el escritorio de forma definitiva, consulte DISALLOW_FILE_MODS y sus contrapartidas.

El Modelo B explica un enigma frecuente: WordPress que pide credenciales FTP al pulsar «Actualizar». WordPress comprueba si los archivos que crearía tendrían el mismo propietario que los suyos. Si no es así, recurre a FTP. Forzar FS_METHOD a direct oculta el síntoma sin corregir la causa. Decida qué modelo quiere y configure el propietario en consecuencia.

Cómo restablecer los permisos de WordPress sin riesgo

Haga primero una copia de seguridad de archivos y base de datos. Después vaya a la raíz de WordPress y confirme que está en el lugar correcto:

cd /var/www/example.com/public
ls wp-config.php

Si ls no encuentra wp-config.php, deténgase. (Algunas configuraciones lo guardan un nivel por encima de la raíz web, así que revise su estructura.) Después restablezca los modos:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;

En sitios grandes, la variante con + es mucho más rápida porque pasa muchos archivos a cada llamada a chmod:

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +

Cambie el propietario solo en un servidor que controle. Para el Modelo B, sería así:

sudo chown -R deploy:www-data /var/www/example.com/public

El restablecimiento también aplana las excepciones que se describen más abajo, así que vuelva a aplicarlas de inmediato. Después compruebe el resultado con stat -c '%a %U:%G %n' wp-config.php wp-content/uploads, suba una imagen de prueba y cargue algunas páginas.

Excepciones: wp-config.php, uploads y .htaccess

wp-config.php contiene la contraseña de la base de datos, así que «otros» no debe tener ningún permiso. Use 600 si el usuario de PHP es el propietario del archivo (Modelo A). Use 640 si el propietario es un usuario de despliegue y PHP lo lee a través del grupo (Modelo B). Si pone 600 en el Modelo B, PHP no puede leer el archivo y el sitio deja de funcionar. Para las claves (salts), los ajustes de depuración y las copias de seguridad olvidadas, consulte el endurecimiento de wp-config.php.

wp-content/uploads y los directorios de caché deben ser escribibles por el usuario de PHP. En el Modelo B, haga que el usuario de PHP sea propietario de esos directorios o déjelos con el grupo de PHP como grupo propietario y permiso de escritura para el grupo (775 para directorios, 664 para archivos). Limite la escritura a esas rutas, no a todo wp-content.

En Apache, .htaccess es un caso especial. Si es escribible, WordPress actualiza las reglas de reescritura al guardar los enlaces permanentes, y los plugins de caché o de seguridad añaden sus propios bloques. Si no lo es, WordPress le muestra las reglas para que las pegue a mano. Un .htaccess de solo lectura le cuesta algo de comodidad. A cambio, el código que se ejecuta como PHP no puede añadirle una redirección ni una línea auto_prepend_file.

Por qué 777 no arregla nunca un error de subida

777 permite que cualquier cuenta y cualquier proceso del servidor escriban en el archivo o directorio. En un alojamiento compartido, eso puede incluir scripts comprometidos de otros clientes. Puede hacer desaparecer un error de subida, pero solo porque elimina la protección, no porque corrija la causa. Revise las causas reales en este orden:

1. Propietario incorrecto. El mensaje «Unable to create directory wp-content/uploads/… Is its parent directory writable by the server?» (o su equivalente en español) casi siempre significa que el usuario de PHP no es propietario de uploads o no puede escribir en él. Suele ocurrir tras una migración o una restauración hecha como root.
2. Disco o cuota llenos. Compruebe df -h en su propio servidor, o la cuota en el panel de su alojamiento.
3. Directorio temporal o límites de rutas. «Missing a temporary folder» apunta a upload_tmp_dir. Una restricción open_basedir que excluya la ruta temporal también puede bloquear las subidas.
4. Límites de tamaño. «The uploaded file exceeds the upload_max_filesize directive» significa que debe aumentar upload_max_filesize y post_max_size, o subir un archivo más pequeño.

En un alojamiento compartido, normalmente no puede ejecutar chown usted mismo. Pida a su proveedor que asigne a su cuenta el propietario correcto. Es una petición rutinaria.

De qué no protegen los permisos correctos

Los permisos limitan lo que puede hacer un usuario. No sirven de nada contra código que ya se ejecuta como ese usuario. Si un plugin vulnerable permite a un atacante ejecutar PHP, su código tiene los derechos del usuario de PHP. En el Modelo A, eso significa todo. En el Modelo B, sigue significando uploads, directorios de caché y cualquier otra cosa que haya dejado escribible. Por eso los atacantes prefieren uploads, como se explica en web shells en wp-content/uploads.

Restablecer los permisos tras un ataque tampoco elimina una puerta trasera. El archivo malicioso sigue ahí, solo que con modos ordenados. Siga primero un plan de eliminación de malware y corrija los permisos después, como parte del endurecimiento. Según el RGPD, unos permisos correctos pueden contar como una de las medidas técnicas que protegen la integridad y la confidencialidad de los datos personales (art. 32, EUR-Lex), pero solo funcionan dentro de un conjunto más amplio de medidas.

Revise los permisos con regularidad

Los permisos tienden a desviarse. Las causas habituales son las migraciones, las restauraciones de copias, los cambios de proveedor y un arreglo rápido con sudo. Ejecute estas dos comprobaciones desde la raíz de WordPress después de cada uno de esos eventos y, de todos modos, cada pocos meses:

find . -perm -o+w ! -type l
find . ! -user deploy

El primer comando lista todo lo que es escribible por cualquiera (se excluyen los enlaces simbólicos porque siempre aparecen como 777). El segundo lista los archivos que no pertenecen al propietario esperado. En el Modelo A, sustituya deploy por el usuario de PHP. Ambos deberían devolver una lista vacía, o solo rutas que usted sepa explicar. La guía de permisos de archivos de WordPress.org recoge la misma base desde el punto de vista del equipo del núcleo.

Para vigilar el conjunto, el plugin Security Audit & Compliance de secaudit.eu ejecuta comprobaciones de endurecimiento y configuración junto con la monitorización de la integridad de archivos, de modo que los archivos modificados o nuevos aparecen entre sus revisiones manuales → secaudit.eu

Preguntas frecuentes

¿Debe wp-config.php tener 400 o 440?

También funciona, siempre que PHP pueda seguir leyendo el archivo: 400 si PHP es el propietario y 440 si PHP lo lee a través del grupo. El inconveniente es que tendrá que volver a cambiar el modo para editar el archivo. Lo habitual, como término medio, es 600 o 640.

¿Es seguro 755/644 en un alojamiento compartido?

Sí, si el proveedor aísla las cuentas y su PHP se ejecuta con su propio usuario. Con 644, otras cuentas podrían en teoría leer sus archivos. Un aislamiento correcto lo impide, y por eso la configuración de su proveedor importa más que las cifras.

¿Debo restablecer los permisos después de cada actualización?

No. WordPress crea los archivos nuevos con modos razonables. Ejecute en su lugar las comprobaciones anteriores y restablezca solo si detectan problemas.