Cómo blindar wp-login.php frente a la fuerza bruta

Si has llegado hasta aquí es probable que tu proveedor de alojamiento te haya avisado de un consumo de CPU anormal, que estés recibiendo decenas de correos de «restablecer contraseña» que tú no has pedido, o que un plugin te esté avisando de intentos fallidos de acceso. La primera buena noticia es que todo eso significa, casi siempre, que todavía no han entrado. En este artículo tienes, por orden de eficacia real, qué medidas frenan un ataque de fuerza bruta contra wp-login.php, cuáles son solo ruido, y cómo comprobar si en algún momento ya consiguieron acceder.

Cómo son de verdad estos ataques: no hay nadie tecleando

La imagen de alguien delante de un teclado probando contraseñas no tiene nada que ver con lo que le pasa a tu web. Lo que hay al otro lado es un programa que recorre listas de dominios y lanza peticiones POST contra /wp-login.php desde cientos o miles de direcciones IP distintas, normalmente ordenadores y servidores ajenos previamente comprometidos.

Esos programas trabajan de dos maneras. La primera es la fuerza bruta clásica: prueban usuarios evidentes (admin, administrador, el nombre del dominio, el nombre de la empresa) contra diccionarios de contraseñas habituales. La segunda, más peligrosa, es el relleno de credenciales: usan pares de correo y contraseña filtrados de otras plataformas y confían en que tú hayas repetido la misma contraseña en tu WordPress. La segunda funciona muchísimo mejor que la primera, y contra ella no sirve de nada limitar intentos si la contraseña acierta a la primera.

Entender esto cambia las prioridades: la mayoría del daño colateral (web lenta, hosting saturado) viene del volumen de peticiones, pero el riesgo real de que entren viene de la contraseña. Son dos problemas distintos y se resuelven con medidas distintas.

Señales de que lo estás sufriendo ahora mismo

Antes de tocar nada, confirma que es esto y no otra cosa. Las señales típicas:

La web va lenta a rachas, sin patrón claro, y el panel de administración tarda más que la parte pública.
Tu proveedor te avisa de que superas el límite de procesos o de CPU de tu plan.
Recibes correos de recuperación de contraseña que nadie ha solicitado.
Un plugin de seguridad te manda avisos de bloqueo cada pocos minutos.

La confirmación seria está en los registros del servidor. En un alojamiento con cPanel los tienes en Métricas > Accesos sin procesar, y por SSH suelen estar en ~/access-logs/ o en /home/usuario/logs/. Con el fichero descargado y descomprimido, dos órdenes te dan el diagnóstico:

grep "POST /wp-login.php" access.log | wc -l
grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

La primera te dice cuántos intentos hay. La segunda te dice desde qué direcciones IP llegan y cuántos por cada una. Si ves miles de peticiones repartidas entre cientos de IP distintas, tienes un ataque distribuido y bloquear IP una a una no te va a servir. Si tu alojamiento es compartido y no encuentras los registros, tienes más detalle en la guía sobre cómo leer los registros de acceso de tu web sin ser técnico.

Limitar intentos: la medida que más rinde por menos esfuerzo

Si solo vas a hacer una cosa, haz esta. Limitar intentos consiste en que, tras equivocarse varias veces, esa IP quede bloqueada durante un tiempo. No impide que acierten la contraseña a la primera, pero corta en seco la fuerza bruta por diccionario y, sobre todo, reduce muchísimo el consumo de recursos.

En WordPress lo resuelve un plugin ligero como Limit Login Attempts Reloaded, o el módulo equivalente de cualquier suite de seguridad que ya tengas instalada. No instales dos: se pisan y acabas bloqueándote tú. Una configuración razonable es cuatro intentos permitidos, veinte minutos de bloqueo, y bloqueo largo (varias horas) tras repetir la falta. Lo encontrarás en Ajustes dentro del menú del propio plugin.

Si tu alojamiento ofrece protección a nivel de servidor, actívala también: filtrar antes de que la petición llegue a PHP es mucho más eficiente que hacerlo dentro de WordPress. Pregunta a tu proveedor si tienen fail2ban, ModSecurity o un cortafuegos de aplicación. Si estás delante de Cloudflare, una regla de límite de peticiones sobre la ruta /wp-login.php hace el mismo trabajo sin gastar ni un ciclo de tu servidor.

Cambiar la URL de acceso: cuándo ayuda y cuándo es puro teatro

Mover el acceso a una dirección como /entrada-privada/ con un plugin tipo WPS Hide Login tiene un efecto muy concreto y muy limitado: los programas automáticos que solo saben ir a /wp-login.php se estrellan contra un 404 y tu servidor deja de gastar recursos en ellos. Como medida antirruido, funciona.

Como medida de seguridad, no. No detiene a nadie que se moleste treinta segundos en mirar, y arrastra efectos secundarios que conviene conocer:

Si la olvidas, recuperar el acceso pasa por desactivar el plugin renombrando su carpeta por FTP.
Los plugins de caché a veces guardan la página de acceso y la sirven a destiempo.
Cualquier herramienta que se conecte a tu web (una aplicación móvil, un servicio de copias) puede dejar de funcionar.
No protege xmlrpc.php ni la API REST, que siguen exactamente donde estaban.

Resumen honesto: hazlo si te molesta el ruido en los registros, pero no lo cuentes como protección y no lo hagas en lugar de lo que viene a continuación.

Contraseñas y segundo factor: la barrera que sí detiene el ataque

Esta es la parte que de verdad decide si entran o no. Una contraseña larga, única y generada al azar hace que la fuerza bruta sea irrelevante, y un segundo factor hace que una contraseña filtrada tampoco sirva.

Lo mínimo aceptable, por orden:

Ninguna cuenta de administrador se llama admin ni igual que el dominio.
Cada administrador tiene una contraseña distinta, generada por un gestor de contraseñas, que no se usa en ningún otro sitio.
Todas las cuentas con permisos de administrador o editor tienen segundo factor activado.
Las cuentas de personas que ya no colaboran contigo están eliminadas, no solo desactivadas.

Para el segundo factor, los plugins Two Factor o WP 2FA añaden códigos temporales de aplicación autenticadora sin complicar el día a día. Ten en cuenta un detalle que se pasa por alto: las contraseñas de aplicación de WordPress (en Usuarios > Perfil) se saltan el segundo factor por diseño, así que revisa que no haya ninguna creada que no reconozcas. Tienes el procedimiento completo en el artículo sobre contraseñas y verificación en dos pasos en WordPress.

Bloqueo por país o por IP y sus efectos secundarios

Si tu negocio solo vende en España, bloquear el acceso al panel desde el resto del mundo parece obvio. Y ayuda, pero con matices que conviene tener claros antes.

La versión más sólida es restringir wp-login.php a las direcciones IP desde las que trabajáis. En un servidor Apache moderno se hace en el .htaccess de la raíz:

<Files wp-login.php>
    Require ip 203.0.113.25
    Require ip 198.51.100.0/24
</Files>

Sustituye esas direcciones por las tuyas reales. Si tu servidor usa nginx o LiteSpeed en modo nativo, esta directiva puede no aplicarse: pregunta a tu proveedor antes de darla por buena, y comprueba después abriendo la página de acceso desde los datos móviles.

Los efectos secundarios son reales: casi ninguna conexión doméstica tiene IP fija, si viajas te dejas fuera a ti mismo, y si trabajas desde el móvil cambiarás de IP cada poco. El bloqueo por país en Cloudflare es más cómodo pero más impreciso, y castiga también a proveedores legítimos. Mi recomendación práctica: usa esto si tenéis oficina con IP fija; si no, quédate con limitar intentos y segundo factor, que no dependen de dónde estés.

No olvides XML-RPC ni la API REST: la misma puerta por otro pasillo

Aquí es donde fallan la mitad de los blindajes. Puedes tener wp-login.php cerrado a cal y canto y seguir permitiendo intentos de acceso por otras dos vías.

xmlrpc.php es la primera. Su método system.multicall permite probar muchas combinaciones de usuario y contraseña en una sola petición, lo que hace que el contador de «intentos fallidos» ni se entere. Si no usas la aplicación móvil de WordPress ni Jetpack ni publicación remota, esta puerta te sobra: en la guía para desactivar XML-RPC en WordPress tienes cómo cerrarla sin romper nada.

La segunda es la API REST, que por defecto publica la lista de usuarios. Compruébalo tú mismo abriendo en el navegador:

https://tudominio.com/wp-json/wp/v2/users

Si te devuelve nombres de usuario, acabas de regalarle al atacante la mitad del trabajo: ya no tiene que adivinar el usuario, solo la contraseña. Lo mismo pasa con https://tudominio.com/?author=1, que suele redirigir revelando el identificador. Casi todas las suites de seguridad tienen una casilla para bloquear la enumeración de usuarios; actívala. Este tipo de detalles, junto con los permisos del servidor y las cabeceras, forman parte de una configuración segura del alojamiento web que conviene revisar entera al menos una vez.

Qué hacer si sospechas que ya han entrado

Hay cuatro señales que ya no son sospecha sino evidencia: un usuario administrador que no reconoces, tu correo de administración cambiado, un plugin instalado que nadie ha instalado, o contenido y redirecciones que no has puesto tú.

Si ves alguna, el orden importa:

No borres nada todavía. Los registros y los ficheros modificados son la única forma de saber por dónde entraron. Si los eliminas, limpiarás la web y volverán a entrar por el mismo sitio.
Cambia la contraseña de todos los administradores, la del panel de alojamiento y la del FTP.
Invalida las sesiones abiertas: en Usuarios > Perfil tienes el botón Cerrar sesión en el resto de sitios.
Cambia las claves de seguridad de wp-config.php generando unas nuevas en https://api.wordpress.org/secret-key/1.1/salt/ y sustituyendo el bloque completo. Esto expulsa a cualquiera que tuviera una sesión válida.
Revisa Usuarios > Todos los usuarios filtrando por Administrador, y comprueba si hay ficheros PHP donde no debería haberlos, por ejemplo dentro de wp-content/uploads/.

Y ahora la parte honesta. Si solo has visto intentos fallidos, todo lo anterior lo puedes hacer tú en una tarde y no necesitas contratar a nadie. Pero si ya hay un administrador desconocido o ficheros extraños, el problema deja de ser el acceso y pasa a ser una web comprometida: ahí hay que averiguar qué se ha tocado, si hay puertas traseras y si se han filtrado datos de clientes, y eso ya no se arregla cambiando contraseñas. En ese caso, para en seco y busca ayuda profesional antes de restaurar una copia de seguridad encima, porque restaurar sin saber la fecha real de la intrusión suele significar restaurar el problema.

Si prefieres no estar pendiente de los registros ni descubrir el problema por un correo de tu proveedor, Pulse vigila los accesos a tu panel las 24 horas desde 19 euros al mes: te avisa cuando aparece un administrador nuevo, cuando cambian ficheros del núcleo o cuando los intentos de acceso se disparan, que es justo el momento en el que aún se puede evitar el susto.

Seguir leyendo en esta sección

Ver todo en Accesos y contraseñas → · Mapa completo del sitio