Blindando wp-config.php y Archivos Críticos mediante .htaccess

Es sorprendente que, tras años de evolución, la arquitectura de muchos servidores siga permitiendo que archivos con información extremadamente sensible sean, al menos, consultables por el servidor web si no existe una directiva específica que lo prohíba. El archivo wp-config.php es la joya de la corona: un solo descuido aquí y el atacante tiene acceso total a tus tablas. Esta es una de esas herencias técnicas que WordPress y Apache arrastran por inercia, confiando en que el desarrollador sepa blindar la puerta trasera manualmente.

#¿Por qué .htaccess y no solo permisos de archivo?

A nivel de ingeniería, chirría que algunos desarrolladores confíen ciegamente en un CHMOD 400 o 440. Aunque los permisos locales son vitales, una regla en .htaccess actúa como un portero en la capa del servidor HTTP. Bloquea la petición de descarga directa del archivo incluso antes de que el motor de WordPress empiece a arrancar. No te obsesiones con el «Score» de los plugins de seguridad; lo que importa es que el servidor web devuelva un 403 Forbidden antes de soltar un solo byte del archivo de configuración.

#Protocolo de Blindaje de Archivos Sensibles

Vamos a implementar un bloqueo selectivo que cubra los puntos más críticos. Recuerda que estas reglas solo funcionan si tu servidor corre bajo Apache o utiliza Litespeed. Si usas Nginx, estas directivas no tendrán ningún efecto.

#Bloqueando el acceso a wp-config.php

Configurar en la raíz del sitio dentro de .htaccess:

# Bloqueo de acceso al archivo de configuración
<Files wp-config.php>
    order allow,deny
    deny from all
</Files>

#Protegiendo archivos de sistema y logs

A nivel de servidor, es sorprendente que sigamos dejando por defecto archivos como debug.log visibles si el desarrollador olvida borrarlo. Esta regla detiene el acceso a diversos archivos que nunca deberían ser descargables.

Añadir a continuación en el archivo .htaccess:

# Bloqueo de archivos de servidor, logs y backups
<FilesMatch "^(\.htaccess|\.htpasswd|php\.ini|debug\.log|error_log|wp-config-backup\.php)$">
    Order deny,allow
    Deny from all
</FilesMatch>

#Depurando un intento de robo de información mediante archivos de log

Hace un tiempo, revisando los logs de seguridad de un sitio de alta demanda, noté un patrón de escaneo muy específico: un bot estaba iterando nombres de archivos comunes como wp-config.old, wp-config.php.bak y debug.log. El síntoma clínico apareció al ver picos de tráfico en la base de datos que no se correspondían con las visitas reales del sitio. El servidor estaba respondiendo con códigos 200 a peticiones de archivos que el administrador había dejado por «un descuido momentáneo» tras una migración rápida.

Al principio, el administrador intentó usar un plugin de firewall que prometía «protección total», pero el plugin solo añadía reglas de PHP que se ejecutaban tarde. Para cuando el firewall de PHP despertaba, el archivo ya era vulnerable. Al implementar las reglas de .htaccess que ves arriba, desactivamos el intento de descarga instantáneamente en la capa de red del servidor. Vimos cómo los registros pasaron de «200 OK» a «403 Forbidden» en cuestión de segundos, cortando la fuga de información de raíz.

#Protocolo de emergencia ante un error 500

Editar el archivo .htaccess es una operación de riesgo. Un solo carácter mal puesto o un espacio de más puede provocar un Internal Server Error (Error 500) que deje tu web caída por completo.

Si tras guardar el archivo el sitio deja de funcionar, mantén la calma. Accede inmediatamente vía SFTP o a través del gestor de archivos de tu hosting y renombra el archivo .htaccess a algo como .htaccess_old. Esto restaurará el acceso al sitio, aunque perderás las reglas de seguridad y los enlaces permanentes (permalinks). Una vez recuperado el acceso, revisa que no hayas pegado el código dentro de un bloque de etiquetas que no corresponda o que no haya caracteres invisibles al final de las líneas.

#¿Dónde aplica esta técnica de blindaje?

• Escenarios recomendados: Sitios web alojados en servidores Apache (la gran mayoría de hostings compartidos y VPS con cPanel) donde el usuario tiene control sobre el archivo de configuración del directorio.
• Contraindicaciones: No lo apliques en servidores que utilicen exclusivamente Nginx o servidores IIS de Windows, ya que ignorarán estas reglas. Tampoco es necesario si tu hosting ya gestiona estas restricciones a nivel de servidor principal (puedes probarlo intentando acceder tú mismo a tusitio.com/wp-config.php; si recibes un 403, ya estás protegido).

#Pros y Contras

• Pros: Protección de bajo nivel (muy efectiva), consumo nulo de recursos PHP y detención de ataques antes de que lleguen a la aplicación.
• Contras: Puede romper la web si hay errores de sintaxis y requiere acceso a archivos del servidor (no se puede hacer solo desde el panel de WP).

«El .htaccess es la primera línea de infantería. Si cae, tu seguridad dependerá exclusivamente de cuán bien hayas programado tu PHP.»

Para aprender más sobre las capacidades de seguridad de Apache, puedes consultar la documentación oficial de Apache Software Foundation o revisar guías de hardening avanzadas en OWASP.