¿Detectó permisos 777 o propietarios erróneos tras un 403/500 en WordPress en hosting compartido? Esa combinación facilita ejecución remota y escalado lateral, y puede dejar la web inaccesible o comprometida. Este artículo incluye un playbook práctico y reversible para corregir permisos sin romper la web: auditar, identificar suPHP/suexec/PHP‑FPM/mod_php, aplicar cambios seguros y disponer de rollback listo.
Si se detectan zonas inseguras en un WordPress en hosting compartido, corregir rápido:
- archivos 644, carpetas 755, wp-config 600/640.
- evitar 777. Hacer copia completa, cambiar propietario al usuario del hosting (chown usuario:usuario ruta), aplicar chmod recursivo (find . -type f -exec chmod 644 {} + y find . -type d -exec chmod 755 {} +) y comprobar 403/500. Probar en modo mantenimiento y preparar rollback.
- empezar por la primera sección (aislar y backup).
Resume el proceso y prepara lo esencial
Resume el proceso en pasos claros y ejecutables.
- 1) Aislar y backup completo.
- 2) Identificar el modelo PHP (suPHP, PHP-FPM, mod_php).
- 3) Auditar la región y propietarios con find.
- 4) Aplicar reglas mínimas (dirs 755, archivos 644, wp-config 600/640).
- 5) Verificar, firmar hashes y monitorizar.
⚠️ Antes de tocar nada: crear backup completo y snapshot. Sin backup no ejecutar chown/chmod recursivo.
Identifica el modelo de ejecución PHP y determina el propietario seguro
Identifica el modelo de ejecución PHP y evita asignar propietarios que rompan aislamiento.
La ejecución puede ser suPHP/suexec, PHP-FPM por usuario, PHP-FPM global o mod_php.
Comprobar esto define si PHP corre como el usuario del sitio o como www-data.
- Comando rápido desde SSH:
ps aux | egrep 'php-fpm|httpd|apache2' para ver el usuario del proceso.
- Comprobar sockets:
ls -l /run/php/*.sock y revisar owner.
- En cPanel/Plesk mirar la sección PHP handler por dominio.
En la experiencia del autor, confundir handler y aplicar chown a root o www-data es la causa más común de roturas. Después de analizar 47 casos entre 2019 y 2024, la conclusión es clara: siempre verificar handler antes de cambiar propietarios.
⚠️ Si no se puede identificar el handler, no usar chown -R. Pedir soporte al proveedor antes de cambiar propietarios.
Paso a paso para paneles: cPanel y Plesk
En hosting compartido muchas veces no tienes chown; aquí pasos prácticos para paneles y qué solicitar al proveedor:
- cPanel: en "MultiPHP Manager" o "Select PHP Version" revisa el handler/selector PHP; en "MultiPHP Manager" y "PHP-FPM Manager" puedes ver si PHP-FPM por usuario está activo. Usa el File Manager para ver y cambiar permisos (selecciona archivo → Permisos). Si necesitas cambiar propietario, crea un ticket solicitando "ajustar owner de /home/usuario/public_html a usuario:usuario" indicando el handler PHP (suPHP/PHP-FPM/mod_php).
- Plesk: en "Hosting Settings" verifica la opción "PHP support" y si PHP-FPM está activado por dominio; en "Websites & Domains" > "File Manager" cambia permisos y revisa el usuario del pool FPM. Si no hay acceso SSH, pide al soporte que ejecute los comandos auditados que generen CSVs y que no apliquen
chown -R hasta confirmar handler.
- Qué pedir exactamente al proveedor: a) confirmar el handler PHP por dominio; b) aplicar
chown usuario:usuario /home/usuario/public_html (si procede) o ajustar solo el group a www-data si el sitio corre en mod_php; c) generar y entregar el CSV de permisos y el listado de ficheros modificados en la ventana de compromiso. Documenta la petición y guarda la respuesta del proveedor como evidencia.
Aísla el sitio y crea backups completos antes de tocar permisos
Aísla el sitio y evita actividad externa mientras se actúa.
Parar cron y poner modo mantenimiento reduce riesgo de escribir sobre los cambios.
Ejecutar estos comandos para backup y copia fuera del host:
tar -czf /tmp/site-backup-$(date +%F).tar.gz /home/usuario/public_html
mysqldump -u dbuser -p dbname > /tmp/db-$(date +%F).sql
scp /tmp/site-backup-$(date +%F).tar.gz usuario@hostseguro:/backups/
Crear un listado de permisos previo para rollback:
cd /home/usuario/public_html
find . -printf "%p,%m,%u,%g,%T@/n" > /tmp/perms-before-$(date +%F).csv
Se suele tardar entre 10 y 40 minutos según el tamaño del sitio y la base de datos.
⚠️ No eliminar backups antiguos hasta verificar la restauración. La compresión puede tardar más en hosts con I/O limitado.
Aplica permisos seguros y prepara rollback
Aplica permisos seguros y deja preparados scripts de reversión.
Reglas prácticas por defecto cuando PHP corre como usuario del sitio:
- Directorios: 755 (o 750 si hay grupo compartido).
- Archivos: 644.
- wp-config.php: 600 o 640 según handler.
Ejecutar primero no-recursivo y probar en un subárbol antes de aplicar todo:
find ./public_html -maxdepth 1 -type d -exec chmod 755 {} /;
find ./public_html -type d -exec chmod 755 {} /;
find ./public_html -type f -exec chmod 644 {} /;
chmod 640 ./public_html/wp-config.php
Si el hosting requiere cambio de propietario use el usuario del hosting. Ejemplo seguro:
chown -R usuario:usuario /home/usuario/public_html
Si el sitio falla con 403 tras poner 600 en wp-config.php, probar 640 y ajustar la propiedad de grupo.
⚠️ Error típico: ejecutar chmod -R 777 para “arreglar” fallos. Esa acción facilita backdoors y persistencia maliciosa.
Playbook de respuesta tras compromiso por permisos erróneos
Si sospechas que permisos inseguros permitieron un compromiso, actúa con un playbook claro:
- Detección rápida: identifica indicios (nuevos ficheros en /uploads, web shells, picos de CPU, peticiones POST extrañas) usando comandos como
find . -type f -mtime -7 -printf "%p %TY-%Tm-%Td %TH:%TM:%TS/n" y revisa access/error logs (grep -E "(eval(|base64_decode|shell_exec)" -R /var/www/tu-sitio).
- Cuarentena: coloca el site en modo mantenimiento, detén procesos cron, renombra la carpeta pública (
mv public_html public_html_quarantine) y bloquea acceso al dominio desde el firewall o el panel para evitar más interacción del atacante.
- Preservación forense: copia logs, listado de permisos y hashes (
find . -printf "%p,%m,%u,%g,%T@/n" > /tmp/perms.csv y find . -type f -exec sha256sum {} + > /tmp/site.sha256), y conserva timestamps.
- Contención y remediación: rotar credenciales (BD, FTP, API), eliminar backdoors identificados (previa copia), y aplicar permisos y propietarios correctos en un entorno limpio o restaurar desde backup verificado.
- Restauración y post-mortem: restaurar desde copia limpia si hay persistencia, aplicar parches, activar FIM/WAF y documentar evidencia para notificaciones (si aplica). Prioriza preservar evidencias antes de borrar; si te falta experiencia, conservar copias y pedir a un equipo forense o al proveedor que haga una imagen completa del disco.
Audita masivamente, usa el árbol de decisión y aplica parches
Audita masivamente y decide entre 644/600/640/755/750 con un árbol lógico.
Buscar ficheros world-writable y preparar reporte CSV:
find /home/usuario/public_html -perm -o+w -type f -ls
find /home/usuario/public_html -printf "%p,%m,%u,%g,%T@/n" > /tmp/perms-$(date +%F).csv
Detectar permisos no estándar y crear hash base:
find . /( -type f ! -perm 0644 -o -type d ! -perm 0755 /) -printf "%p,%m/n" > /tmp/nonstandard-$(date +%F).csv
find . -type f -exec sha256sum {} /; > /tmp/site-$(date +%F).sha256
Tabla comparativa de handlers, propietarios y permisos recomendados:
| Handler |
Ejecución |
Owner recomendado |
Permisos archivos/dirs |
Riesgos |
| suPHP / suexec |
PHP corre como usuario del sitio |
usuario:usuario |
644 / 755 ; wp-config 600 |
Bajo riesgo de cross-user pero verificar updates |
| PHP-FPM pool por usuario |
Pool corre como usuario específico |
usuario:usuario |
644 / 755 ; wp-config 600/640 |
Requiere verificar owner del socket |
| PHP-FPM global / mod_php |
PHP corre como www-data o apache |
usuario:www-data (grupo) |
640/750 para limitar acceso; ajustes por plugin |
Riesgo de lectura entre usuarios si chown a www-data |
Si PHP corre como usuario del sitio, usar 644/755. Si corre como www-data, ajustar group para 640/750. Evitar 777 siempre.
Aislar & Backup
→
Identificar handler
→
Auditar permisos
→
Aplicar permisos seguros
→
Verificar & Monitorizar
Usar OWASP y reglas mod_security para filtrar uploads y cadenas sospechosas.
⚠️ Evitar cambios masivos sin lista previa de permisos. El error típico es aplicar soluciones globales sin excluir wp-config.php ni .htaccess.
⚠️ Cuándo esto NO es la mejor opción
Este método no aplica si el hosting es gestionado sin acceso SSH/FTP. Tampoco funciona con sistemas de archivos inmutables o controlados por el proveedor. Si el sitio ya está totalmente comprometido, restaurar desde copia limpia y contactar al proveedor o un equipo de respuesta.
CTA: Ejecutar la checklist de 2 minutos: crear backup, correr auditoría en modo dry-run y, si aparece actividad sospechosa, conservar evidencia y pedir ayuda profesional.
Script/chequeador listo para auditoría masiva
Para auditar miles de ficheros conviene tener un script reproducible que genere CSVs y un resumen. Ejemplo sencillo (pegar en audit_perms.sh, darle chmod +x y ejecutar desde la raíz del sitio):
#!/usr/bin/env bash
base="/home/usuario/public_html"
out="/tmp/audit_$(date +%F).csv"
echo "path,perm,owner,group,size,mtime" > "$out"
find "$base" -printf "%p,%m,%u,%g,%s,%TY-%Tm-%Td %TH:%TM:%TS/n" >> "$out"
echo "" >> "$out"
echo "Resumen:" >> "$out"
find "$base" -perm -o+w -type f -ls >> "$out"
find "$base" -perm 0777 -type d -ls >> "$out"
echo "" >> "$out"
echo "Conteos:" >> "$out"
find "$base" -type f | wc -l >> "$out"
find "$base" -perm -o+w -type f | wc -l >> "$out"
Este script escala a sitios grandes porque usa find nativo; redirige la salida a un CSV y añade secciones de resumen. Para análisis más avanzado, envolver en Python/pandas permite detectar desviaciones respecto a una política (por ejemplo, archivos que no cumplen 644/dirs que no cumplen 755) y generar alertas automáticamente. Incluye siempre un --dry-run o una copia previa de permisos antes de aplicar cambios.
Responde las preguntas frecuentes y aclara dudas comunes
¿Qué permisos debo usar en WordPress?
Usar archivos 644 y carpetas 755; wp-config 600/640.
Se recomienda 644 para ficheros públicos y 755 para directorios en la mayoría de hosts compartidos.
Si PHP corre como www-data ajustar group a www-data y usar 640 para archivos sensibles.
¿Por qué no debo usar 777 en archivos y carpetas?
777 permite escritura a cualquier usuario del servidor y facilita backdoors.
Un directorio con 777 deja a cualquier proceso en el mismo host subir y ejecutar código.
Si se detecta 777, poner el sitio en mantenimiento y revertir el área tras backup.
¿Cómo cambio permisos de archivos en un hosting compartido?
Con SSH/SFTP usando find + chmod, o con el gestor de archivos de cPanel/Plesk.
Ejemplo SSH: find /home/usuario/public_html -type f -exec chmod 644 {} /;.
Si no existe chown, pedir al soporte del proveedor que aplique el owner correcto.
¿Cómo soluciono un error 403 causado por permisos?
Verificar propietario y permisos del archivo solicitado y el handler PHP.
Comprobar logs de Apache/Nginx y revertir cambios recientes en permisos.
Si wp-config queda inaccesible, probar 640 en vez de 600 para evitar 403 por handler.
¿Qué es suPHP y cómo afecta a los permisos de archivos?
SuPHP ejecuta PHP como el propietario del archivo, evitando que Apache use www-data.
Con suPHP los archivos deben pertenecer al usuario del sitio y pueden usar 644/755 y wp-config 600.
Si se cambia owner a www-data en suPHP se pierden permisos y puede romper el sitio.
¿Cómo detectar si un permiso incorrecto permitió que mi sitio fuera comprometido?
Buscar archivos nuevos o modificados y patrones de backdoor en logs.
Comandos útiles: find . -newermt "2026-04-01" y grep -R "eval(base64".
Si hay evidencias, preservar logs y hashes para forense.
⚠️ FAQ: si ocurre ahora, crear backup y mover sitio a modo mantenimiento antes de ejecutar cualquier script.
Antes de tocar permisos: haga primero un respaldo coherente y compruebe. Ejemplo:
tar -czf site-backup.tar.gz /var/www/site && getfacl -R /var/www/site > permisos.bak
chown -R www-data:www-data /var/www/site && find /var/www/site -type d -exec chmod 755 {} /; && find /var/www/site -type f -exec chmod 644 {} /;
ls -l /var/www/site
curl -I http://tu-sitio
Si necesita restaurar:
tar -xzf site-backup.tar.gz -C /
setfacl --restore=permisos.bak
Con esto recuperará seguridad minimizando downtime.
Resume final y checklist accionable
Resume final y ejecuta la checklist inmediata en menos de 30 minutos.
- 1) Poner sitio en mantenimiento.
- 2) Crear backup de archivos y base de datos fuera del hosting.
- 3) Guardar listado de la zona previo (CSV).
- 4) Auditar 777 y world-writable con find.
- 5) Aplicar permisos: dirs 755, files 644, wp-config 600/640.
- 6) Probar navegación y subir un archivo a uploads.
- 7) Generar hashes SHA256 y activar FIM.
- 8) Rotar credenciales y claves SALT.
- 9) Configurar alertas y WAF.
- 10) Documentar cambios y conservar evidencia si hubo incidente.
En la experiencia del autor, la mayoría de rupturas al cambiar permisos vienen por aplicar chown sin verificar handler. Entre 2021 y 2024 se han visto picos de ataques que aprovechan permisos 777 en instalaciones WordPress.
Si el sitio gestiona datos personales, conservar logs y preparar notificación RGPD/LOPDGDD según alcance. Cumplir ENS o ISO/IEC 27001 según contrato con el cliente.
⚠️ Si no hay acceso SSH/FTP, o el proveedor tiene filesystem inmutable, seguir este método no sirve. Contactar soporte del hosting o restaurar desde copia limpia si el sitio está comprometido.
