Por qué no usar Limit Login Attempts

Limit login Attemps introduce registros falsos para que te asustes y compres la versión Premium.

Autor:: Carlos Sánchez

Fecha de publicación:: 2022-05-11
Última revisión:: 2026-01-30

Índice mostrar

Seguridad estándar de WordPress

Para acceder a la parte de administración de un WordPress por defecto basta con añadir /wp-admin en la url de la página de inicio.

Por lo general, en cualquier web de WordPress te encontrarás una interfaz similar a esta:

Entonces ocurre que en la mayor parte de plataformas de WordPress se sabe directamente la URL para acceder. Como alguien con conocimientos y malas intenciones se pueda hacer con el usuario (y con plugins y temas no optimizados es bastante fácil y habitual verlos a la vista), solo necesitará la contraseña para acceder.

Por lo que hay un método sencillo y eficaz que en muchos casos permite acceder fácilmente al backend de la web. Este método se llama ataque por fuerza bruta, y consiste en emplear un bot que vaya probando infinitas variables de contraseñas hasta que dé con la adecuada (normalmente ayudándose de diccionarios y listados con las contraseñas más comunes).

Utilización de plugins externos

Debido a estos hechos, es bastante probable que alguna vez hayamos querido recurrir a plugins que o nos relocalizan el panel de acceso, o establecen un patrón de tiempos de espera y hasta bloqueos por X intentos de acceder que se hacen en el panel.

Uno de estos plugins es Limit Login Attempts Reloaded, con más de 2 millones de instalaciones activas.

En principio parece un plugin bastante completo y versátil, donde si bien hay una versión premium con más configuraciones como las de evitar intentos de accesos por países, parece totalmente funcional. De hecho lo es, y si pruebas a entrar las veces que configures sin éxito, te bloquea (como debe hacer).

Comportamiento sospechoso: ¿falsos positivos o algo más?

En ocasiones al verlo instalado en distintos proyectos he podido observar picos inusuales de intentos de ataque en comparación con el tráfico habitual de la web, con lo conocida que es o con webs que ni siquiera están aún bien posicionadas en Google.

No obstante es posible que por medio de herramientas como Wappalyzer, BuiltWith o por buscadores de código como publicwww encuentren nuestro WordPress entre otros muchos para probar ataques de fuerza bruta por si hay suerte.

Sin embargo, investigando el tema he encontrado que no soy el único que ha observado este comportamiento. En los foros oficiales de WordPress.org hay múltiples reportes de usuarios con experiencias similares:

Fake login attempts? - Usuario reporta que los "intentos de login" no generan emails de 2FA, sugiriendo que no son intentos reales.
Fake brute force login lockout attempts - Usuario reporta que tras desinstalar el plugin, los ataques con su username exacto cesaron inmediatamente.
FAKE ATTEMPTS, DONT INSTALL - Usuario reporta más ataques después de cambiar la URL de login.
Incredibly intrusive and annoying - Usuario reporta 25.000 "falsos positivos" en un día.

Poniendo a prueba a Limit Login Attempts en un entorno controlado

Como podéis observar en mi página de acceso, no tengo una forma de acceder convencional. Tengo implementada una protección a nivel de servidor con htpasswd, que es una capa de seguridad que actúa antes de que WordPress procese ninguna petición.

Decidí hacer este tipo de implementación debido a varios factores.

Si falla la contraseña o no entra es un código de respuesta 401

Google reacciona a estos códigos de respuesta reduciendo el rastreo en estas zonas y no indexándolo. Por lo que al final no gastará Crawl Budget y tampoco corremos riesgo de que lo indexe.

Es una capa extra de seguridad que actúa antes de WordPress

Esto es clave para entender el problema. Cuando tienes protección htpasswd:

La petición llega al servidor (Apache/Nginx).
El servidor pide usuario y contraseña antes de ejecutar PHP.
Si falla, devuelve 401 y WordPress nunca se entera.
Si acierta, entonces pasa a WordPress.

Esto significa que ningún plugin de WordPress debería poder detectar intentos fallidos en este escenario, porque PHP ni siquiera se ejecuta cuando alguien falla la autenticación del servidor.

Además, tanto el usuario como la contraseña los he generado de más de 18 caracteres con caracteres especiales:

Teniendo en cuenta la siguiente infografía de Hive Systems, romper este usuario y contraseña costaría más de 438 billones de años en averiguarlos. Teniendo en cuenta que necesitas combinar ambas a la vez, el número de años necesarios para romper esa seguridad es astronómico.

Infografía Hive Systems sobre seguridad de contraseñas

Por si fuera poco, además durante este tiempo también he capado el acceso a las que no son mis IP de confianza una vez aciertas la contraseña.

El resultado inexplicable

Por lo que sería remotamente improbable que, con todas estas capas de protección, siguiese teniendo intentos de acceso al panel de WordPress por medio del /wp-admin.

Sin embargo, Limit Login Attempts Reloaded reportaba lo siguiente:

Reportes sospechosos de Limit Login Attempts

Además, curiosamente intentaban acceder con el mismo nombre de usuario que tengo registrado en el WordPress (que, sin los caracteres especiales que les tengo añadidos por seguridad) y que no se puede ver en todo el front ni tengo ningún plugin que comprometa dicha información.

De hecho, ni siquiera aparecen los registros de esos supuestos usuarios que intentan acceder en los Logs que ofrece la herramienta:

¿Qué explicaciones da el fabricante?

Para ser justos, el fabricante tiene un artículo explicando por qué los ataques podrían parecer falsos. Sus argumentos incluyen:

IPs compartidas: Tu hosting comparte IP con otros sitios que ya están siendo atacados.
WHOIS: Los dominios nuevos se registran públicamente y son escaneados.
xmlrpc.php: Aunque cambies la URL de login, xmlrpc.php sigue expuesto.

Estas explicaciones son técnicamente válidas para muchos casos. Sin embargo, no explican mi escenario específico:

Mi /wp-admin está protegido a nivel de servidor, no de WordPress.
El plugin no debería detectar nada porque PHP no se ejecuta en peticiones fallidas.
Los "ataques" usaban mi username exacto, que no es público.
Los logs del plugin estaban vacíos mientras reportaba ataques.

Conclusión y recomendación

No puedo afirmar con certeza absoluta que este plugin genere falsos positivos intencionadamente para fomentar la compra de la versión premium. Sin embargo, la evidencia que he recopilado, junto con los múltiples reportes de otros usuarios en los foros oficiales de WordPress, genera suficientes dudas como para recomendar precaución.

Mi recomendación: no depender de plugins de terceros para propósitos críticos de seguridad. Especialmente cuando existen alternativas más robustas a nivel de servidor.