Cambiar propietario de archivos: restaura permisos correctos tras un hackeo
Cuando analizó un sitio web comprometido, una de las primeras cosas que reviso es la propiedad de los archivos y directorios. En mi experiencia, los hackers casi siempre dejan rastros evidentes: archivos creados por el usuario www-data, root o incluso propietarios fantasma que no debería existir en tu servidor. Restaurar los permisos correctos es crítico para evitar reinfecciones y asegurar que tu sitio funciona bajo la identidad de usuario correcta.
En este artículo te explicaré cómo identificar propietarios incorrectos, las herramientas que necesitas y los pasos concretos para restaurar tu WordPress o PrestaShop a un estado seguro.
¿Por qué los hackers cambian propietarios de archivos?
Cuando un atacante obtiene acceso a tu servidor (a través de un plugin desactualizado, una contraseña débil o una inyección SQL), lo primero que intenta es ganar persistencia. Cambiar la propiedad de los archivos es una técnica común porque:
- Evasión de detección: si tu servidor está configurado para que WordPress sea propiedad de tu usuario FTP/SFTP, un archivo de propietario www-data destaca y es un indicador de compromiso.
- Acceso permanente: un webshell con propietario www-data sigue siendo ejecutable incluso después de que cambies tu contraseña FTP.
- Dificulta la limpieza: algunos administradores inexpertos no notan que los permisos están mal y el malware persiste silenciosamente.
- Bloqueo de acceso: en algunos casos, el hacker cambia la propiedad a un usuario de máquina inexistente, bloqueándote incluso a ti.
He visto casos donde un cliente no podía eliminar archivos mediante FTP porque la propiedad había sido transferida a nobody o a un usuario fantasma. Fue una situación frustrante que podría haberse evitado con auditorías regulares.
Identificar propietarios y permisos incorrectos
Conectar por SSH y revisar la estructura
Si tienes acceso SSH a tu servidor (y lo recomiendo siempre), el primer paso es conectar y listar los archivos con información de propiedad:
ls -la /ruta/a/tu/wordpress
La salida te mostrará algo como:
-rw-r--r-- 1 usuario grupo 1024 Jan 15 10:30 index.php
Las partes clave son: usuario (owner) y grupo (group). En una instalación correcta de WordPress en un servidor compartido, debería ser algo como:
- Usuario propietario: tu usuario FTP (ej: miseñoweb, usuario1, etc.) o www-data si estás en un servidor dedicado con PHP-FPM bien configurado.
- Grupo: www-data, www, httpd o similar (el usuario web del servidor).
Si ves propietarios raros como root, nobody, mysql o usuarios que no reconoces, es un indicador de compromiso.
Automatizar la detección con find
En lugar de revisar archivo por archivo, puedo usar find para detectar anomalías:
find /ruta/a/wordpress -not -user miusuario -not -user www-data -type f
Este comando lista todos los archivos que NO son propiedad de tu usuario FTP ni de www-data. Si aparecen archivos, tienes un problema.
Restaurar propietarios correctos en WordPress
Opción 1: Cambiar propietario a tu usuario FTP (servidores compartidos)
En hosting compartido, lo habitual es que los archivos sean propiedad de tu usuario FTP:
chown -R miusuario:www-data /ruta/a/wordpress
Reemplaza miusuario con tu usuario real. El parámetro -R (recursivo) cambia todos los archivos y carpetas dentro del directorio.
Nota importante: el grupo debe seguir siendo www-data para que el servidor web pueda leer los archivos. No cambies el grupo a tu usuario.
Opción 2: Cambiar propietario a www-data (servidores dedicados con PHP-FPM)
Si usas un servidor dedicado con PHP-FPM correctamente configurado, el propietario debe ser www-data en todos los archivos:
chown -R www-data:www-data /ruta/a/wordpress
Esta es la configuración más segura en servidores modernos porque el proceso PHP se ejecuta como www-data, evitando escaladas de privilegios.
Restaurar permisos numéricos (CHMOD)
Una vez hayas corregido el propietario, es hora de los permisos. Los permisos correctos en WordPress son:
- Directorios: 755 (rwxr-xr-x) – el propietario lee, escribe y ejecuta; otros solo leen y ejecutan.
- Archivos PHP y datos: 644 (rw-r–r–) – el propietario lee y escribe; otros solo leen.
- wp-config.php: 600 (rw——-) – solo el propietario puede acceder.
- carpeta /uploads: 755 en la carpeta, 644 en archivos dentro.
Para establecer estos permisos desde SSH:
find /ruta/a/wordpress -type d -exec chmod 755 {} ;
find /ruta/a/wordpress -type f -exec chmod 644 {} ;
chmod 600 /ruta/a/wordpress/wp-config.php
Esto es clave: si los permisos son demasiado permisivos (777 o 666), cualquiera en el servidor puede modificar tus archivos. He encontrado backdoors en sitios que tenían permisos 777 en directorios completos.
Restaurar permisos en PrestaShop
PrestaShop es similar, pero con algunas particularidades. La estructura correcta es:
- Directorios: 755
- Archivos: 644
- config/settings.inc.php: 644 (en algunos casos 600)
- carpeta /upload: 755 con archivos 644
El propietario debe seguir la misma lógica que WordPress: tu usuario FTP en hosting compartido, www-data en dedicado.
chown -R miusuario:www-data /ruta/a/prestashop
find /ruta/a/prestashop -type d -exec chmod 755 {} ;
find /ruta/a/prestashop -type f -exec chmod 644 {} ;
Casos especiales: detectar y eliminar webshells
Después de cambiar propietarios, es posible que haya webshells o backdoors ocultos. Buscar archivos con propietarios sospechosos es un indicador, pero también debes revisar:
Archivos PHP sospechosos
Muchos hackers suben archivos con nombres inocentes (shell.php, admin.php, update.php) en directorios menos obvios como wp-content/uploads, plugins desactivados o themes sin usar.
find /ruta/a/wordpress -name "*.php" -type f -newer /ruta/a/wordpress/index.php
Este comando lista archivos PHP más nuevos que index.php, lo que puede indicar qué se subió tras el hackeo.
Archivos con permisos anómalo
find /ruta/a/wordpress -perm /111 -type f -name "*.php"
Esto busca archivos PHP ejecutables por el propietario, grupo u otros. Un archivo PHP nunca debería ser ejecutable en el sistema de archivos (el servidor web se encarga de ejecutarlo).
Verificar cambios con Wordfence CLI o MalCare
Después de restaurar permisos, te recomiendo usar herramientas especializadas para confirmar que no hay malware residual:
- Wordfence CLI: escanea archivos WordPress en busca de cambios respecto a versiones oficiales. Es gratuito y muy potente.
- MalCare: detección automática de webshells y malware incluso si no coincide con firmas conocidas.
- WP-CLI: con comandos personalizados para revisar integridad de plugins y temas.
La combinación de cambio de propietarios + análisis de malware es tu mejor defensa. No hagas uno sin el otro.
Implementar protecciones adicionales tras la restauración
Deshabilitar edición de archivos
Una vez hayas limpiado el sitio, evita que nadie (incluso atacantes con acceso al panel admin) pueda editar archivos PHP:
En wp-config.php, añade:
define('DISALLOW_FILE_EDIT', true);
Esto desactiva el editor de archivos en el panel de WordPress, reduciendo la superficie de ataque significativamente.
Proteger wp-config.php con .htaccess
En el directorio raíz de WordPress, crea o edita .htaccess:
<Files wp-config.php>
order allow,deny
deny from all
</Files>
Esto previene acceso directo al archivo de configuración, incluso si se coloca una inyección.
Cambiar prefijo de tablas de base de datos
Si el hacker accedió a la base de datos, también debería cambiar el prefijo (por defecto wp_):
define('DB_PREFIX', 'wnq42_');
Esto complica los ataques de inyección SQL dirigidos a tablas específicas. Requiere cierto trabajo de migración, pero vale la pena en sitios críticos.
Auditoría post-hackeo: la lista de verificación
Cuando finalices la restauración de propietarios, verifica:
- Todos los archivos tienen propietario correcto (tu usuario o www-data, según configuración).
- Todos los directorios tienen permisos 755, archivos 644, excepto wp-config.php en 600.
- No hay archivos PHP sospechosos en directorios de upload o temas desactivados.
- Escaneo antimalware con Wordfence CLI o MalCare sin detecciones.
- Cambio de contraseñas de FTP, SSH, base de datos y panel admin.
- Actualización de todos los plugins, temas y WordPress al último parche.
- Revisión de logs de servidor en /var/log/apache2 o /var/log/nginx para actividad sospechosa.
En mi experiencia, los sitios que no completan esta lista suelen reinfectarse en 48-72 horas. El cambio de propietarios es solo el primer paso.
Herramientas recomendadas para automatizar todo esto
WP-CLI permite automatizar cambios de permisos en WordPress sin escribir comandos complejos:
wp user list
wp plugin list
wp theme verify-checksums
Con scripts personalizados, puedes combinar chown, chmod y escaneos de integridad en una sola ejecución.
Si no tienes acceso SSH, algunas empresas de hosting permiten cambiar propietarios a través del panel de control (cPanel, Plesk, etc.). Contacta con soporte si no ves la opción.
¿Cuándo llamar a un profesional?
Si después de cambiar propietarios:
- Siguen apareciendo archivos sospechosos nuevos.
- El sitio se ralentiza o muestra errores inexplicables.
- Las redirecciones no cesan tras limpiar.
- No tienes acceso SSH y tu proveedor no te ayuda.
Es momento de buscar ayuda profesional. En ManuelFolgar.com realizamos limpiezas completas de malware, auditorías de seguridad profundas y hardening de servidores. Contacta conmigo para una evaluación sin compromiso.
Solicita una auditoría de seguridad profesional en ManuelFolgar.com
Referencias técnicas y fuentes de autoridad
Para profundizar en estos conceptos, te recomiendo estos recursos oficiales:
- OWASP (Open Web Application Security Project) – guías sobre permisos de archivos y prevención de compromiso.
- WordPress.org – Documentación oficial sobre permisos de archivos
- INCIBE (Instituto Nacional de Ciberseguridad) – recursos españoles sobre seguridad web.
- CISA (Cybersecurity and Infrastructure Security Agency) – alertas sobre vulnerabilidades web comunes.