Cómo prevenir ataques de fuerza bruta en WordPress (9 capas de protección)

Si tu sitio de WordPress está en línea, probablemente esté siendo atacado ahora mismo.

Los bots automatizados escanean Internet continuamente, probando /wp-login.php en cada sitio de WordPress que encuentran. Prueban primero los inicios de sesión de "admin", luego una lista de las contraseñas más comunes.

Un sitio sin protección recibe cientos de estos intentos cada día, de forma silenciosa, sin ningún signo visible.

Lo que es peor: los ataques fallidos no son gratuitos. Cada intento de inicio de sesión activa un proceso PHP en tu servidor.

Suficientes intentos simultáneos y tu plan de hosting alcanza sus límites.

Los visitantes reales empiezan a ver tiempos de carga lentos o páginas de error. Algunos hosts limitan tu cuenta automáticamente. Esto sucede incluso cuando ningún atacante logra entrar.

Un ataque exitoso es un problema diferente. El acceso completo de administrador significa cambios de contenido, malware inyectado en tus archivos de tema, cuentas de respaldo creadas, spam SEO incrustado en tus publicaciones o datos de clientes expuestos.

La recuperación de una brecha exitosa lleva horas en el mejor de los casos; días si no tienes una copia de seguridad limpia.

En esta publicación, te daré las mejores maneras de defender tu sitio de ataques de fuerza bruta.

Aquí están los puntos clave:

• Incluso los ataques de fuerza bruta fallidos perjudican tu sitio. Agotan los trabajadores de PHP, ralentizan los tiempos de carga y pueden activar la limitación del hosting antes de que se adivine correctamente una sola contraseña.
• El credential stuffing no es lo mismo que la fuerza bruta. Los atacantes utilizan contraseñas reales filtradas de otras brechas, lo que significa que una contraseña segura por sí sola no es suficiente si tus usuarios reutilizan credenciales.
• WordPress no tiene protección contra fuerza bruta incorporada. La limitación de inicios de sesión, la autenticación de dos factores y la funcionalidad de WAF requieren un plugin o una configuración del servidor.
• La autenticación de dos factores es el paso de mayor retorno de esta lista. Detiene tanto la fuerza bruta como el credential stuffing, incluso cuando una contraseña es correcta.
• El método system.multicall de XML-RPC elude la mayoría de las defensas de la página de inicio de sesión. Deshabilitarlo cierra una superficie de ataque separada que los plugins de limitación de velocidad no cubren.
• Cambiar tu URL de inicio de sesión reduce el volumen de ataques, pero no es una defensa principal. Trátalo como una fricción, no como protección.
• Una copia de seguridad que nunca has restaurado es una copia de seguridad que en realidad no tienes. Prueba tu proceso de restauración trimestralmente antes de necesitarlo bajo presión.
• Más plugins de seguridad no significan más seguridad. Un plugin bien configurado supera a cuatro mal configurados, lo que puede crear conflictos y sobrecarga.

Tabla de Contenidos

¿Qué es un ataque de fuerza bruta?

La mayoría de la gente se imagina un ataque de fuerza bruta como un bot que prueba contraseñas aleatorias hasta que una funciona. Eso sucede, pero no es la única versión de este ataque, y ya ni siquiera es la más común.

Fuerza bruta clásica vs. Inyección de credenciales

Fuerza bruta clásica es cuando un software automatizado prueba todas las combinaciones posibles de caracteres hasta que encuentra una contraseña que funciona.

Contra una contraseña larga y aleatoria, esto es poco práctico. Tardaría más en descifrar una contraseña aleatoria de 16 caracteres que el tiempo que le queda al sol para quemarse.

Inyección de credenciales es diferente y más peligrosa.

Los atacantes compran o descargan bases de datos filtradas de otras brechas de datos: direcciones de correo electrónico emparejadas con contraseñas de servicios comprometidos. Luego prueban esos pares en sitios de WordPress.

Si uno de tus usuarios se registró con el mismo correo electrónico y contraseña que usa en todas partes, la inyección de credenciales podría obtener acceso a ellos e iniciar sesión en el primer intento.

Por eso "tengo una contraseña segura" no protege completamente a tus usuarios. Tu contraseña puede ser segura. La suya podría no serlo.

Los ataques de diccionario se sitúan entre los dos. En lugar de todas las combinaciones posibles, prueban una lista curada de contraseñas comunes, patrones conocidos y variaciones de palabras reales. Más rápido que la fuerza bruta real, más dirigido que la adivinación aleatoria.

El multiplicador XML-RPC

WordPress incluye un archivo llamado xmlrpc.php, originalmente creado para la publicación remota y las integraciones de API. Acepta un método llamado system.multicall que permite que una solicitud HTTP pruebe miles de combinaciones de nombre de usuario/contraseña en una sola llamada.

Esto es importante porque la mayoría de los plugins de limitación de inicio de sesión supervisan /wp-login.php. Un bot que usa xmlrpc.php elude por completo esa protección. Limitar la velocidad de tu página de inicio de sesión mientras dejas XML-RPC abierto es como cerrar la puerta principal y dejar la ventana sin cerrar.

Si no estás usando XML-RPC, cerrarlo es uno de los pasos de mayor retorno de esta lista. La capa 5 cubre exactamente cómo.

Lo que te cuesta incluso un ataque fallido

Un ataque de fuerza bruta que nunca adivina una sola contraseña correcta todavía te cuesta algo real.

Cada intento de inicio de sesión es una solicitud HTTP. Cada solicitud inicia un proceso PHP. En el alojamiento compartido, tu plan viene con un número finito de trabajadores PHP concurrentes.

Un ataque de alto volumen llena esos trabajadores con intentos de inicio de sesión en lugar de servir a tus visitantes reales. El resultado son tiempos de carga lentos, tiempos de espera y, en casos graves, una suspensión temporal del alojamiento que no viste venir.

También entierra eventos de seguridad legítimos en ruido de registro. Si un atacante finalmente logra entrar, los registros de intentos fallidos que habrían señalado actividad inusual ya están llenos de miles de entradas. Estás buscando una aguja en un pajar.

Las protecciones a nivel de plugin reducen el daño. Las protecciones a nivel de servidor y de borde lo eliminan. Esa es la razón principal por la que esta guía está estructurada en capas en lugar de una lista.

Cómo prevenir ataques de fuerza bruta en WordPress

No existe una única configuración que haga que tu sitio sea inmune. Lo que funciona son las capas: cada una atrapa lo que la anterior se pierde.

Tus credenciales detienen a la mayoría de los bots automatizados. La limitación de tasa detiene a los que se cuelan. Un WAF detiene el volumen antes de que llegue a tu servidor. Las copias de seguridad cubren el escenario en el que todo lo demás falla.

Las capas inferiores están ordenadas por impacto y facilidad de implementación. Empieza por la parte superior. Llega tan lejos como tu configuración de alojamiento lo permita. Incluso las tres primeras capas reducen drásticamente tu exposición.

Esto es lo que debes hacer:

• Capa 1: Credenciales: cambia el nombre de usuario administrador predeterminado, usa contraseñas únicas en cada cuenta y habilita la autenticación de dos factores para todos los administradores
• Capa 2: Limitar intentos de inicio de sesión: limita los intentos fallidos de inicio de sesión a través de un plugin o, para una protección más sólida, a través de Cloudflare o limitación de tasa a nivel de servidor
• Capa 3: Cambiar la URL de inicio de sesión predeterminada: mueve la dirección a la que apuntan la mayoría de los bots, reduciendo el volumen de ataques automatizados a tu formulario de inicio de sesión
• Capa 4: Añadir CAPTCHA: filtra envíos de bots automatizados en el formulario de inicio de sesión; más efectivo cuando se combina con la limitación de tasa en lugar de usarse solo
• Capa 5: Deshabilitar o restringir XML-RPC: cierra una superficie de ataque separada que permite a los atacantes probar miles de contraseñas en una sola solicitud HTTP, eludiendo las defensas de la página de inicio de sesión
• Capa 6: Firewall de aplicaciones web: bloquea el tráfico malicioso y las IPs maliciosas conocidas antes de que lleguen a tu página de inicio de sesión; los WAF a nivel de borde como Cloudflare evitan el agotamiento de recursos durante ataques de alto volumen
• Capa 7: Fortalecimiento a nivel de servidor: restringe wp-login.php por IP, implementa Fail2ban y usa SFTP con autenticación de clave SSH; para propietarios de servidores VPS y dedicados
• Capa 8: Mantén todo actualizado: aplica parches a las vulnerabilidades que los atacantes explotan para establecer un punto de apoyo antes de forzar su camino más adentro
• Capa 9: Haz una copia de seguridad de tu sitio: la capa de defensa final; una copia de seguridad externa probada con una ruta de restauración funcional es la única garantía de que un ataque exitoso no acabe con tu sitio

Capa 1: Empieza con tus credenciales

Cada herramienta de fuerza bruta automatizada comienza con el nombre de usuario "admin" y las contraseñas más comunes. Eliminar ambos de tu sitio lleva quizás cinco minutos y elimina la mayoría de los intentos de ataque automatizados de inmediato.

No es una defensa completa, pero es el retorno de tiempo más rápido que encontrarás en esta guía.

Usa un nombre de usuario administrador no predeterminado

Cuando WordPress se instaló por primera vez en tu sitio, sugirió "admin" como nombre de usuario predeterminado. Muchos sitios nunca lo cambian. Los atacantes lo saben, y cada herramienta de fuerza bruta comienza ahí.

Usar un nombre de usuario diferente obliga a un atacante a adivinar dos incógnitas en lugar de una. No es una mejora drástica contra un ataque dirigido sofisticado, pero elimina la gran mayoría de los bots automatizados que nunca superan la suposición de "admin".

Para comprobar tu nombre de usuario actual, ve a Usuarios » Perfil en wp-admin. El campo de nombre de usuario se encuentra en la configuración de Nombre.

WordPress no te permite cambiar tu nombre de usuario directamente, pero puedes crear una nueva cuenta de administrador con un nombre de usuario diferente, transferir la propiedad de tu contenido y eliminar la antigua cuenta de “admin”.

Los usuarios de WP-CLI pueden hacer esto en un solo comando:

wp user update 1 --user_login=yourname

Usa contraseñas seguras y únicas para cada cuenta

Cada cuenta de administrador en tu sitio necesita su propia contraseña única.

El relleno de credenciales funciona probando pares de nombre de usuario/contraseña conocidos de otras brechas. Si un usuario reutilizó su contraseña de correo electrónico en varios sitios y esa contraseña se filtró en otro lugar, el relleno de credenciales podría iniciar sesión al primer intento.

WordPress incluye un medidor de fortaleza de contraseña incorporado que marca las contraseñas débiles en la pantalla de perfil. Eso detiene las peores opciones, pero no impone una longitud mínima ni evita la reutilización.

Para un mayor control, Password Policy Manager te permite establecer requisitos de contraseña en todo el sitio y forzar restablecimientos para las cuentas que no los cumplan.

Habilita la autenticación de dos factores

Con la 2FA habilitada, una contraseña correcta no es suficiente para iniciar sesión. El atacante también necesita un código sensible al tiempo de un dispositivo físico que no tiene.

Eso detiene los ataques clásicos de fuerza bruta, relleno de credenciales y diccionario. Incluso si un atacante tiene tu contraseña exacta de una brecha de datos, no puede iniciar sesión sin el segundo factor.

El núcleo de WordPress no incluye 2FA. Necesitas un plugin.

WP 2FA es gratuito, se mantiene activamente y es fácil de configurar. Admite aplicaciones de autenticación como Google Authenticator, Authy y 1Password.

miniOrange 2FA y el plugin Two Factor son otras opciones ampliamente utilizadas con flexibilidad de configuración adicional.

Las claves de acceso son la alternativa más nueva. Utilizan el estándar WebAuthn y son resistentes al phishing por diseño: no hay código que interceptar, SMS que suplantar o aplicación de autenticación que comprometer. El soporte de plugins aún está madurando, pero si tu configuración lo admite, las claves de acceso merecen ser consideradas.

Aplica 2FA a todas las cuentas de administrador del sitio. No solo a la tuya. Una cuenta de administrador desprotegida es todo lo que un atacante necesita.

Capa 2: Limita los intentos de inicio de sesión

Por defecto, WordPress permite intentos de inicio de sesión ilimitados. Un bot puede probar diez mil contraseñas en el tiempo que tardas en prepararte un café.

La limitación de velocidad corta eso después de un puñado de intentos, bloqueando la IP infractora antes de que se acerque a una credencial correcta.

Limitación de inicio de sesión basada en plugins

Los plugins de limitación de inicio de sesión funcionan rastreando los intentos fallidos por dirección IP. Después de un número determinado de fallos, el plugin bloquea esa IP durante un período definido. El bot del atacante sigue adelante.

Limit Login Attempts Reloaded es la opción gratuita más utilizada, con una pantalla de configuración sencilla y sin sobrecarga.

Wordfence incluye la limitación como parte de su conjunto de funciones más amplio, lo que hace que valga la pena considerarlo si deseas un solo plugin que cubra múltiples capas de seguridad.

Para la mayoría de los sitios, 5-10 intentos fallidos antes de un bloqueo temporal es un punto de partida razonable.

Umbrales más bajos aumentan la seguridad, pero podrían generar dolores de cabeza de soporte. Las oficinas corporativas, universidades y redes móviles a menudo comparten una única IP entre cientos de usuarios. Una persona que escribe mal su contraseña tres veces bloquea a todos los demás.

Prueba tu umbral en función de cómo inician sesión tus usuarios en realidad.

Una limitación que vale la pena conocer: los complementos de capa de aplicación todavía invocan PHP en cada solicitud que procesan. Bajo un ataque de alto volumen real, tu servidor todavía está recibiendo todo ese tráfico.

El complemento evita que el atacante tenga éxito, pero no detiene el consumo de recursos. Eso es lo que aborda la siguiente sección.

Cuándo mover la protección a capas superiores

El nivel gratuito de Cloudflare te permite crear reglas personalizadas de limitación de velocidad dirigidas específicamente a /wp-login.php y /xmlrpc.php.

El tráfico se filtra en el borde de Cloudflare antes de que llegue a tu servidor. Tus trabajadores de PHP permanecen libres para los visitantes reales.

Esta es la mejora más accesible desde la protección a nivel de complemento, y no cuesta nada.

Capa 3: Cambia la URL de inicio de sesión predeterminada

La mayoría de los bots automatizados se dirigen a /wp-login.php porque ahí es donde WordPress pone el formulario de inicio de sesión por defecto. Moverlo a una URL personalizada significa que la mayoría de los bots nunca lo encuentran. Encuentran un 404, marcan tu sitio como un callejón sin salida y se van.

Esta es una capa de fricción, no una defensa principal. Un atacante decidido que se dirige específicamente a tu sitio puede encontrar una URL de inicio de sesión personalizada por otros medios.

Pero reducir el volumen de ataques automatizados tiene un valor real:

• Menos intentos de inicio de sesión fallidos
• Menos ruido en el registro de actividad
• Menos sobrecarga de procesos PHP por parte de los complementos de limitación que procesan solicitudes fallidas

El principal riesgo es perder la URL. Si olvidas tu ruta de inicio de sesión personalizada y tu host no ofrece acceso de emergencia a wp-admin, te quedarás bloqueado de tu propio sitio.

Antes de realizar este cambio, guarda la URL personalizada en tu gestor de contraseñas y confirma el método de acceso de emergencia de tu host. Algunos hosts ofrecen acceso a phpMyAdmin o un restablecimiento de inicio de sesión asistido por soporte.

WPS Hide Login se encarga de esto con una configuración mínima: instálalo, establece tu ruta personalizada y guarda.

Una adición que hace que este paso sea más efectivo: crea una regla de Cloudflare que devuelva un 403 en la ruta original /wp-login.php después de haberla movido.

Sin esa regla, la URL antigua todavía existe y responde, lo que significa que un escáner persistente aún puede encontrarla sondeando rutas comunes. Bloquear la URL antigua en el borde cierra esa brecha.

Capa 4: Añade CAPTCHA al formulario de inicio de sesión

CAPTCHA detiene a los bots automatizados de enviar formularios de inicio de sesión al requerir prueba de interacción humana. Un script que golpea tu página de inicio de sesión miles de veces por hora no puede resolver un desafío visual o conductual como lo haría una persona.

Para la mayoría de los sitios, agregar CAPTCHA al formulario de inicio de sesión reduce significativamente el volumen de envíos automatizados.

Ten en cuenta que no es inquebrantable. Existen servicios de resolución de CAPTCHA: humanos reales pagados fracciones de céntimo para resolver desafíos a escala o modelos de aprendizaje automático entrenados para descifrar formatos de CAPTCHA más antiguos.

Frente a un atacante específico y bien financiado, CAPTCHA es un obstáculo. Frente a los bots automatizados responsables de la gran mayoría del tráfico de fuerza bruta, es efectivo.

Las tres opciones que vale la pena considerar adoptan un enfoque diferente.

1. Google reCAPTCHA v3 se ejecuta de forma invisible en segundo plano, evaluando el comportamiento del usuario y marcando las solicitudes sospechosas sin pedir nada a los usuarios.
2. hCaptcha adopta una postura centrada en la privacidad y es una alternativa directa de reemplazo.
3. Cloudflare Turnstile es gratuito, no interrumpe a la mayoría de los usuarios y no envía datos de comportamiento a Google.

De las tres, Turnstile es mi recomendación actual para configuraciones nuevas. Las concesiones de privacidad son mejores y la experiencia del usuario es más limpia.

Wordfence incluye opciones de CAPTCHA. Si ya lo estás usando, comprueba si su CAPTCHA integrado cubre tu formulario de inicio de sesión antes de añadir un plugin separado.

Capa 5: Deshabilita o restringe XML-RPC

XML-RPC fue la API original de publicación remota de WordPress, creada para una época anterior a la existencia de la API REST. La mayoría de los sitios ya no la utilizan. Dejarla habilitada proporciona a los atacantes una superficie de ataque separada que elude la mayoría de las defensas de la página de inicio de sesión que has configurado hasta ahora.

Xmlrpc.php acepta un método llamado system.multicall que agrupa miles de intentos de inicio de sesión en una sola solicitud HTTP.

Un plugin de limitación de velocidad que vigila /wp-login.php no lo verá. Tu CAPTCHA no se activará. El ataque llega por debajo de tus defensas porque está dirigido a una puerta diferente.

Antes de deshabilitarlo, comprueba si lo estás utilizando realmente. Jetpack se conecta a WordPress.com a través de XML-RPC. Algunos flujos de trabajo de publicación móvil antiguos dependen de él.

Si no usas Jetpack o no publicas desde una aplicación móvil, probablemente no lo necesites.

Plugins de seguridad como Wordfence tienen un interruptor de un clic en la sección de configuración de inicio de sesión.

El plugin Disable XML-RPC-API es una alternativa ligera si prefieres no instalar una suite de seguridad completa.

En Nginx o Apache, puedes bloquear xmlrpc.php a nivel de servidor para que la solicitud nunca llegue a PHP.

Si necesitas XML-RPC para Jetpack u otra integración, la solución específica es bloquear system.multicall en lugar de todo el endpoint. Una regla de WAF de Cloudflare puede hacer esto sin romper la funcionalidad legítima de XML-RPC.

Restringir el acceso a xmlrpc.php a direcciones IP específicas es otra opción para integraciones con fuentes conocidas y estables.

La API REST es el reemplazo moderno para nuevas integraciones. Si estás construyendo algo que habría usado XML-RPC, constrúyelo contra la API REST en su lugar.

Capa 6: Usa un firewall de aplicaciones web

Un Firewall de Aplicaciones Web (WAF) se sitúa entre el tráfico entrante y tu sitio de WordPress, inspeccionando las solicitudes y bloqueando las maliciosas antes de que lleguen a tu página de inicio de sesión.

Cuanto más cerca del borde de la red opere, menos trabajo hará tu servidor bajo ataque. Un WAF basado en plugins detiene los ataques después de que llegan a tu servidor. Un WAF a nivel de borde los detiene antes de que lleguen allí.

WAFs basados en plugins

Los WAF de plugins como Wordfence y MalCare filtran las solicitudes en la capa de aplicación. Mantienen bases de datos de direcciones IP maliciosas conocidas, firmas de bots y patrones de ataque, y bloquean las solicitudes coincidentes antes de que WordPress las procese.

Para sitios en alojamiento compartido donde la configuración del servidor no es accesible, un WAF de plugin es el punto de partida correcto.

La limitación es que su servidor aún recibe cada solicitud que el WAF evalúa. Bajo un ataque a gran escala, PHP todavía se inicia, el plugin todavía se ejecuta y sus recursos de alojamiento aún sufren el impacto. El atacante no entra, pero el costo de los recursos es real.

WAF a nivel de borde

El nivel gratuito de Cloudflare filtra el tráfico en su red global antes de que llegue a su servidor. La gestión de bots, la limitación de velocidad y los desafíos de CAPTCHA de Turnstile operan en el borde.

Su servidor solo ve el tráfico que Cloudflare ya ha examinado. Durante un ataque de fuerza bruta de alto volumen, su sitio permanece rápido para los visitantes reales porque el tráfico del ataque nunca llega.

Sucuri ofrece un WAF administrado con conjuntos de reglas específicos de WordPress y una capa de CDN incluida. Es un servicio de pago, pero el mantenimiento de reglas administradas vale la pena considerarlo para sitios que no tienen un desarrollador que monitoree activamente las configuraciones de seguridad.

Los hosts de WordPress administrados, incluidos WP Engine y Kinsta, incluyen WAF a nivel de infraestructura como parte de su pila de alojamiento. Si está en una de estas plataformas, es probable que ya tenga protección de borde. Confirme con su host qué cubre su WAF específicamente y si hay reglas personalizadas disponibles.

Una configuración de Cloudflare que vale la pena implementar: una regla de firewall personalizada que bloquea todo el tráfico a /wp-admin excepto desde su dirección IP o el rango de IP de su equipo.

Para sitios administrados por un equipo pequeño que inicia sesión desde IPs predecibles o una VPN compartida, este es uno de los pasos individuales más efectivos disponibles. Los bots automatizados no pueden acceder al área de administración en absoluto.

Simplemente confirme que su sitio no utiliza URL de /wp-admin para la funcionalidad orientada al cliente (como las páginas de Mi cuenta de WooCommerce o los inicios de sesión del portal de membresía) antes de habilitar esta regla.

Capa 7: Fortalecimiento a nivel de servidor

Si administra su propio servidor o VPS, puede impulsar la protección por encima de WordPress, bloqueando ataques antes de que toquen PHP o cualquier código de WordPress.

Esta sección es para desarrolladores y propietarios de servidores VPS o dedicados. Si está en alojamiento compartido sin acceso a la configuración del servidor, salte a la Capa 8.

Restringir wp-login.php por IP

Si usted y su equipo siempre inician sesión desde direcciones IP predecibles, como una red de oficina o una VPN compartida, puede restringir /wp-login.php a esas IPs a nivel de servidor. Cada solicitud de cualquier otra IP recibe un 403 antes de que se cargue WordPress.

En Nginx, eso se ve así dentro de su bloque de servidor:

location = /wp-login.php {

allow 203.0.113.10;

deny all;

}

Reemplace la IP con la suya. Agregue varias líneas 'allow' para múltiples IPs. La solicitud de cualquier dirección no listada nunca llega a PHP.

Esto no funciona para sitios de WooCommerce, plataformas de membresía o cualquier configuración donde los clientes inician sesión a través de WordPress. Es más adecuado para sitios de negocios o portafolios con un equipo pequeño y estable de administradores.

Implementar Fail2ban

Fail2ban lee los registros de su servidor y prohíbe automáticamente las direcciones IP que coinciden con los patrones que usted define. Para WordPress, eso significa que una IP que genera entradas de inicio de sesión fallidas repetidas en el registro se agrega a la lista de bloqueo de su firewall, generalmente a través de iptables o nftables, antes de que acumule suficientes intentos como para importar.

Requiere un plugin de integración de WordPress para funcionar: Fail2ban necesita leer los intentos de inicio de sesión fallidos en un formato analizable, y WordPress no los escribe en los registros del servidor por defecto.

WP fail2ban se encarga de esto, escribiendo eventos de autenticación en un formato que Fail2ban puede analizar directamente.

El resultado es una protección que opera en la capa de red: las IP bloqueadas nunca llegan a su servidor web, y mucho menos a WordPress. Combinado con la limitación de velocidad de Nginx en el punto final de inicio de sesión, esta es la configuración no empresarial más estricta disponible.

Use SFTP y claves SSH, no FTP

Los ataques de fuerza bruta no solo se dirigen a su página de inicio de sesión. FTP se ejecuta en el puerto 21 y transmite credenciales en texto plano. Los atacantes escanean los puertos FTP abiertos y ejecutan el mismo enfoque de adivinación de credenciales que utilizan en wp-login.php.

SFTP cifra la conexión. Si su host lo admite, cambie a SFTP y deshabilite FTP por completo. La mayoría de los hosts modernos lo admiten; algunos deshabilitan FTP por defecto.

Para el acceso SSH a su servidor, utilice la autenticación basada en claves en lugar de la autenticación por contraseña. Un par de claves SSH elimina el vector de adivinación de contraseñas en la capa del servidor: no hay contraseña para forzar.

Genere un par de claves localmente, agregue la clave pública al archivo authorized_keys de su servidor (~/.ssh/authorized_keys) y deshabilite el inicio de sesión SSH basado en contraseña en su sshd_config.

Si está administrando un VPS y aún no lo ha hecho, es lo primero que vale la pena configurar.

Capa 8: Mantén WordPress, plugins y temas actualizados

La fuerza bruta suele ser el segundo ataque, no el primero. Los atacantes a menudo explotan una vulnerabilidad en un plugin obsoleto para establecer un punto de apoyo, crear una cuenta de puerta trasera o escalar privilegios.

La fuerza bruta viene después, dirigida a cuentas que ya existen. Mantenerse actualizado cierra los puntos de entrada que hacen que la fuerza bruta valga la pena en primer lugar.

El núcleo de WordPress maneja las actualizaciones de versiones menores automáticamente por defecto. Las versiones principales requieren acción manual o una configuración explícita de actualización automática en el panel de su hosting.

Las actualizaciones automáticas por plugin están disponibles directamente en wp-admin. Vaya a Plugins » Plugins Instalados y verá un interruptor Habilitar actualizaciones automáticas en la columna derecha para cada plugin.

Para la mayoría de los sitios, habilitar las actualizaciones automáticas en todos los plugins activos es la decisión correcta. El riesgo de una actualización que cause problemas es real, pero mucho menor que el riesgo de ejecutar un plugin con una vulnerabilidad conocida durante semanas después de que se publique un parche.

Los temas siguen la misma lógica. Un tema inactivo en su servidor con una vulnerabilidad sin parches sigue siendo explotable, incluso si no es el tema activo.

Elimine todo lo que no esté utilizando. Desactivado no significa seguro.

Lo mismo ocurre con los plugins. Los archivos de un plugin desactivado siguen en el servidor y son accesibles. Si existe una vulnerabilidad en esos archivos, puede ser explotada independientemente de si el plugin está activo en WordPress.

Si no estás usando un plugin, elimínalo por completo en lugar de dejarlo desactivado.

Para equipos que gestionan varios sitios, herramientas como ManageWP, MainWP y Jetpack Manage te permiten supervisar y aplicar actualizaciones en todos los sitios desde un único panel. Ejecutar actualizaciones de un sitio a la vez en diez o veinte instalaciones es el tipo de fricción que lleva a parches omitidos.

Capa 9: Haz una copia de seguridad de tu sitio y aprende a restaurarlo

La propia guía de endurecimiento contra la fuerza bruta de WordPress.org lo dice claramente: mantén copias de seguridad probadas y capaces de funcionar sin conexión, y ensaya tus procedimientos de restauración.

Cada capa anterior a esta reduce el riesgo. Esta elimina el peor resultado posible.

Si un atacante supera todas las demás capas, una copia de seguridad reciente es la diferencia entre una recuperación de una hora y una reconstrucción total. La copia de seguridad no evita la brecha. Determina la gravedad de la brecha.

“Probadas” es la palabra que más importa en esa frase. Probar significa ejecutar una restauración en un entorno de prueba, confirmar que el sitio funciona correctamente y saber exactamente qué pasos implica el proceso antes de tener que hacerlo bajo presión.

Programa una prueba de restauración trimestralmente. Lleva menos de una hora y elimina toda la incertidumbre del peor momento.

Automatiza copias de seguridad y restauraciones con Duplicator

Lo que hace que una copia de seguridad sea útil específicamente en un escenario de brecha por fuerza bruta: debe estar fuera del sitio, independiente del servidor comprometido, con una ruta de restauración que funcione incluso cuando WordPress esté completamente bloqueado.

Duplicator Pro cumple cada uno de esos requisitos.

Las copias de seguridad automáticas programadas se ejecutan en intervalos horarios, diarios, semanales o mensuales sin intervención manual. Estableces la programación una vez y siempre tienes un punto de restauración reciente.

Para el almacenamiento, Duplicator Pro se conecta a Amazon S3, Google Drive, Dropbox, OneDrive y otros servicios en la nube de terceros.

Duplicator Cloud es el propio almacenamiento de Duplicator: no se requiere una cuenta separada, ni un servicio de terceros que configurar. A diferencia de otras opciones, se construyó específicamente para el almacenamiento de copias de seguridad de WordPress.

Si ocurre algo malo, puedes restaurar directamente desde el almacenamiento en la nube sin volver a subir los archivos al servidor primero. Cuando tu servidor está comprometido y no confías en lo que hay en él, extraes la restauración directamente de la copia en la nube.

Las URL de recuperación ante desastres son la parte que la mayoría de la gente no conoce hasta que las necesita. Después de un ataque exitoso de fuerza bruta, una de las primeras cosas que hace un atacante es cambiar la contraseña de administrador o crear nuevas cuentas y bloquear al propietario original.

Una URL de recuperación ante desastres omite por completo wp-admin, lo que te permite iniciar una restauración incluso cuando no puedes iniciar sesión. He utilizado esta función una vez en un incidente real. Es la característica que marca la diferencia entre recuperarse en una hora y pasar un día al teléfono con el soporte de alojamiento.

La restauración con un clic maneja las recuperaciones estándar sin transferencias manuales de archivos ni acceso FTP. Selecciona la copia de seguridad, haz clic en restaurar y confirma. Ese es el proceso.

Cómo monitorizar la actividad de fuerza bruta

La mayoría de los propietarios de sitios de WordPress descubren que están bajo ataque por el aviso de limitación de su proveedor de hosting, no por su propia monitorización. Para entonces, el ataque ya ha consumido recursos del servidor, ha llenado tus registros de ruido y, en algunos casos, ha tenido éxito.

Configurar la visibilidad proactiva lleva menos de una hora y significa que sabrás lo que sucede en tu sitio antes que tu host.

Monitorización proactiva

Registro de actividad te proporciona un registro de auditoría completo de cada acción realizada en tu sitio, como intentos de inicio de sesión fallidos, inicios de sesión exitosos, cambios de roles de usuario, activaciones y desactivaciones de plugins, modificaciones de configuración y ediciones de archivos.

Ese alcance es importante después de una brecha de fuerza bruta. Un atacante que entra no solo inicia sesión; realiza cambios.

El Registro de actividad muestra esos cambios en una línea de tiempo legible para que puedas ver exactamente qué sucedió y en qué orden. Esa es la información que necesitas para evaluar el daño y saber qué limpiar.

Haz que el Registro de actividad te envíe alertas por correo electrónico sobre actividad de inicio de sesión inusual. Esto te ayudará a identificar y detener inmediatamente un ataque de fuerza bruta en lugar de limpiar después de uno.

El panel de control de tu hosting es otra capa de monitorización. Los picos inexplicables de trabajadores PHP o el uso de CPU en horas no laborables son a menudo el primer signo visible de un ataque de alto volumen, que aparece antes de que tu plugin de seguridad haya registrado suficientes eventos para activar una alerta.

Señales de que ya estás bajo ataque

Algunos ataques se anuncian solos. Otros son más silenciosos.

Un pico repentino en las notificaciones de inicio de sesión fallido en tu registro de actividad es la señal más clara. Si normalmente ves dos o tres intentos fallidos al día y de repente ves cientos, algo ha cambiado.

Los avisos de bloqueo de usuarios que en realidad no intentaron iniciar sesión son una señal más sutil. Los bloqueos basados en IP afectan a todos los usuarios que comparten esa IP: una oficina corporativa o una red universitaria donde una persona activa un bloqueo puede impedir que todos los demás en la misma conexión accedan.

Si tu bandeja de entrada de soporte comienza a llenarse de mensajes de "No puedo iniciar sesión" de personas que no intentaban restablecer sus contraseñas, revisa tu registro de bloqueos.

La lenta respuesta de wp-admin o los errores de agotamiento de trabajadores PHP en el registro de errores de tu hosting apuntan al consumo de recursos de un ataque de alto volumen. El sitio todavía funciona, pero es más lento de lo que debería ser, y los registros explican por qué.

Después de cualquier incidente de seguridad, ve a Usuarios » Todos los usuarios en wp-admin y filtra por el rol de Administrador.

Una cuenta de administrador no autorizada creada durante una ventana de ataque es una señal de que el atacante tuvo éxito y se dejó una puerta trasera. Comprueba esto antes de considerar cerrado un incidente.

Lo que no funciona (y por qué la gente todavía lo recomienda)

Algunos de los consejos de seguridad de WordPress más repetidos suenan razonables pero ofrecen poca protección real. Conocer la diferencia te ahorra el esfuerzo de implementar cosas que brindan una falsa sensación de seguridad.

Geobloqueo por país

El atractivo es obvio: si la mayoría de tus ataques provienen de un país específico, bloquea ese país. El problema es que las botnets no funcionan así.

Una botnet es una red de máquinas comprometidas: routers domésticos, servidores, dispositivos IoT, ordenadores normales infectados con malware. Esas máquinas están en todas partes, incluso en tu propio país.

Bloquear el tráfico de Rusia o China no detiene una botnet con nodos en Estados Unidos, Reino Unido y Australia. Sí bloquea a visitantes legítimos de esos países. Para la mayoría de los sitios, la compensación no vale la pena.

Proteger con contraseña wp-admin con autenticación HTTP

Añadir una segunda solicitud de contraseña antes del directorio wp-admin suena como una capa adicional útil. En la práctica, puede romper AJAX de WordPress, del cual wp-admin depende para la funcionalidad principal, incluyendo guardar entradas, ejecutar configuraciones de plugins y manejar subidas de medios.

Los sitios que implementan esto correctamente con exclusiones de AJAX cuidadosas pueden hacerlo funcionar, pero para la mayoría de los propietarios de sitios, la complejidad de la configuración supera el beneficio.

Preguntas Frecuentes (FAQs)

Antes del próximo ataque, asegúrate de poder recuperarte de él

Los ataques de fuerza bruta son cada vez más baratos de ejecutar. Las botnets basadas en la nube, las bases de datos de credenciales de años de brechas acumuladas y los servicios de resolución de CAPTCHA han reducido el costo de ejecutar un ataque sostenido contra un sitio de WordPress a casi cero.

Cada capa de protección en esta publicación reduce su riesgo. Ninguna de ellas lo reduce a cero. La única garantía de que un ataque exitoso no acabe con su sitio es una copia de seguridad probada de la que pueda restaurar, incluso cuando wp-admin esté completamente bloqueado.

Más de 1.5 millones de profesionales de WordPress utilizan Duplicator Pro para exactamente esto: copias de seguridad automáticas programadas en Duplicator Cloud o en cualquier proveedor de almacenamiento en la nube importante, recuperación remota sin volver a cargar archivos en un servidor comprometido y URL de recuperación ante desastres que restauran su sitio incluso cuando no puede iniciar sesión.

Si esta publicación le hizo pensar en la seguridad y recuperación de WordPress, estas guías merecen ser leídas a continuación.

• Cómo proteger tu sitio web de hackers (Guía definitiva de seguridad)
• ¿Es WordPress seguro? Revelando la verdad
• Lista de verificación de seguridad de WordPress: Guía paso a paso para proteger tu sitio
• ¿Cómo recuperar un sitio de WordPress hackeado (9 consejos de expertos)?
• Cómo limpiar un sitio WordPress
• Dominar la depuración de WordPress: de los conceptos básicos a las técnicas avanzadas
• Los 9 mejores plugins de copia de seguridad de bases de datos de WordPress (para proteger sus datos)