Seguridad wp-config.php avanzada

La importancia crítica de la seguridad wp-config.php

Si hay un archivo en tu instalación de WordPress que merece respeto, ese es wp-config.php. No es solo un archivo de configuración; ahí están las llaves de tu casa. Guarda las credenciales de la base de datos y define, en gran medida, qué tan difícil le va a poner las cosas a un intruso. Sin embargo, es curioso ver cuántos administradores lo tratan como algo intocable o, peor aún, lo ignoran hasta que es demasiado tarde. Gestionar la seguridad wp-config.php es blindar tu web desde los cimientos.

WordPress sale de la caja pensando en la funcionalidad, no en la fortaleza. Es lógico. Pero el problema es que esa configuración estándar deja muchas puertas entreabiertas. Lo bueno es que no necesitas ser un gurú de la seguridad para cambiar esto. Con unas pocas líneas de código bien puestas, este archivo deja de ser un simple archivo de texto y se convierte en un guardián activo. Vamos a repasar cómo.

Cambio de prefijo de la base de datos

Mantener el prefijo por defecto wp_ es un error novato que paga caro. Los bots automatizados que rastrean la web buscando vulnerabilidades lo saben. Asumen que tus tablas se llaman así. Es como poner un cartel en la puerta que dice «la llave está debajo del felpudo». Cambiar este prefijo no hace tu sitio invulnerable, pero obliga al atacante a adivinar la estructura interna, añadiendo una capa de ofuscación que, a menudo, es suficiente para que se vayan a por un objetivo más fácil.

Ojo, que no es tan simple como cambiar una línea en el wp-config.php. Tienes que renombrar las tablas en la base de datos y actualizar las referencias en la tabla wp_options (o tu nuevo prefijo). Pero todo empieza aquí. Busca esta línea y haz el cambio antes de instalar, o tómate el trabajo de hacerlo ahora:

$table_prefix = ‘wp_’;

Sustitúyela por algo aleatorio, un galimatías que no tenga sentido:

$table_prefix = ‘k9x_82mz_’;

Deshabilitar edición de temas y plugins

¿Sabías que cualquier administrador puede editar código PHP directamente desde el panel de control? Es cierto. En Escritorio > Apariencia > Editor de temas tienes el poder de romper todo con un clic. Ahora imagina que un hacker logra acceder a una cuenta de administrador. No necesita subir archivos; usa tu propio editor para inyectar malware o dejar una puerta trasera. Deshabilitar esto no te quita funcionalidad que uses a diario, pero cierra un agujero gigante.

Pon esto en tu archivo wp-config.php:

define( ‘DISALLOW_FILE_EDIT’, true );

Y si quieres ser más estricto aún, bloquea también la instalación y actualización de plugins desde el dashboard. Así te aseguras de que cualquier modificación requiera acceso FTP o SFTP, lo cual implica unas credenciales separadas que el hacker probablemente no tenga:

define( ‘DISALLOW_FILE_MODS’, true );

Forzar conexión SSL y Seguridad de transporte

La encriptación no es opcional hoy en día. Si tu panel de administración viaja en texto plano, cualquiera en la red puede ver tus cookies y contraseñas. WordPress tiene una constante específica para obligar a que el login y el escritorio se sirvan siempre a través de HTTPS. Es una manera efectiva de proteger las credenciales de esas intercepciones tan comunes en redes WiFi públicas.

Para activar esta parte de la seguridad wp-config.php, mete este código:

define( ‘FORCE_SSL_ADMIN’, true );

También puedes forzar SSL para todo el sitio. Aunque los plugins lo hacen bien, hacerlo a nivel de configuración es más limpio y robusto:

define( ‘FORCE_SSL_LOGIN’, true );

Limitar revisiones de entradas y vaciado de papelera

Las revisiones de posts salvan la vida más de una vez, sí. Pero cada una de ellas es una entrada completa en la base de datos. Si llevas años escribiendo, la basura se acumula. No es solo cuestión de espacio; una base de datos hinchada es más lenta y más difícil de respaldar. Limitar el número de revisiones mantiene todo más ágil.

Una línea basta para decirle a WordPress «basta con tres»:

define( ‘WP_POST_REVISIONS’, 3 );

Si odias las revisiones, puedes poner false y olvidarte del tema (aunque yo no lo recomiendo para sitios activos). Y hablemos de la papelera. WordPress retiene lo que borras durante 30 días. ¿Necesitas un mes para decidir si te equivocaste? Probablemente no. Ahorra espacio reduciendo el tiempo:

define( ‘EMPTY_TRASH_DAYS’, 7 ); // Vaciar papelera cada 7 días

Si eres del tipo que borra y ya, y sabes lo que hace, puedes ponerlo a 0 para eliminar archivos al instante. Cuidado, que ahí no hay vuelta atrás.

Bloqueo de peticiones externas y acceso a archivos XML-RPC

WordPress llama a casa para buscar actualizaciones. Está bien. Pero también permite peticiones externas desde plugins que, a veces, envían más datos de los que te gustaría. Puedes poner un muro a todo esto bloqueando las peticiones externas por defecto:

define( ‘WP_HTTP_BLOCK_EXTERNAL’, true );

¿Y si necesitas que un plugin hable con una API de pago o un servicio externo? Puedes abrir la puerta solo para ellos:

define( ‘WP_ACCESSIBLE_HOSTS’, ‘api.ejemplo.com’ );

Luego está el tema de xmlrpc.php. Este archivo es un clásico objetivo para ataques de fuerza bruta y DDoS. A menos que uses la app móvil de WordPress o Jetpack para publicar cosas a distancia, realmente no lo necesitas. Desactívalo sin miedo:

add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );

Desplazamiento de claves de seguridad

Las claves de seguridad (AUTH_KEY, SECURE_AUTH_KEY y sus variantes) son el engrase que encripta las cookies. Si son débiles o, peor, si alguien las conoce, puede falsificar una cookie y entrar a tu sitio sin contraseña. Es como robar la llave maestra. WordPress ofrece un generador online para esto. Úsalo.

Busca las líneas por defecto y cámbialas por unos monstruos de texto aleatorio como estos:

define( ‘AUTH_KEY’, ‘pon aqui tu frase aleatoria’ );
define( ‘SECURE_AUTH_KEY’, ‘pon aqui tu frase aleatoria’ );
define( ‘LOGGED_IN_KEY’, ‘pon aqui tu frase aleatoria’ );
define( ‘NONCE_KEY’, ‘pon aqui tu frase aleatoria’ );
define( ‘AUTH_SALT’, ‘pon aqui tu frase aleatoria’ );
define( ‘SECURE_AUTH_SALT’, ‘pon aqui tu frase aleatoria’ );
define( ‘LOGGED_IN_SALT’, ‘pon aqui tu frase aleatoria’ );
define( ‘NONCE_SALT’, ‘pon aqui tu frase aleatoria’ );

Un efecto secundario útil: al cambiar estas claves, desconectas a todos los usuarios actuales. Si alguien tenía una sesión secuestrada, adiós.

Deshabilitar el editor de temas y plugins en caso de error

Hablamos de DISALLOW_FILE_EDIT, pero hay otro frente. La depuración. Cuando WP_DEBUG está activo, los errores se pintan en pantalla. Genial para quien programa, terrible para quien vive. En producción, mostrar errores es regalarte: le estás diciendo al atacante las rutas de tu servidor y trozos de tu estructura. Apágalo.

Tu configuración en un sitio en vivo debería parecerse a esto:

define( ‘WP_DEBUG’, false );
define( ‘WP_DEBUG_LOG’, false );
define( ‘WP_DEBUG_DISPLAY’, false );

Conclusión

Tratar wp-config.php como un archivo más es un error. Es la primera línea de defensa interna que tienes. Implementar estas constantes no es ciencia complicada, pero la diferencia de seguridad es abismal. Estás cerrando ventanas que los atacantes usan como entrada principal. Desde proteger la base de datos hasta cortar el acceso a servicios remotos innecesarios, cada ajuste cuenta.

Dicho esto, no te lances a editar sin red. Haz una copia de seguridad del sitio y del archivo. Si algo sale mal (y a veces sale), detente. En RedServicio (redservicio.net) tenemos a gente lidiando con esto todos los días. Si te sientes abrumado o simplemente prefieres que alguien más asuma el riesgo, estamos aquí para asegurar tu infraestructura. La seguridad proactiva no es un gasto; es tranquilidad.