Los ataques de fuerza bruta contra wp-login.php son el vector más frecuente en WordPress: bots automatizados prueban miles de combinaciones de usuario y contraseña por hora hasta encontrar una que funcione. Sin ningún sistema de bloqueo, el atacante puede intentarlo indefinidamente. Proteger wp-login.php del brute force requiere capas combinadas: límite de intentos, 2FA y WAF.
Un ataque de fuerza bruta en WordPress es un método automatizado donde scripts o botnets prueban combinaciones sistemáticas de credenciales contra wp-login.php hasta acceder a una cuenta válida. El éxito depende de dos factores: la debilidad de las contraseñas y la ausencia de un sistema que detenga los intentos repetidos. WordPress no incluye esa protección por defecto, lo que convierte a wp-login.php en el punto más atacado de cualquier instalación estándar.
En 30 segundos
- Los bots prueban combinaciones automáticas de usuario/contraseña contra wp-login.php sin que el dueño del sitio lo note hasta que el daño ya está hecho
- Limit Login Attempts Reloaded, con más de 2 millones de instalaciones activas en WordPress.org, es el plugin estándar para bloquear IPs tras intentos fallidos
- La configuración recomendada para la mayoría de los sitios es 5 intentos fallidos antes del bloqueo y un tiempo de espera de al menos 1 hora
- El 2FA bloquea el acceso aunque la contraseña ya haya sido comprometida, lo que lo convierte en la capa más efectiva contra este tipo de ataque
- XML-RPC también acepta intentos de login y muchos sitios lo dejan sin proteger, lo que crea un segundo vector de entrada
¿Qué es un ataque de fuerza bruta en wp-login.php?
Ponele que tu sitio recibe 4.000 requests por hora a /wp-login.php. Vos no lo sabés. No aparece nada en el dashboard de WordPress, el sitio carga normal y todo parece estar bien. Mientras tanto, un bot está probando «admin» + «password123», después «admin» + «wordpress», después «admin» + el nombre de tu dominio, y así hasta terminar el diccionario o dar con la combinación correcta.
La mecánica es simple: un script descarga una lista de contraseñas comunes (compiladas a partir de filtraciones reales de otros servicios, las llamadas listas de «credential stuffing») y las dispara contra wp-login.php en secuencia. Las contraseñas más comunes según los registros de ataques reales incluyen variaciones de «admin», el nombre del dominio, años y combinaciones predecibles. Si no hay nada que frene esos intentos, el bot sigue probando.
Hay dos variantes. La primera es el brute force clásico: prueba combinaciones de caracteres de forma exhaustiva. La segunda, más común hoy, es el ataque de diccionario: usa listas de contraseñas ya conocidas que resultan mucho más efectivas porque explotan la reutilización de credenciales entre servicios. Complementá con herramientas para limpiar malware.
El problema adicional es xmlrpc.php. Ese archivo acepta intentos de autenticación igual que wp-login.php, con la diferencia de que permite probar múltiples contraseñas en un solo request HTTP (amplificando el ataque). Muchos administradores bloquean wp-login.php pero dejan xmlrpc.php abierto sin darse cuenta.
¿Qué impacto tiene un ataque de fuerza bruta si no hacés nada?
El escenario más obvio es el acceso no autorizado: alguien entra al panel de administración, instala un plugin malicioso, redirige el tráfico o copia la base de datos. Pero ese es el final. Antes de llegar ahí hay consecuencias que ya afectan el sitio.
- Degradación de rendimiento. Cada intento de login consume CPU y memoria del servidor. Con miles de requests por hora sostenidos, el sitio se vuelve lento para los visitantes reales antes de que el atacante entre.
- Suspensión por el hosting. En hosting compartido, el consumo excesivo de recursos puede provocar que el proveedor suspenda la cuenta temporalmente. El resultado para los visitantes es idéntico a una caída: sitio inaccesible.
- Penalización en SEO. Si el sitio termina comprometido y distribuye malware o tiene redirecciones maliciosas, Google lo marca como peligroso. Recuperar esa reputación lleva semanas o meses.
- Costo de remediación. Limpiar un sitio infectado lleva horas y puede requerir restaurar desde un backup. Si no hay backup reciente, el daño puede ser permanente.
¿Y qué pasa si el ataque no logra entrar pero sigue activo? Exacto: el daño de rendimiento ocurre igual. No necesitan comprometer el sitio para afectarlo.
Limitar intentos de login: configuración recomendada para proteger wp-login.php del brute force
La defensa más básica es establecer un máximo de intentos fallidos antes de bloquear la IP. El estándar en la industria va de 3 a 5 intentos, con un tiempo de bloqueo inicial de al menos 1 hora. WordPress no incluye esto por defecto, así que se necesita un plugin.
Esta tabla muestra las tres configuraciones más comunes según el tipo de sitio:
| Configuración | Intentos permitidos | Duración del bloqueo | Ideal para |
|---|---|---|---|
| Conservadora | 3 intentos | 24 horas | Tiendas WooCommerce, sitios con datos sensibles o pagos |
| Estándar | 5 intentos | 1 hora | Blogs, portfolios, sitios de contenido |
| Relajada | 10 intentos | 20 minutos | Entornos de desarrollo o equipos con muchos usuarios |
La configuración conservadora tiene un riesgo real: si alguien del equipo tipea mal la contraseña tres veces, queda bloqueado durante 24 horas (lo que puede ser molesto sin un procedimiento claro de desbloqueo). La estándar equilibra seguridad y usabilidad para la mayoría de los sitios. Te puede servir nuestra cobertura de alternativas de firewalls WAF.
Eso sí: el bloqueo por IP tiene una limitación importante. Botnets distribuidas usan miles de IPs distintas, así que el límite de intentos por IP ralentiza el ataque pero no lo detiene por completo. Para eso hay que combinarlo con las capas que se describen más adelante.
Cómo configurar Limit Login Attempts Reloaded paso a paso
Limit Login Attempts Reloaded tiene más de 2 millones de instalaciones activas en el repositorio de WordPress.org (que no es un número que se ignore así nomás) y es el plugin más usado para esta tarea. La configuración básica lleva menos de 5 minutos.
- Instalación. Desde el panel de WordPress, ir a Plugins > Agregar nuevo, buscar «Limit Login Attempts Reloaded» e instalarlo desde el repositorio oficial.
- Acceder a la configuración. Una vez activado, las opciones aparecen en Ajustes > Limit Login Attempts.
- Configurar intentos y bloqueo. Los campos principales son «Allowed Retries» (intentos antes del bloqueo), «Lockout period» (duración en minutos) y «Hours until retries are reset» (ventana de tiempo para contar los intentos).
- Notificaciones por email. Activar el aviso por correo cuando una IP quede bloqueada es especialmente útil si manejás sitios para clientes: te enterás del ataque en tiempo real.
- Compatibilidad con proxy o CDN. Si el sitio está detrás de Cloudflare u otro proxy, activar la opción de «trusted IP headers». Sin esto, el plugin bloquea la IP del proxy en vez de la del atacante (y entonces bloqueás a todos tus visitantes).
Para sitios bajo alto volumen de ataques, el plugin tiene integración con su propia red para compartir listas de IPs maliciosas conocidas. Esa función está disponible en el plan gratuito.
Cambiar la URL de login: útil, pero no es protección real
WPS Hide Login y plugins similares permiten cambiar la URL de login de /wp-login.php a algo como /acceso-mi-sitio o cualquier string que elijas. La idea: si los bots no saben dónde está el login, no pueden atacarlo.
Funciona para el ruido automatizado básico. Muchos bots atacan /wp-login.php por defecto sin verificar si la URL existe. Cambiarla puede reducir notoriamente la cantidad de intentos que registra el plugin.
El problema es que eso es «seguridad» por oscuridad (y el término va con comillas porque no es seguridad real). Un atacante que apunta específicamente a tu sitio puede encontrar la URL real del login revisando el código fuente de los formularios, interceptando el tráfico, o simplemente probando los strings más comunes que usan estos plugins. Instalás WPS Hide Login, elegís /mi-acceso, y hay listas públicas de los 50 slugs más populares para este plugin. Más contexto en protección de tiendas online.
Usalo como complemento. No como capa principal.
Activar 2FA: la capa que los bots no pueden pasar
La autenticación de dos factores es la medida más efectiva contra el brute force. El argumento es simple: incluso si un atacante da con la contraseña correcta, sin el segundo factor (un código temporal de 6 dígitos que genera una app en el teléfono) no puede entrar.
Los plugins más usados para 2FA en WordPress son Wordfence (incluye 2FA en su versión gratuita, lo que no es poco considerando que también trae WAF y escaneo de malware), WP 2FA y Two Factor Authentication. Los tres soportan apps estándar como Google Authenticator o Authy.
El flujo con 2FA activado: el usuario ingresa usuario y contraseña, WordPress valida las credenciales y, si son correctas, pide el código TOTP de 6 dígitos válido por 30 segundos que genera la app. Sin ese código, el login no se completa aunque la contraseña sea correcta.
Para sitios con un único administrador, la implementación tarda 10 minutos y el nivel de protección sube de forma sustancial. Para sitios con múltiples usuarios, hay que coordinar que cada uno configure la app en su teléfono, lo que tiene un costo operativo real pero vale la pena en sitios con datos sensibles o acceso a pagos.
WAF y rate limiting a nivel de servidor
Los plugins actúan a nivel de PHP: WordPress ya procesó el request cuando el plugin decide bloquearlo. Un WAF opera antes de que el request llegue a PHP, lo que es más eficiente en recursos y más difícil de evadir. Cubrimos ese tema en detalle en firewalls WAF más robustos.
Cloudflare tiene un tier gratuito que permite configurar reglas de rate limiting para /wp-login.php directamente desde su dashboard. Una regla básica y efectiva: bloquear cualquier IP que haga más de 10 requests a /wp-login.php en un período de 1 minuto. Se puede configurar sin tocar el servidor y protege xmlrpc.php también con una regla separada.
Wordfence Premium incluye un WAF con firmas específicas para detectar patrones de brute force. La versión gratuita tiene WAF pero las firmas se actualizan con 30 días de retraso respecto a la versión paga (spoiler: en seguridad, 30 días de retraso es mucho tiempo para vulnerabilidades activas).
Para sitios alojados en donweb.com, el panel de control permite aplicar reglas de seguridad directamente, incluyendo el bloqueo de xmlrpc.php a nivel de servidor antes de que los requests lleguen a PHP, lo que evita el consumo de recursos durante ataques sostenidos.
Si querés ir más allá, tenemos un artículo sobre Seguridad en wp-login.php que cubre todo en detalle.
Errores que anulan la protección contra brute force en wp-login.php
- Dejar el usuario «admin» activo. El nombre «admin» es el primero que prueba cualquier ataque de diccionario. Si tu administrador se llama «admin», el atacante ya tiene la mitad del trabajo hecho. La solución es crear un usuario administrador con otro nombre y eliminar o degradar el usuario «admin» original.
- No limitar los intentos de login. WordPress no trae esta protección. Sin un plugin que la active, los bots pueden probar contraseñas indefinidamente. Es la brecha más básica y la más común en sitios sin gestión activa de seguridad.
- Confiar solo en cambiar la URL de login. Como explicamos antes, la oscuridad no reemplaza la protección real. Un sitio con la URL de login cambiada pero sin límite de intentos ni 2FA sigue siendo vulnerable a un atacante con más herramientas.
- Ignorar XML-RPC. Si el sitio no usa aplicaciones móviles de WordPress ni herramientas que requieran XML-RPC, desactivarlo es la decisión correcta. Dejarlo abierto es un segundo punto de entrada para ataques que muchos sitios tienen sin saberlo.
- Contraseñas reutilizadas o predecibles. Una contraseña como «MiSitio2026!» puede aparecer en listas de filtraciones si se usó en otro servicio que fue comprometido. La defensa es usar contraseñas generadas aleatoriamente y almacenarlas en un gestor de contraseñas.
Preguntas Frecuentes
¿Qué es un ataque de fuerza bruta en WordPress?
Un ataque de fuerza bruta en WordPress es un método automatizado donde bots prueban combinaciones sistemáticas de usuario y contraseña contra wp-login.php hasta encontrar credenciales válidas. La variante más común hoy usa listas de contraseñas reales obtenidas de filtraciones anteriores (credential stuffing) en lugar de generar combinaciones aleatorias, lo que las hace más efectivas. Sin límite de intentos configurado, el ataque puede continuar indefinidamente sin que WordPress lo detecte.
¿Cuál es el mejor plugin para bloquear brute force en WordPress?
Limit Login Attempts Reloaded es el más instalado para esta función específica, con más de 2 millones de instalaciones activas según el repositorio de WordPress.org. Para sitios que quieren una solución completa, Wordfence combina límite de intentos, WAF y 2FA en un solo plugin con versión gratuita funcional. La elección depende de si preferís una herramienta enfocada o un suite de seguridad integrado.
¿Cómo limitar intentos de login en WordPress?
La forma más directa es instalar Limit Login Attempts Reloaded desde el repositorio oficial de WordPress, ir a Ajustes > Limit Login Attempts y configurar el máximo de intentos (5 es el estándar para la mayoría de los sitios) y la duración del bloqueo (1 hora como mínimo). El plugin bloquea automáticamente la IP que supere ese límite y puede enviar notificaciones por correo cuando ocurra un bloqueo. Si el sitio usa Cloudflare, también es posible configurar rate limiting directamente desde el dashboard de Cloudflare sin tocar WordPress.
¿Qué impacto tiene un ataque de fuerza bruta en el rendimiento del servidor?
Un ataque sostenido genera miles de requests a wp-login.php por hora, cada uno consumiendo CPU y memoria del servidor. En hosting compartido, esto puede provocar que el proveedor suspenda la cuenta por uso excesivo de recursos, con el mismo resultado para los visitantes que una caída. La protección a nivel de WAF o CDN es más eficiente porque bloquea los requests antes de que lleguen a PHP, evitando el consumo de recursos durante el ataque.
¿Cómo configurar 2FA en WordPress?
Con Wordfence (versión gratuita), ir al panel del plugin y acceder a la sección «Login Security». El proceso genera un código QR que se escanea con Google Authenticator o Authy en el teléfono. Desde ese momento, cada login requiere el código de 6 dígitos válido por 30 segundos que genera la app. WP 2FA es una alternativa específica si no se quiere instalar Wordfence completo y solo se busca activar el segundo factor sin otras funcionalidades de seguridad.
Conclusión
Proteger wp-login.php del brute force no requiere inversión significativa ni configuraciones complejas. Con tres capas bien configuradas, la exposición baja de forma sustancial: instalar Limit Login Attempts Reloaded con 5 intentos y bloqueo de 1 hora, activar 2FA para los usuarios administradores, y si el sitio ya pasa por Cloudflare, agregar una regla de rate limiting para /wp-login.php y /xmlrpc.php.
Lo que no resuelve ninguna de estas medidas es una contraseña ya comprometida que esté circulando en listas de credential stuffing. Por eso el 2FA cierra ese hueco: si la contraseña existe en una filtración, el atacante igual necesita el código temporal del teléfono para entrar. No hay forma de robar ese código de forma remota.
El punto de partida más simple si el sitio no tiene nada configurado: instalar Limit Login Attempts Reloaded hoy. Lleva 5 minutos y ya reduce el riesgo de forma medible. El resto de las capas se pueden agregar de a una.