Seamos sinceros: WordPress es el rey de la web y está sobreviviendo al vibecoding, al menos de momento. Por algo sigue moviendo más del 40% de Internet. Eso es genial por la comunidad y los recursos, pero también significa que es el objetivo favorito de cualquier ciberdelincuente con tiempo libre.
Instalar WordPress y no securizarlo siempre ha sido tentar a la suerte pero actualmente es incluso temerario. Existen herramientas de auditoria web (como WPScan, especializada en WordPress) muy potentes y ahora cualquier persona puede utilizarlos siguiendo los pasos de cualquier LLM.
Hoy vamos a hablar de hardening (endurecimiento, bastionado…) en WordPress, o el noble arte de reducir la superficie de ataque (attack surface) hasta que los hackers se aburran y se vayan a molestar a otro.
Índice de contenidos
Lo básico: Si no haces esto, ni sigas leyendo
Empecemos por lo obvio, que curiosamente es lo que más gente ignora. No vamos a entrar en detalle, pero te damos la orientación para que amplíes la información con tu IA de confianza.
Actualizaciones: La dieta de tu web
El software desactualizado es la vía de entrada número uno. Tanto el núcleo (core) de WordPress, como los temas y plugins, deben estar al día. Las actualizaciones no son solo nuevas funcionalidades molestas; suelen incluir parches de seguridad (security patches) críticos.
Si ves una notificación de actualización y la ignoras durante meses, básicamente estás diciendo: «Hola, sé que tengo una vulnerabilidad conocida, venid a mí».
Copias de seguridad (Backups)
La regla de oro de la informática: Si no tienes tres copias, no tienes datos. Necesitas un sistema de copias de seguridad automatizado y, lo más importante, externo al servidor. Si tu servidor explota (metafóricamente o porque un ransomware decidió encriptarlo todo), tener el backup en el mismo disco duro es tan útil como un cenicero en una moto.
Recuerda: Un backup no sirve de nada si no has probado a restaurarlo. Que no se te olvide nunca.
Identidad y Acceso: Cierra la puerta principal
La mayoría de los ataques son automatizados. Son bots probando llaves en todas las puertas que encuentran.
Mata al usuario ‘admin’
Si tu usuario administrador se llama «admin», «administrator» o el nombre de tu dominio, enhorabuena: ya le has hecho el 50% del trabajo al atacante. Lo primero que intenta un ataque de fuerza bruta (brute force attack) es el usuario «admin».
- Solución: Crea un usuario nuevo con permisos de administrador, un nombre difícil de adivinar y borra el antiguo.
Capa de Identidad (El Señuelo / Honeypot)
Los atacantes saben que los nombres de usuario de WordPress son públicos y se pueden enumerar con muchísima facilidad tirando de la API REST o buscando las páginas de autor. Para evitar esto, tienes que desvincular el usuario real con el que accedes al panel, del nombre público que ve la gente.
Para ello creamos una capa de identidad falsa o señuelo (spoofing). La idea es sencilla: si tu usuario de login es complejo y secreto, forzamos a WordPress a mostrar al público un alias falso, como por ejemplo «escriba». Cuando las redes de bots ataquen intentando adivinar la contraseña de «escriba», jamás lograrán entrar porque ese usuario en realidad no existe para el sistema de acceso.
Si administras tu servidor y tienes acceso por terminal, puedes aplicar este cambio de forma limpia y directa usando WP-CLI. Solo tienes que ejecutar estos comandos reemplazando los datos por los tuyos:
wp user update tu_usuario_secreto --user_nicename=escriba --allow-root
wp cache flush --allow-rootContraseñas y Autenticación Multifactor (MFA)
«Contraseña123» no es una contraseña, es un chiste de mal gusto. Usa gestores de contraseñas y longitudes absurdas (revisa nuestros criterios recomendados para contraseñas). Pero, sobre todo, activa la autenticación multifactor (MFA). Es esa capa extra que pide un código de tu móvil. Incluso si un atacante consigue tu contraseña (quizás porque la usaste en ese foro de cocina que fue hackeado en 2015), sin el segundo factor, se queda fuera.
Implementar MFA es molesto, sí. Pero es más molesto explicarle a tu jefe por qué la web de la empresa ahora redirige a un sitio de apuestas ruso. Y si, el MFA no lo es todo «ÑEÑEÑE» pero es una capa más.
Debes usar aplicaciones TOTP (como Google Authenticator o Authy) y alejarte de los SMS, vulnerables a ataques de SIM Swapping.
Limita los intentos de login
Por defecto, WordPress te deja intentar loguearte infinitas veces. Instala un plugin para limitar los intentos de inicio de sesión (login attempts). Después de 3 fallos, bloquea la IP. Que se vayan a adivinar la contraseña de su abuela.
Plugins y Temas: El Caballo de Troya
Aquí es donde entra el desastre. La gente instala plugins para todo: un plugin para que nieve en la web, otro para cambiar el color del scroll…
Minimización
Cada plugin es una puerta potencial. Cuantos más tengas, mayor es tu superficie de ataque. Desactiva y borra lo que no uses. El código inactivo también puede ser explotado si está en el servidor.
Cuidado con lo «Nulled»
¿Te has bajado un tema premium gratis de una web rusa sospechosa? Sorpresa: probablemente viene con «regalo». El software pirata (nulled software) suele estar infectado con puertas traseras (backdoors) o scripts de minería de criptomonedas. Lo barato sale caro, y en ciberseguridad, sale carísimo.
Hardening Técnico: Bajo el capó
Ahora nos ponemos los guantes de látex. Vamos a tocar configuraciones del servidor.
Prefijo de la Base de Datos
Por defecto, las tablas de WordPress empiezan por wp_. Esto hace la vida muy fácil a los ataques de inyección SQL (SQL Injection) automatizados, porque ya saben cómo se llaman tus tablas. Cámbialo durante la instalación o usa un plugin de seguridad para renombrarlo a algo tipo x7z_. No es infalible (es seguridad por oscuridad), pero ayuda a despistar a los bots tontos.
La verdadera defensa contra el SQLi son las consultas parametrizadas (que WordPress ya hace en su core) y un buen WAF.
Permisos de Archivos (File Permissions)
En Linux/Unix, los permisos importan.
- Directorios:
755 - Archivos:
644 wp-config.php:400o440(nadie más que el servidor debería leer esto).
Si pones permisos 777 (lectura, escritura y ejecución para todo el mundo) a algo, básicamente estás gritando «¡Barra libre!». Nunca, bajo ninguna circunstancia, uses 777.
Desactiva la edición de archivos
WordPress permite editar los archivos .php de temas y plugins desde el panel de administración. Si un hacker entra en tu panel, puede insertar código malicioso directamente desde ahí. Añade esto a tu wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );XML-RPC: El zombi del pasado
XML-RPC es una API antigua que se usaba para conectar apps externas. Hoy en día, la API REST es mejor. XML-RPC es famoso por ser usado para ataques de amplificación DDoS y fuerza bruta. Si no lo usas (y probablemente no lo hagas), bloquéalo en tu .htaccess o con un plugin.
El Escudo Exterior: WAF y HTTPS
SSL/TLS (HTTPS)
A estas alturas, si tu web sigue en HTTP, Google te penaliza y los navegadores te marcan como «No seguro». Pero más allá de eso, necesitas cifrado (encryption) en tránsito para que nadie intercepte tus credenciales cuando te logueas en la cafetería. Usa Let’s Encrypt, es gratis. No tienes excusa.
Web Application Firewall (WAF)
Un cortafuegos de aplicación web (WAF) se coloca delante de tu sitio y filtra el tráfico malicioso antes de que llegue a tu servidor. Servicios como Cloudflare (que tiene capa gratuita) o plugins como Wordfence son vitales. Bloquean bots, escaneos de vulnerabilidades y ataques conocidos.
Checklist de Supervivencia (Resumen para vagos)
Si te has saltado todo el texto porque «mucho texto», al menos haz esto:
- Backup diario externo (fuera de tu servidor).
- Actualiza todo (Core, temas, plugins) religiosamente.
- Elimina el usuario
adminy pon contraseñas de más de 12 caracteres. - Activa MFA (2FA). Es innegociable.
- Instala un plugin de seguridad (WAF) y limita intentos de login.
- Deshabilita la edición de archivos en el dashboard.
- Ponle HTTPS con certificado TLS.
Ejemplo práctico con htaccess
Vamos a profundizar un poco, aunque seguimos en lo básico de lo básico
Si tu servidor usa Apache (o LiteSpeed), el archivo .htaccess es importante. Puede bloquear, redirigir y proteger. Aquí van los snippets (fragmentos de código) que separan a los niños de los adultos.
Nota: Añade esto antes de las reglas de WordPress (# BEGIN WordPress).
Protege el archivo de configuración (wp-config.php)
El wp-config.php tiene tus claves de base de datos. Si alguien lo lee, game over.
<FilesMatch "^(?i)wp-config\.php$">
Require all denied
</FilesMatch>Nadie, absolutamente nadie, puede cargar este archivo desde el navegador.
Evita el listado de directorios (Directory Browsing)
Si no hay un index.php en una carpeta, el servidor suele mostrar una lista de todos los archivos. Es como dejar que un ladrón vea el plano de tu casa.
Options -IndexesEfecto: Si intentan ver /wp-content/uploads/, verán un «403 Forbidden» en lugar de tus archivos.
Bloquea la ejecución de PHP en carpetas de subida
Este es vital. Si un atacante logra subir un archivo llamado malware.php a tu carpeta de imágenes (/uploads), intentará ejecutarlo para tomar el control. Vamos a impedir que se ejecuten scripts ahí.
Crea un archivo .htaccess nuevo DENTRO de /wp-content/uploads/ y pon esto:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>Resultado: Aunque suban el virus, no podrán «detonarlo». Se queda ahí como un archivo inerte.
Bloqueo de XML-RPC
Como dijimos antes, si no usas Jetpack o la app móvil de WP, cierra esto. Es un coladero.
<FilesMatch "^(?i)xmlrpc\.php$">
Require all denied
</FilesMatch>Seguridad por oscuridad: Ejemplo práctico con un MU-Plugin (Must-Use)
Mientras que el archivo htaccess que hemos visto antes sirve para proteger el servidor, un MU-Plugin sirve para proteger el código de tu aplicación. Estos plugins son scripts puros de PHP que se cargan antes que cualquier otra cosa en WordPress.
Tienen la particularidad de que no se pueden desactivar desde el panel de control y ni siquiera aparecen en la lista normal de plugins instalados. Son, a todos los efectos, un blindaje silencioso.
Vamos a utilizar uno para tapar las fugas de información más típicas: la versión exacta de tu WordPress, el listado de usuarios que expone la API REST y las huellas que deja el autor en el código fuente de tu diseño. La seguridad por oscuridad no debe ser tu principal capa de defensa, pero llegados a este punto suma, y mucho.
Para aplicarlo, crea un archivo llamado wp-hardening.php y súbelo a la ruta wp-content/mu-plugins/ de tu instalación. Si esa carpeta no existe, simplemente créala. Una vez dentro, pega este código:
<?php
/* Plugin Name: Wp Hardening - Bunker Light Edition */
if (!defined('ABSPATH')) exit;
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');
add_filter('script_loader_src', function($s){return strpos($s,'ver=')?remove_query_arg('ver',$s):$s;});
add_filter('style_loader_src', function($s){return strpos($s,'ver=')?remove_query_arg('ver',$s):$s;});
add_filter('rest_endpoints', function($e){
unset($e['/wp/v2/users'], $e['/wp/v2/users/(?P<id>[\d]+)']);
return $e;
});
add_action('template_redirect', function(){
if(is_author()){ wp_redirect(home_url(), 301); exit; }
});Esta es una versión muy básica. Puedes mejorarla para ocultar las versiones de tus plugins y aplicar otras medidas de seguridad. Consulta con tu IA de confianza sabiendo SIEMPRE lo que haces y lleva la seguridad de tu WordPress al siguiente nivel.
Protocolo de verificación: atácate a ti mismo (WPScan)
En el mundo de la ciberseguridad, la protección no se asume, sino que se demuestra. Una vez que has aplicado las reglas en tu servidor, has configurado tu usuario señuelo y has subido tu código de ofuscación, el paso lógico es auditar tu propia web (como detallamos aquí) exactamente como lo haría un delincuente.
La herramienta por excelencia en la industria para hacer esto se llama WPScan. Si abres tu terminal de Linux, puedes lanzar un escaneo de reconocimiento agresivo contra tu dominio utilizando este comando:
wpscan --url https://tudominio.com/ --random-user-agent --enumerate u --api-token TU_API_KEYSi has hecho bien los deberes del hardening, el resultado del escáner debe ser frustrante para el atacante:
- La versión de tu WordPress no debería ser detectada por ningún lado.
- Los intentos de acceso a servicios como XML-RPC deben rebotar con un error de acceso denegado.
- Y lo más importante, al intentar enumerar los usuarios, el escáner solo debería ser capaz de encontrar a tu usuario señuelo, manteniendo tu nombre de acceso real completamente en la sombra.
Cuando el escáner vuelve vacío, sabes que tu web está lista para salir ahí fuera.
Conclusión
La seguridad en WordPress no es un producto que compras y te olvidas; es un proceso continuo. Es como limpiar la casa: si dejas de hacerlo, eventualmente la basura te comerá.
Aplicar este hardening no te garantiza una seguridad del 100% (eso no existe, ni desenchufando el servidor), pero elevará la barra lo suficiente como para que los atacantes pasen de largo y se vayan a por la web de tu competencia, que seguro sigue usando «admin/123456».
