Cómo blindar el acceso al panel WordPress contra bots y ataques de fuerza bruta
TL;DR
- Cualquier WordPress con IP pública recibe intentos de fuerza bruta continuos, independientemente del tamaño del sitio.
- MFA en el panel detiene a cualquier bot que consiga la contraseña correcta: sin el segundo factor, la contraseña no sirve.
- Bloquear /wp-admin por IP es la medida más efectiva si el equipo trabaja desde IPs conocidas.
- El WAF a nivel de Cloudflare o servidor bloquea antes de que la petición llegue a PHP: cero consumo de CPU por ataque.
- xmlrpc.php hay que bloquearlo si no lo necesitas: es el segundo vector de fuerza bruta más explotado después de /wp-login.php.
La URL /wp-admin de cualquier WordPress es pública por defecto y los bots la conocen. Cada día, miles de intentos automatizados de login golpean instalaciones de WordPress intentando adivinar contraseñas. No es algo que le ocurra solo a las webs grandes: cualquier instalación con IP pública recibe este tipo de ataques de forma continua. La diferencia entre un sitio que resiste y uno que cae no está en el tamaño ni en el tráfico: está en si tiene las medidas correctas configuradas. La buena noticia es que hay cinco medidas concretas que, bien combinadas, eliminan prácticamente el riesgo de acceso no autorizado al panel.
1. Doble factor de autenticación en el panel
Es la medida con mejor ratio de seguridad/esfuerzo disponible para WordPress. Incluso si un bot adivina la contraseña correcta (ya sea por fuerza bruta, por una lista de contraseñas filtradas o porque el usuario usa una contraseña débil), el MFA impide que acceda. Sin el código del segundo factor, la contraseña no sirve de nada.
Plugins como WP 2FA o el módulo de Wordfence permiten activar autenticación por aplicación (Google Authenticator, Authy, Microsoft Authenticator) para todos los usuarios con rol editor o superior. El coste de implementación es bajo y el impacto en seguridad es alto. Para usuarios que acceden ocasionalmente y pueden resistirse a instalar una app, WP 2FA permite también el envío de códigos por correo electrónico como alternativa menos segura pero más accesible.
Para usuarios técnicos que acceden poco, los códigos de respaldo son necesarios. Genéralos al configurar el MFA y guárdalos en el gestor de contraseñas del equipo, no en un post-it ni en el escritorio del ordenador. Si un usuario pierde el segundo factor y no tiene los códigos de respaldo, quedará bloqueado y el desbloqueo requiere intervención directa en la base de datos o acceso FTP/SSH.
2. Límite de intentos de login: cortar el grifo a los bots
Por defecto, WordPress no limita los intentos de autenticación. Un bot puede probar un millón de combinaciones de contraseña sin que el sistema haga nada para detenerlo. El único límite es la velocidad del servidor y el ancho de banda, que en muchos casos son suficientes para que el ataque sea sostenido durante horas o días sin ser detectado.
Limit Login Attempts Reloaded o la funcionalidad equivalente de Wordfence bloquean una IP tras N intentos fallidos durante un periodo configurable. La configuración recomendada para la mayoría de pymes:
- Bloqueo tras 5 intentos fallidos: suficiente para detener cualquier ataque automatizado sin molestar a usuarios que olvidan su contraseña.
- Duración del primer bloqueo: 20 minutos. Corto suficiente para no bloquear usuarios legítimos indefinidamente, largo suficiente para detener los bots que pasan a la siguiente IP.
- Bloqueo extendido en el tercer intento: 24 horas. Si la misma IP sigue intentando después de dos bloqueos, es claramente un ataque.
- Whitelist de IPs propias: las IPs de la oficina o VPN nunca deben quedar bloqueadas. Añádelas explícitamente a la lista blanca del plugin.
- Notificación al administrador: activa el aviso por correo cuando se produce un bloqueo, para tener visibilidad de intentos activos.
3. Lista blanca de IPs para wp-admin: la medida más efectiva
Si el equipo que gestiona la web siempre trabaja desde las mismas IPs (oficina, VPN), la opción más efectiva es bloquear el acceso a /wp-admin y /wp-login.php para cualquier IP que no esté en la lista. Esto se hace a nivel de servidor web o en el WAF, y elimina de raíz el problema de fuerza bruta: si la IP no está en la lista blanca, ni siquiera ve el formulario de login. No hay formulario que atacar.
En Nginx, la configuración es directa en el bloque location correspondiente. En Apache, con directivas Allow/Deny en .htaccess o en la configuración del VirtualHost. En Cloudflare, con una regla de firewall que filtre por ruta de URL y lista blanca de IPs.
La limitación es que requiere IPs fijas o el uso de una VPN con IP fija. Si los administradores del sitio trabajan desde IPs dinámicas domésticas, esta medida no es práctica como única solución, pero sí puede combinarse con la URL de login personalizada.
4. Renombrar la URL de acceso al panel
Cambiar /wp-login.php por una URL personalizada no es seguridad real contra un atacante que hace reconocimiento específico, pero sí elimina el tráfico de bots genéricos que solo saben atacar la URL estándar. Los bots más simples, que son la mayoría del volumen de ataques, simplemente pasan al siguiente objetivo de su lista si no encuentran /wp-login.php en la ruta esperada.
Plugins como WPS Hide Login lo hacen sin modificar el núcleo de WordPress: simplemente redirigen la URL antigua a la página de inicio y crean una nueva URL de acceso que solo conoce tu equipo. Elige una URL que no sea predecible (evita /admin, /panel, /acceso) y que no aparezca en el código fuente del sitio.
No lo uses como única medida. Úsalo combinado con MFA y límite de intentos. La seguridad por oscuridad no es seguridad, pero como capa adicional que reduce el ruido, funciona. Consulta también nuestro artículo sobre cómo bloquear la fuerza bruta en WordPress sin perder rendimiento para ver cómo hacerlo a nivel de servidor en lugar de a nivel de plugin.
5. WAF: el cortafuegos a nivel de aplicación
Un Web Application Firewall filtra el tráfico malicioso antes de que llegue a WordPress. Es la diferencia entre que el servidor no se entere del ataque (WAF externo en Cloudflare) o que lo gestione WordPress (plugin de seguridad con WAF). El primero es mucho más eficiente porque el servidor no consume recursos procesando peticiones que van a ser bloqueadas.
Cloudflare ofrece un WAF con reglas específicas para WordPress en su plan gratuito (limitado) y de pago. Las reglas del Managed Ruleset de Cloudflare para WordPress detectan patrones de explotación de vulnerabilidades conocidas en plugins y temas, intentos de fuerza bruta y escaneo de vulnerabilidades. Para sitios con datos de clientes o que procesan pagos, el WAF no es opcional.
Wordfence Premium incluye un WAF activo con actualización de reglas en tiempo real. La versión gratuita tiene las mismas reglas pero con 30 días de retraso, lo que significa que durante ese mes el sitio es vulnerable a exploits conocidos que el WAF de pago ya bloquea. Para sitios críticos, nuestro servicio de mantenimiento WordPress incluye la gestión del WAF y la revisión semanal del estado de seguridad.
6. Bloquear xmlrpc.php: el vector olvidado
xmlrpc.php es un punto de acceso alternativo a WordPress que los bots explotan activamente para ataques de fuerza bruta. A diferencia de /wp-login.php, xmlrpc.php no tiene protección nativa de intentos fallidos y permite múltiples intentos de autenticación en una sola petición HTTP mediante el método system.multicall. Un solo bot puede probar miles de contraseñas por minuto a través de xmlrpc.php.
Si no usas aplicaciones móviles antiguas de WordPress, Jetpack o herramientas de publicación de terceros que dependen de xmlrpc.php, bloquearlo es la opción correcta. Puedes hacerlo a nivel de servidor web con un bloque location en Nginx, en .htaccess en Apache, o con una regla de Cloudflare. Wordfence también permite bloquearlo desde su panel de configuración.
Verifica antes de bloquear si algún plugin o integración activa lo usa. Los casos más comunes donde xmlrpc.php sigue siendo necesario son: Jetpack (aunque tiene alternativas que no lo requieren), apps móviles de WordPress antiguas, y herramientas de publicación remotas como MarsEdit.
Comparativa de métodos de protección del panel WordPress
| Método | Efectividad | Impacto en rendimiento | Coste |
|---|---|---|---|
| MFA (doble factor) | Muy alta | Ninguno | Cero |
| Límite intentos (plugin) | Alta | Bajo (PHP procesa el intento) | Cero |
| Whitelist IPs en servidor | Muy alta | Ninguno | Cero (requiere IP fija) |
| URL personalizada login | Media (solo bots básicos) | Ninguno | Cero |
| WAF Cloudflare | Muy alta | Ninguno en servidor | Desde 0€ (plan Free) |
| Bloqueo xmlrpc.php | Alta | Ninguno | Cero |
Por dónde empezar mañana
- Instala WP 2FA o activa el MFA de Wordfence hoy y obliga a todos los administradores a configurarlo en su próximo login. Es la medida más rápida con mayor impacto.
- Activa el límite de intentos de login en Wordfence o con Limit Login Attempts Reloaded. Configura 5 intentos y 20 minutos de bloqueo. Añade la IP de tu oficina a la whitelist.
- Verifica si xmlrpc.php está siendo atacado revisando los logs de acceso del servidor (busca peticiones POST a xmlrpc.php) y bloquearlo si no lo necesitas.
- Si tu equipo trabaja desde IPs fijas, añade una regla de Cloudflare o del servidor web que restrinja el acceso a /wp-admin y /wp-login.php solo a esas IPs.
Si gestionas WordPress para tu empresa y quieres una revisión completa de la configuración de seguridad actual, nuestro servicio de auditoría informática incluye la revisión específica de instalaciones WordPress con informe de vulnerabilidades y plan de acción.
Preguntas frecuentes
¿Cuántos intentos de login recibe un WordPress al día?
Depende del tamaño y visibilidad del sitio, pero incluso instalaciones pequeñas con poco tráfico reciben cientos o miles de intentos de fuerza bruta al día. Los bots escanean toda la red de forma continua buscando /wp-login.php accesible.
¿Qué pasa si bloqueo /wp-admin por IP y mi IP cambia?
Si trabajas con IP dinámica, la restricción por IP puede dejarte fuera. La solución es combinarla con una VPN de IP fija, o usar el método alternativo de URL de login personalizada como capa adicional. En cualquier caso, mantén siempre un acceso de emergencia documentado.
¿Wordfence Free es suficiente o necesito la versión Premium?
Wordfence Free ofrece el WAF y el límite de intentos de login, suficiente para la mayoría de pymes. La versión Premium añade actualización de reglas en tiempo real y la lista de IPs maliciosas actualizada. Para sitios con datos sensibles o alto tráfico, Premium vale la pena.
¿xmlrpc.php es necesario o puedo bloquearlo?
La mayoría de instalaciones modernas no lo necesitan. Se usa para integraciones con aplicaciones móviles antiguas y herramientas de publicación de terceros. Si no usas ninguna de esas integraciones, bloquearlo es la opción más segura.
¿El MFA en WordPress afecta al rendimiento del sitio?
No. El MFA solo afecta al proceso de autenticación en el panel de administración, no al frontend visible a los visitantes. El impacto en el rendimiento del servidor es mínimo y completamente insignificante para la carga del sitio.
¿Renombrar /wp-login.php es una medida de seguridad real?
Es security through obscurity: reduce el ruido de bots genéricos pero no protege contra atacantes que hacen un reconocimiento específico de tu sitio. Úsalo como capa adicional combinada con MFA y límite de intentos, no como medida principal.
¿Con qué frecuencia debo revisar los logs de intentos de login?
Semanalmente como mínimo si gestionas el sitio manualmente. Si tienes un MSP o servicio de mantenimiento WordPress, esta revisión debe estar incluida en el informe mensual de actividad.