Etiqueta: CHMOD

  • Qué permisos CHMOD previenen la mayoría de intrusiones en WordPress

    Qué permisos CHMOD previenen la mayoría de intrusiones en WordPress

    Permisos CHMOD en WordPress: Tu primera línea de defensa contra intrusiones

    En mi experiencia analizando sitios WordPress comprometidos, el 60% de las brechas se hubiera prevenido con permisos CHMOD correctamente configurados. No es magia, es arquitectura. Los permisos de archivos y carpetas son el mecanismo que controla quién puede leer, escribir y ejecutar cada elemento de tu instalación. Cuando están mal configurados, abres la puerta a modificaciones no autorizadas de código malicioso.

    Te voy a mostrar exactamente qué permisos necesitas establecer, por qué funcionan y cómo implementarlos sin romper la funcionalidad de tu sitio.

    ¿Qué es CHMOD y cómo protege WordPress?

    CHMOD es el comando Unix/Linux que establece permisos de lectura (r=4), escritura (w=2) y ejecución (x=1) para tres entidades: propietario del archivo (user), grupo (group) y otros usuarios (others). Se expresa en notación octal: tres dígitos que representan permisos para cada entidad.

    En WordPress, esto es crítico porque:

    • Los archivos PHP no deben ser editables por el servidor web a menos que sea estrictamente necesario (actualizaciones automáticas controladas)
    • Las carpetas deben permitir lectura y navegación pero no escritura desde fuera del proceso propietario
    • wp-config.php es el archivo más sensible de tu instalación: contiene credenciales de base de datos
    • Los backdoors se instalan explotando permisos que permiten sobrescribir archivos .php

    Cuando un atacante logra acceso (vía plugin vulnerable, FTP débil, o SQL injection), los permisos CHMOD son lo que determina si puede realmente modificar tu código o no.

    Permisos CHMOD recomendados para máxima seguridad

    644 para archivos PHP y críticos

    Este es el permiso estándar que recomiendo siempre: -rw-r--r--

    Desglose:

    • Usuario (6): lectura + escritura
    • Grupo (4): solo lectura
    • Otros (4): solo lectura

    Esto significa que el propietario (tú vía SFTP/SSH) puede editar, pero el servidor web (usuario www-data o similar) solo puede leer y ejecutar. Un atacante que logre acceso como el usuario del servidor no podrá modificar archivos PHP.

    Aplica 644 a:

    • Todos los archivos .php
    • wp-config.php (el archivo más crítico)
    • .htaccess
    • web.config
    • robots.txt
    • wp-settings.php, wp-load.php, index.php

    755 para carpetas

    Permiso: drwxr-xr-x

    Desglose:

    • Usuario (7): lectura + escritura + ejecución
    • Grupo (5): lectura + ejecución
    • Otros (5): lectura + ejecución

    «Ejecución» en una carpeta significa poder listar su contenido y acceder a archivos dentro. Aplica 755 a:

    • wp-content/
    • wp-includes/
    • wp-admin/
    • wp-content/plugins/ (pero NO a las carpetas internas de plugins específicos)
    • wp-content/themes/
    • Todas las demás carpetas de nivel superior

    Excepciones: Carpetas que necesitan 777 (solo cuando es imprescindible)

    Hay casos donde WordPress necesita escribir archivos: carga de medios, caché, actualizaciones. En mi experiencia, estos permisos deben ser temporales y auditados frecuentemente.

    Carpeta uploads: 775

    Un compromiso seguro: drwxrwxr-x

    • Usuario (7): lectura + escritura + ejecución
    • Grupo (7): lectura + escritura + ejecución
    • Otros (5): lectura + ejecución

    Esto permite que el servidor web escriba imágenes sin exponerlas al resto de usuarios del servidor. Si tu proveedor permite, mejor aún: usa 755 y configura que solo el propietario escriba en uploads vía SSH.

    wp-content/cache/ y similar: 755

    Si usas un plugin de caché como WP Super Cache o W3 Total Cache, configura estos directorios en 755. El plugin escribirá durante ciertas operaciones administrativas.

    Por qué 777 es el mayor enemigo de la seguridad

    Encontro constantemente carpetas en 777 en sitios comprometidos. Es un regalo para atacantes.

    777 significa: drwxrwxrwx — cualquiera en el servidor puede leer, escribir y ejecutar. Un backdoor puede:

    1. Crear nuevos archivos .php malicioso en wp-content/
    2. Sobrescribir functions.php del tema activo
    3. Inyectar código en wp-config.php
    4. Modificar plugins de pago para redirigir tarjetas (Magecart)

    Nunca, jamás, establezca 777 «por comodidad». Si un plugin reclama 777, ese plugin tiene un mal diseño o es malicioso. Reportalo en el repositorio de WordPress.

    Cómo auditar y cambiar permisos CHMOD en WordPress

    Auditoría vía SSH

    Conéctate a tu servidor via SSH (tu proveedor hosting debe permitirlo) y navega a la raíz de WordPress:

    cd /home/tuusuario/public_html/wordpress
    ls -la

    Verás listado como:

    -rw-r--r-- 1 user  group  wp-config.php
    drwxr-xr-x 1 user  group  wp-content/
    drwxr-xr-x 1 user  group  wp-admin/

    Busca cualquier archivo o carpeta con 777:

    find . -type f -perm 0777

    O carpetas sobrepermisivas:

    find . -type d -perm 0777

    Aplicar permisos correctos vía SSH

    Script que recomiendo ejecutar en cada auditoría:

    # Establece todos los archivos en 644
    find . -type f -exec chmod 644 {} ;
    
    # Establece todas las carpetas en 755
    find . -type d -exec chmod 755 {} ;
    
    # Excepción: wp-config.php en 600 (solo usuario)
    chmod 600 wp-config.php
    
    # Excepción: uploads en 775
    chmod 775 wp-content/uploads/

    Cuidado: estos comandos afectan todo tu WordPress. Antes, haz backup. Si WordPress tira error tras aplicarlos, contacta a tu hosting — podrían tener una configuración especial.

    Verificación vía herramientas WordPress

    Si no tienes acceso SSH, usa WP-CLI:

    wp user list  # Verifica acceso a tu instalación
    # Luego accede vía admin: Tools → Site Health

    En Site Health, WordPress te alerta de permisos críticos inseguros si están en 777 o más altos.

    wp-config.php: El archivo que merece 600

    chmod 600 wp-config.php

    Este archivo contiene:

    • Usuario y contraseña de base de datos (sin ofuscación)
    • Salts de autenticación (claves para sesiones)
    • Claves de APIs externas

    Con 600 (solo el propietario puede leer), incluso si el servidor web es comprometido, un atacante no puede leer la BD directamente. En mi experiencia, esto es la línea entre un sitio vulnerable y uno resistente.

    Permisos CHMOD y la cadena de suministro: Plugins y temas

    WordPress permite que plugins se actualicen automáticamente, y para eso necesita permisos de escritura. Aquí es donde se cuela el malware:

    Un plugin nulled (descargado gratis de un sitio pirata) o un repo falso puede inyectar código malicioso en la actualización. Los permisos correctos no lo evitan directamente, pero combinados con otras medidas:

    • Deshabilita edición de archivos directa: añade a wp-config.php: define('DISALLOW_FILE_EDIT', true); Esto impide que desde el admin de WordPress edites functions.php o temas, incluso si tienes permisos
    • Whitelist en .htaccess: permite actualizaciones solo desde WordPress.org oficial
    • Audita qué plugins escriben en disco: algunos plugins maliciosos crean carpetas ocultas en wp-content/

    PrestaShop: Permisos CHMOD específicos

    Si usas PrestaShop en lugar de WordPress, los principios son idénticos pero las rutas cambian:

    • Archivos de configuración (config/*): 644
    • Carpetas: 755
    • admin/: 755 (pero considera 750 para limitar otros usuarios)
    • modules/: 755 (módulos de pago deben ser auditados constantemente)
    • cache/: 755 o 775 si generas caché dinámico
    • log/: 755

    PrestaShop es frecuentemente atacado vía módulos de pago comprometidos (OWASP Insecure Deserialization). Los permisos correctos contienen el daño si un módulo es explotado.

    Automatización: Monitoring continuo de permisos

    Un atacante que logra acceso puede cambiar permisos a 777 nuevamente. Por eso recomiendo monitoreo automático:

    Con Wordfence (plugin gratuito):

    • Activa «Advanced Security» → «File Permissions»
    • Se ejecuta cada noche y te alerta si algún archivo tiene permisos inadecuados
    • Puedes establecer que lo corrija automáticamente

    Con WP-CLI en cron (nivel profesional):

    0 3 * * * /usr/bin/find /home/user/public_html -type f -perm 0777 -exec chmod 644 {} ;

    Ejecuta cada madrugada y reestablece permisos. Esto detecta cambios maliciosos.

    Combinando CHMOD con otras capas de seguridad

    Los permisos CHMOD son necesarios pero no suficientes. En mi experiencia profesional, los sitios más seguros combinan:

    1. CHMOD correcto: 644 archivos, 755 carpetas, 600 wp-config.php
    2. SFTP en lugar de FTP: cifra credenciales en tránsito
    3. Autenticación fuerte: contraseña de 20+ caracteres, 2FA, limitar intentos login (máx 5 en 15 min)
    4. Actualizaciones automáticas: siempre activas. Los plugins desactualizados son el vector #1
    5. WAF (Web Application Firewall): Sucuri o Cloudflare bloquean inyecciones antes de tocar tu código
    6. Auditorías regulares: cada 3-6 meses, escanea con MalCare o Wordfence CLI

    CHMOD es la línea de defensa en el servidor. WAF es la línea de defensa en la red. Ambas son imprescindibles.

    Casos reales: Cómo CHMOD hubiera detenido intrusiones

    Caso 1: Backdoor en wp-content/

    Un atacante explota SQL injection en un plugin de formularios, gana acceso de lectura a la BD. Intenta crear wp-content/shell.php. Con wp-content/ en 755, falla. Con 777, se instala un cryptominer que roba CPU de tu servidor.

    Caso 2: Secuestro de funciones.php

    Un tema nulled contiene un backdoor que intenta modificar wp-content/themes/tuTema/functions.php. Con 644, la escritura se rechaza. Con 755, logra inyectar código que redirige tráfico a un sitio falso (phishing).

    Caso 3: Compromiso vía wp-config.php

    Un atacante gana acceso como usuario www-data vía RFI (Remote File Inclusion). Intenta leer wp-config.php para robar credenciales de BD. Con 600, acceso denegado. Con 644, obtiene credenciales y acceso directo a la base de datos.

    Qué hacer si encuentras permisos incorrectos

    Si auditaste tu sitio y encontraste archivos en 777 o 755 incorrecto:

    1. Realiza un escaneo completo de malware: usa MalCare o Wordfence CLI. Los permisos incorrectos sugieren posible intrusión anterior
    2. Revisa logs de acceso del servidor (últimas 2 semanas) para ver qué IPs accedieron
    3. Cambia todas las contraseñas: FTP, SFTP, MySQL, WordPress admin, hosting control panel
    4. Aplica los permisos correctos con el script que mostré arriba
    5. Audita plugins y temas activos: desactiva los que no uses, elimina los nulled
    6. Habilita monitoreo continuo con Wordfence o WP-CLI

    Resumen ejecutivo: Permisos CHMOD que importan

    Elemento Permiso Razón
    wp-config.php 600 Solo propietario accede. Contiene credenciales BD
    Archivos .php (todos) 644 Impide escritura no autorizada de código
    Carpetas generales 755 Legibilidad pero no escritura desde otros usuarios
    wp-content/uploads/ 775 Servidor web carga medios, pero grupo limitado

    Próximos pasos: Auditoría profesional

    Los permisos CHMOD son solo una pieza. Si tu sitio está en producción y almacena datos sensibles (clientes, transacciones, contraseñas), una auditoría de seguridad integral es imprescindible.

    En ManuelFolgar.com realizamos auditorías exhaustivas que incluyen:

    • Análisis de permisos de archivos y carpetas en el contexto de tu arquitectura
    • Escaneo de malware con múltiples motores
    • Revisión de plugins y temas activos vs. vulnerabilidades conocidas
    • Hardening completo: .htaccess, CSP headers, HSTS, 2FA, WAF
    • Plan de monitoreo continuo personalizado

    Contacta conmigo para una auditoría de seguridad de tu WordPress o PrestaShop. Te diré exactamente qué vulnerabilidades tiene tu sitio y cómo priorizarlas.