En un sitio WordPress dejado con su configuración por defecto, la página de acceso es probablemente el recurso más solicitado del servidor, no por visitantes reales, sino por bots que prueban continuamente combinaciones de credenciales. Esta actividad, llamada ataque de fuerza bruta, aprovecha que la URL de acceso es idéntica en millones de instalaciones de WordPress en todo el mundo. La buena noticia es que un puñado de medidas sencillas basta para descartar la gran mayoría de estos intentos, sin necesidad de conocimientos avanzados.

Por qué esta amenaza afecta tanto a WordPress

WordPress hace funcionar una parte muy importante de los sitios web del mundo, lo que lo convierte en un objetivo predilecto para scripts automatizados que no apuntan a un sitio concreto, sino que rastrean todo internet buscando instalaciones mal protegidas. Una parte significativa de estos intentos de acceso utiliza contraseñas ya comprometidas en filtraciones de datos en otros lugares de la web, lo que hace especialmente arriesgado reutilizar una contraseña entre varios servicios para una cuenta de administrador.

Cambiar el nombre de usuario admin

Si tu cuenta de administrador principal todavía se llama admin, la mitad del trabajo de un atacante ya está hecho: solo le queda adivinar la contraseña. WordPress no permite renombrar un usuario existente, pero es sencillo crear un nuevo usuario con un nombre distinto y permisos de administrador, transferir los contenidos existentes a esa nueva cuenta y luego eliminar la antigua cuenta admin.

Limitar el número de intentos de acceso

Sin restricción, un bot puede probar varios miles de combinaciones por minuto. Un plugin de limitación de intentos, como Limit Login Attempts Reloaded o funciones equivalentes integradas en suites de seguridad más amplias, bloquea temporalmente una dirección IP tras un número definido de fallos, normalmente cinco intentos seguidos de un bloqueo de unos minutos a varias horas. Esta única medida basta para volver un ataque automatizado demasiado lento como para resultar rentable.

Añadir doble autenticación

WordPress no ofrece de forma nativa autenticación de dos factores en su núcleo, esta función debe añadirse mediante un plugin dedicado. Una vez activada, exige, además de la contraseña, un código temporal generado por una aplicación en el móvil, lo que hace inútil una contraseña robada por sí sola para un atacante. Esta protección debería exigirse a todas las cuentas con permisos de administrador o editor, no solo a la cuenta principal.

Cambiar la URL de acceso

Los bots apuntan sistemáticamente a las direcciones por defecto, wp-login.php y wp-admin. Un plugin como WPS Hide Login permite sustituir esta dirección por una URL personalizada que solo tú conoces. Esta medida no sustituye a las protecciones anteriores, pero reduce considerablemente el volumen de intentos automatizados que realmente llegan a tu servidor, ya que la mayoría de los bots nunca buscará más allá de una dirección por defecto ausente.

Desactivar XML-RPC si no lo utilizas

Este archivo, presente por defecto en WordPress, permite conexiones remotas usadas por ciertas aplicaciones móviles u herramientas de publicación externas. También constituye un vector de ataque adicional, en particular para intentos de acceso agrupados que a veces eluden las limitaciones habituales. Si ninguna herramienta de tu pyme depende de él, desactivarlo a nivel de servidor o mediante un plugin cierra esta puerta sin ninguna pérdida funcional.

Apoyarte en tu proveedor de hosting

Muchos proveedores de hosting gestionado ya ofrecen un cortafuegos de aplicaciones web y un filtrado de intentos sospechosos a nivel de red, antes incluso de que la solicitud llegue a WordPress. Comprobar qué ofrece realmente tu hosting actual a veces revela que parte de la protección ya está en marcha, y que el esfuerzo necesario del lado del sitio se limita a las medidas complementarias descritas aquí.

Puntos a verificar antes de publicar: confirmar que los plugins mencionados (Limit Login Attempts Reloaded, WPS Hide Login) siguen mantenidos y disponibles en el directorio oficial de WordPress en el momento de la publicación, y comprobar que la ausencia de autenticación de dos factores nativa en el núcleo de WordPress sigue siendo exacta en esa fecha.