Plan de batalla para defenderte de ataques de fuerza bruta

Cada 28 segundos un sitio WordPress recibe un intento de acceso automatizado. Wordfence bloquea más de 65 millones de ataques de fuerza bruta al día solo en su red, y los bots creados con IA han aumentado el volumen de estos ataques un 45 % en el último año.

Un ataque de fuerza bruta no necesita que tu web tenga una vulnerabilidad en un plugin o un tema desactualizado, le basta con tu página de acceso.

Un script prueba combinaciones de usuario y contraseña, una tras otra, miles de veces por hora, hasta que da con la correcta o el servidor se cae por la carga. Y muchas veces el objetivo ni siquiera es entrar, sino tumbar tu web a base de peticiones.

La buena noticia es que este tipo de ataque es de los más fáciles de parar. Pero hay una diferencia enorme entre «instalar un plugin de seguridad y olvidarte» y montar una defensa seria, y esa diferencia está en dónde frenas el ataque.

En esta guía te explicaré cómo montar una protección por capas usando solo herramientas gratuitas.

Vamos a ir de fuera hacia dentro, primero la CDN como filtro perimetral, luego el hosting a nivel de servidor, y finalmente WordPress con plugins y buenas prácticas.

Cada capa tiene su función, todas son importantes, y cuando trabajan juntas los ataques de fuerza bruta dejan de ser un problema y pasan a ser ruido de fondo que ni notas.

Yo te voy a poner los ejemplos con las herramientas que uso y recomiendo, que ya sabrás que Cloudflare como CDN, SiteGround como hosting, y Vigilante como plugin de seguridad dentro de WordPress.

Los conceptos y las estrategias de cada capa son aplicables con cualquier combinación de herramientas, si usas otro CDN, otro hosting u otro plugin de seguridad, adapta los pasos a tu caso.

Dónde frenes el ataque lo cambia todo

Antes de entrar en materia necesitas entender algo que cambia la forma de pensar sobre seguridad en WordPress, y es que no es lo mismo frenar un ataque en la puerta de tu casa que frenarlo a tres calles de distancia.

Cada vez que alguien (o un bot) intenta acceder a tu WordPress, el servidor tiene que hacer bastante trabajo:

1. Cargar el núcleo de WordPress
2. Conectarse a la base de datos
3. Buscar el usuario
4. Calcular el hash de la contraseña
5. Ejecutar todos los hooks de seguridad

Multiplica eso por cientos o miles de intentos por hora y tu servidor se queda sin recursos para servir a los visitantes reales.

Si frenas el ataque solo con un plugin dentro de WordPress el daño ya está hecho a nivel de recursos, porque en este momento PHP ya se ha ejecutado y la base de datos ya ha recibido consultas.

Un plugin de seguridad puede bloquear al atacante después de X intentos, pero el servidor ya ha tragado toda esa carga. Si frenas el ataque en el CDN, esas peticiones ni siquiera llegan a tu servidor, el consumo de recursos es cero y tu web sigue funcionando como si no pasara nada.

La arquitectura por capas funciona como una defensa militar donde primero está el perímetro exterior, donde se frena al grueso del ejército atacante, luego están las murallas del castillo, donde se bloquea lo que ha conseguido pasar, y finalmente la guarnición interior, que se encarga de lo que ha logrado colarse por las grietas. Si una capa falla las otras siguen en pie.

• Capa 1 – CDN (perímetro): Filtra el tráfico masivo antes de que llegue a tu servidor. Aquí paras el 95% de los ataques.
• Capa 2 – Hosting (servidor): Bloquea IPs concretas y tráfico por países a nivel de infraestructura. Lo que pasa el CDN se encuentra con este filtro.
• Capa 3 – WordPress (aplicación): Analiza el comportamiento dentro de WordPress, limita intentos, exige segundo factor de autenticación, registra actividad y responde a ataques dirigidos.

Cada capa atrapa lo que se le escapa a la anterior, esa es la gracia del asunto. ¿Lo tienes claro?, pues ¡a defender la ciudad!

Capa 1: la CDN como primera línea de defensa

Una CDN (red de entrega de contenidos) como Cloudflare o KeyCDN actúa como proxy inverso, de manera que todo el tráfico de tu web pasa primero por él antes de llegar a tu servidor. Eso te da un control enorme sobre qué peticiones pasan y cuáles se quedan en la puerta.

En los ejemplos uso Cloudflare porque es el que yo utilizo y recomiendo, tiene un plan gratuito muy completo y es el más extendido, pero la estrategia es la misma con cualquier CDN que ofrezca reglas de firewall, gestión de bots y bloqueo geográfico.

Las estrategias van de menor a mayor impacto en la experiencia de usuario. Empieza por las primeras, que son invisibles para los visitantes legítimos, y usa las últimas solo cuando sea necesario.

Filtrar bots automatizados

• Qué consigues: eliminar el tráfico de bots maliciosos antes de que hagan una sola petición a tu servidor. Esta medida es completamente invisible para los visitantes humanos y no tiene ningún efecto negativo en la experiencia de usuario ni en el SEO.
• Cómo funciona: las CDN modernas utilizan aprendizaje automático para distinguir bots de humanos basándose en patrones de comportamiento, reputación de IP, huellas digitales del navegador y otros factores. A los bots maliciosos se les bloquea automáticamente.
• Cómo se hace en Cloudflare: ve a Seguridad → Configuración → Tráfico de bots y activa el Modo bot fight. Un clic y listo.
• Contras: si usas servicios que acceden a tu web de forma automatizada (herramientas de monitorización de uptime, servicios de backup externos, APIs de terceros, pasarelas de pago), comprueba que siguen funcionando. En la gran mayoría de casos no hay problema, pero vale la pena verificarlo.

Proteger la página de acceso con reglas de firewall

• Qué consigues: que cualquier bot que intente acceder a tu wp-login.php tenga que pasar un desafío que no puede superar. Los visitantes humanos lo resuelven automáticamente en un par de segundos sin molestias.
• Cómo funciona: configuras una regla en el firewall del CDN para que toda petición a tu página de login pase por un desafío JavaScript (lo que se conoce como Managed Challenge). Los navegadores reales lo resuelven solos. Los scripts automatizados no pueden.
• Cómo se hace en Cloudflare: ve a Seguridad → Reglas de seguridad y crea una regla:
  • Nombre: Proteger login WordPress
  • Campo: Ruta de URI
  • Operador: contiene
  • Valor: /wp-login.php
  • Acción: Desafío administrado
• Pros: filtra prácticamente todos los bots de fuerza bruta que van contra el login, con un impacto mínimo en usuarios reales (un par de segundos de espera la primera vez).
• Contras: si tienes un formulario de login personalizado en otra URL (algunos temas o plugins lo hacen), necesitas añadir esa ruta también a la regla. Y si tienes muchos usuarios que acceden frecuentemente (una tienda WooCommerce con miles de clientes, por ejemplo), ese par de segundos extra se multiplica.

Bloquear vectores de ataque innecesarios

• Qué consigues: cerrar puertas de entrada que probablemente no necesitas y que los atacantes usan como alternativa al login.
• Cómo funciona: xmlrpc.php es un archivo de WordPress que permite la comunicación remota con tu web. Lo usan algunas apps para publicar desde el móvil y ciertos plugins, pero también es un vector de ataque muy popular porque permite probar credenciales en masa con una sola petición (el método system.multicall). La mayoría de webs WordPress modernas no lo necesitan.
• Cómo se hace en Cloudflare: crea otra regla personalizada:
  • Nombre: Bloquear XML-RPC
  • Campo: Ruta de URI
  • Operador: contiene
  • Valor: /xmlrpc.php
  • Acción: Bloquear
• Pros: eliminas un vector de ataque importante sin afectar al funcionamiento normal de la web en la gran mayoría de casos.
• Contras: si usas Jetpack, la app oficial de WordPress para móvil, o algún servicio que dependa de XML-RPC, dejarán de funcionar. En ese caso, usa Desafío administrado como acción en vez de Block, así los servicios legítimos podrán pasar el desafío.

Restringir el acceso geográfico

Qué consigues: reducir drásticamente el volumen de ataques bloqueando el acceso desde países que no forman parte de tu audiencia. La mayoría de botnets operan desde redes distribuidas por todo el mundo, así que limitar geográficamente es muy efectivo.

• Cómo funciona: el CDN identifica el país de origen de cada petición por su IP y aplica la acción que tú elijas: bloquear, presentar un desafío o dejar pasar.
• Cómo se hace en Cloudflare: ve a Seguridad → Reglas de seguridad y crea una regla usando el campo País. Puedes seleccionar los países que quieras restringir y elegir la acción.
  Aquí hay dos estrategias según lo agresivo que quieras ser:
  • Restringir solo el login por país: combina las condiciones Ruta de URI + contains + /wp-login.php Y País + es igual a [país]. De este modo solo bloqueas el acceso al login desde esos países, pero pueden visitar tu web con normalidad.
  • Restringir toda la web por país: bloquea o aplica el desafío a todo el tráfico de ciertos países. Más agresivo, pero más efectivo si tu web tiene una audiencia geográfica muy clara.
    Mi consejo: empieza por los países desde los que recibes más ataques (puedes verlo en los registros de eventos de seguridad del CDN) y usa Desafío administrado en vez de Bloqueo. Así, si hay un visitante legítimo de ese país puede pasar la verificación y acceder.
• Pros: reduce el volumen de ataques de forma drástica si tienes geográficamente localizada a tu audiencia.
• Contras: te puedes cargar tráfico legítimo si no piensas bien qué países bloqueas. Servicios como pasarelas de pago, APIs de terceros o herramientas de monitorización pueden operar desde países que no esperas. Y si usas el bloquo en vez del desafío no hay vuelta atrás para esas visitas.

Ajustes generales de seguridad

• Qué consigues: un nivel base de protección que complementa las reglas específicas.
  Estos ajustes son el equivalente a cerrar bien todas las ventanas antes de salir de casa. Ninguno por sí solo para un ataque, pero todos juntos complican la vida al atacante:

• • SSL/TLS en modo Completo (estricto): si tu hosting incluye certificado SSL (SiteGround y la mayoría de hostings de calidad lo ofrecen gratis), activa este modo para que la conexión entre el CDN y tu servidor esté cifrada de extremo a extremo. Evita ataques de tipo man-in-the-middle.
  • Siempre usar HTTPS: redirige todo el tráfico HTTP a HTTPS automáticamente.
  • Nivel de seguridad en medio o alto: determina el umbral a partir del cual el CDN presenta desafíos a visitantes sospechosos.
  • Tiempo del desafío a 30 minutos: el tiempo durante el cual un visitante que ha pasado un desafío no tendrá que repetirlo.

Último recurso: modo Under Attack

Este es el botón de pánico. No es una medida preventiva, es una medida de emergencia.

• Qué consigues: frenar de golpe todo el tráfico malicioso cuando tu web está siendo atacada activamente y lo notas en el rendimiento (la web va lenta, se cae, el servidor no responde).
• Cómo funciona: al activarlo todos los visitantes (humanos y bots) tienen que pasar un desafío JavaScript antes de acceder a cualquier página de tu web. Los bots quedan completamente fuera.
• Cómo se hace en Cloudflare: en la página principal de tu dominio, busca Modo Under Attack Mode en el panel lateral derecho y actívalo. Si tienes la app de Cloudflare en el móvil puedes hacerlo desde cualquier sitio.
• Pros: efectividad inmediata. En cuestión de segundos el volumen de tráfico malicioso que llega a tu servidor cae a prácticamente cero. Es la respuesta más rápida que existe.
• Contras: afecta a todos los visitantes, incluidos los legítimos. Añade un par de segundos de espera a cada visita nueva (la pantalla de verificación automática de Cloudflare). Perjudica al SEO si se mantiene activado mucho tiempo porque los bots de búsqueda también tienen que pasar el desafío. Las APIs y webhooks que recibe tu web pueden dejar de funcionar. No es algo para tener puesto permanentemente.
• Cuándo usarlo: solo cuando estás bajo un ataque activo que afecta al rendimiento de tu web y las reglas WAF no son suficientes para contenerlo. Actívalo, espera a que la situación se estabilice, analiza el patrón del ataque, crea reglas de seguridad específicas para ese patrón, y desactívalo.

Capa 2: el hosting como segunda muralla

Tu hosting es la infraestructura donde vive tu web. Los hosting de calidad incluyen herramientas de seguridad que actúan a nivel de servidor, antes de que WordPress se cargue, eso los convierte en un segundo filtro muy eficiente para lo que ha conseguido pasar el CDN.

Al igual que como te comenté con las CDN y Cloudflare, en los ejemplos uso SiteGround porque es el hosting que recomiendo y conozco en detalle, pero la mayoría de hosting serios ofrecen funcionalidades equivalentes. Busca en tu panel de control las opciones de bloqueo de IPs, bloqueo de tráfico y logs de acceso.

Aquí las estrategias van de lo más básico (observar) a lo más agresivo (bloquear países enteros).

Vigilar los registros de acceso

• Qué consigues: visibilidad sobre lo que llega a tu servidor. Sin esta información estás tomando decisiones a ciegas.
• Cómo funciona: el hosting registra todas las peticiones que recibe tu servidor, como la IP de origen, la URL solicitada, el código de respuesta HTTP, el user-agent y la marca de tiempo. Revisando estos logs puedes detectar patrones de ataque, o sea, muchas peticiones a wp-login.php desde una misma IP, picos de tráfico inusuales, accesos desde países que no esperas.
• Cómo se hace en SiteGround: ve a Site Tools → Estadísticas → Registro de acceso.

No necesitas revisar los registros cada día pero sí cuando notes algo raro (web lenta, consumo de recursos alto, avisos del hosting) o como rutina semanal/mensual.

Lo que encuentres ahí te ayuda a tomar mejores decisiones en las otras capas, a la hora de crear reglas de seguridad más específicas en la CDN o bloquear IPs y rangos concretos.

Bloquear IPs desde el servidor

• Qué consigues: que las IPs que has identificado como atacantes no lleguen ni a cargar PHP. El bloqueo se ejecuta en el servidor así que el impacto en rendimiento de tu WordPress es cero.
• Cómo funciona: añades la IP o el rango de IPs a una lista de bloqueo en el panel de tu hosting. El servidor rechaza esas conexiones antes de que WordPress se entere de que existen.
• Cómo se hace en SiteGround: ve a Site Tools → Seguridad → Tráfico bloqueado. Puedes bloquear IPs individuales (por ejemplo, 185.234.218.45) o rangos con comodines (por ejemplo, 185.234.218.*).
• Pros: muy eficiente a nivel de recursos, el bloqueo se produce antes de que intervenga PHP o WordPress.
• Contras: los ataques de fuerza bruta suelen venir de miles de IPs rotativas así que bloquear IPs una a una es jugar al ratón y al gato. Es efectivo para IPs persistentes que detectas repetidamente en los logs, para ataques masivos distribuidos el bloqueo geográfico o las reglas del CDN son mejores opciones.

Bloquear tráfico por países desde el servidor

• Qué consigues: cortar de raíz todo el tráfico de países que no tienen relación con tu web, sin pasar por ningún desafío ni verificación. Bloqueo total para bien o para mal.
• Cómo funciona: el hosting identifica el país de origen de la IP y, si está en la lista de bloqueados, muestra una página de bloqueo. No hay opción de pasar una verificación como en el CDN. Bloqueo y punto.
• Cómo se hace en SiteGround: ve a Site Tools → Seguridad → Tráfico bloqueado > Bloquear país. Selecciona el dominio, elige el país y confirma.
• Pros: muy efectivo para reducir carga de servidor. Se ejecuta antes de que WordPress se cargue.
• Contras: es un bloqueo sin matices. Puedes bloquear visitantes legítimos, clientes, pasarelas de pago o servicios que operen desde esos países. Piénsalo bien antes de activarlo y revísalo periódicamente.

Hay una diferencia importante con el bloqueo geográfico del CDN pues aquí el bloqueo es absoluto, no hay desafío administrado. Si bloqueas un país nadie de ese país accede a nada de tu web. Por eso recomiendo esta estrategia:

• Bloqueo suave por países (con posibilidad de que humanos pasen): hazlo en el CDN con el desafío administrado.
• Bloqueo duro por países (nadie accede): hazlo en el hosting, pero solo si estás seguro de que no tienes visitantes, clientes o servicios en esos países.

El plugin de seguridad del hosting

Hay algunos hosting que ofrecen su propio plugin de seguridad para WordPress, y como me habrás oído decir más de una vez ante la duda siempre usa primero lo que te ofrezca el hosting, son los mayores interesados en que no tengas problemas.

Siguiendo con el ejemplo, SiteGround tiene Security Optimizer, que incluye 2FA, límite de intentos de login, URL de login personalizada y registro de actividad.

Si ya usas un plugin de seguridad, tipo Vigilante o Wordfence, no lo necesitas, pero ojo, que tener dos plugins de seguridad activos a la vez suele causar conflictos. Pero si no usas ninguno y tu hosting ofrece uno es una forma rápida de tener lo básico cubierto.

Capa 3: WordPress, tu último bastión de defensa

Las dos capas anteriores filtran la gran mayoría del tráfico malicioso, pero siempre hay peticiones que pasan, como ataques más sofisticados, IPs sin historial malicioso, o intentos dirigidos desde pocas IPs que no disparan los umbrales de la CDN.

Esta capa tiene una ventaja que las otras no tienen, el contexto.

Dentro de WordPress sabes quién está intentando entrar, qué usuario están probando, cuántos intentos llevan, qué están haciendo exactamente, y puedes tomar decisiones basándote en información muy concreta.

Voy a organizar esta sección por estrategias de defensa, de menor a mayor impacto, y en cada una te doy las herramientas gratuitas con las que puedes aplicarla.

Igual que en las capas anteriores, de lo preventivo a lo reactivo, del perímetro al último recurso.

Limitar los intentos de login

• Qué consigues: que un bot no pueda probar miles de combinaciones de usuario y contraseña sin consecuencias. Después de X intentos fallidos la IP se bloquea temporalmente.
• Cómo funciona: tu plugin de seguridad cuenta los intentos de acceso fallidos desde cada IP. Cuando se supera el umbral que hayas configurado (por ejemplo 5 intentos), esa IP se bloquea durante un tiempo. Si vuelve a intentarlo después del bloqueo y falla otra vez, el siguiente bloqueo es más largo (bloqueo progresivo). Así se desanima a los bots que insisten.
• Configuración recomendada: entre 3 y 5 intentos permitidos, con un primer bloqueo de 15 a 30 minutos y bloqueos progresivos activados.
• Con qué puedes hacerlo:
  • Vigilante: puedes configurar el límite de intentos, los bloqueos progresivos y recibes avisos por email de los bloqueos. También oculta los mensajes de error de la pantalla de acceso, para no revelar si un usuario existe o no (dato que los atacantes aprovechan para afinar sus ataques).
  • Limit Login Attempts Reloaded: plugin ligero y centrado solo en esto. Si no quieres un plugin de seguridad completo y solo buscas limitar los intentos este es el más popular y funciona bien.
• Pros: medida fundamental que frena a la mayoría de bots simples y fácil de configurar.
• Contras: si el ataque viene de miles de IPs rotativas (una botnet) cada IP solo necesita un par de intentos y nunca llega al umbral de bloqueo. Para ataques distribuidos esta medida por sí sola no es suficiente, necesitas las capas anteriores.

Proteger el acceso a wp-login

• Qué consigues: que los bots no encuentren la página de acceso estándar de WordPress. Si no la encuentran no la atacan, y buscan otras.
• Cómo funciona: cambias la URL de login de WordPress por una personalizada que solo tú conozcas. En vez de tudominio.com/wp-login.php tu acceso estará en tudominio.com/lo-que-tu-quieras. Los bots que buscan wp-login.php automáticamente se encuentran con un error 404 y se van.
• Con qué puedes hacerlo:
  • Vigilante: activa la URL de acceso personalizada y elige una dirección que puedas recordar. Tienes la opción de informar por email a todos los usuarios a los que les afecte el cambio.
  • WPS Hide Login: plugin muy ligero que hace solo esto. Buena opción si no necesitas un plugin de seguridad más completo.
• Pros: reduce el ruido de ataques automatizados de forma considerable. Los bots buscan wp-login.php por defecto y si no lo encuentran, no insisten.
• Contras: esto es seguridad por oscuridad, no seguridad real. Un atacante determinado puede encontrar tu URL de login de otras formas (redireccionando a wp-admin, por ejemplo). No sustituye a las demás medidas, pero complementa.

Identificación en dos pasos (2FA)

Qué consigues: que aunque un atacante adivine tu contraseña no pueda entrar. Es la medida individual con más impacto contra ataques de fuerza bruta. El 2FA convierte la fuerza bruta en un ataque completamente inútil contra tu cuenta.

• Cómo funciona: después de introducir usuario y contraseña correctos, necesitas un segundo factor de verificación: un código temporal que se envía a tu email, una app de autenticación en tu móvil o una llave de seguridad física. Sin ese segundo factor el acceso no se completa.
• Configuración recomendada: actívalo como mínimo para todos los administradores. Si tienes editores o autores actívalo también para ellos. Puedes activar la opción de dispositivos de confianza para no tener que verificar cada vez que entras desde tu equipo habitual.
• Con qué puedes hacerlo:
  • Vigilante: incluye 2FA por correo electrónico. Cuando inicias sesión, recibes un código de un solo uso. Puedes configurar dispositivos de confianza para 30 días y forzar el 2FA por roles.
  • Two-Factor: plugin de referencia para 2FA en WordPress, desarrollado por colaboradores del núcleo de WordPress. Admite apps TOTP (Google Authenticator, Authy), códigos por email, llaves de seguridad U2F y códigos de respaldo. Si prefieres 2FA con app de verificación en vez de por email esta es la opción gratuita más completa.

Puedes usar Two-Factor junto con Vigilante sin problemas desactivando el 2FA de Vigilante y usar Two-Factor para gestionarlo.

• Pros: efectividad prácticamente absoluta. El 2FA hace que la fuerza bruta sea irrelevante como método para robar credenciales.
• Contras: añade un paso más al login lo que puede resultar incómodo. Si usas 2FA por email y tu servidor de correo falla puedes quedarte fuera de tu propia web (por eso los códigos de respaldo son importantes). Para webs con muchos usuarios (tiendas, membresías) forzar 2FA a todos puede generar quejas. Inicialmente actívalo solo para perfiles con permisos altos y, sobre todo, que puedan acceder a wp-admin, no a clientes por ejemplo.

Política de contraseñas y gestión de usuarios

• Qué consigues: eliminar el eslabón más débil de la cadena, que suele ser una contraseña mala o una cuenta con un nombre predecible. El 80 % de los ataques con éxito a WordPress se basan en contraseñas débiles o robadas.
• Qué hacer:
  • Bloquear nombres de usuario predecibles: impide que existan usuarios con nombres como «admin«, «test«, «root» o «administrator«, son los primeros que prueban los bots.
  • Forzar contraseñas seguras: un mínimo de 12 a 16 caracteres, con mezcla de tipos. Usa un gestor de contraseñas (Bitwarden es gratuito y funciona muy bien).
  • No reutilizar contraseñas: si tu contraseña de WordPress es la misma que la de tu email, un atacante que consiga una tiene las dos.
  • Caducidad de contraseñas: obliga a cambiarlas periódicamente, sobre todo en entornos con varios usuarios.
  • Gestión de sesiones: controla cuántas sesiones simultáneas puede tener un usuario y cierra las que no reconozcas.
• Con qué puedes hacerlo:
  • Vigilante: puedes bloquear nombres de usuario inseguros, forzar contraseñas con longitud mínima, configurar caducidad de contraseñas con intervalos personalizados, activar historial de contraseñas para evitar reutilización, y gestionar sesiones activas.
  • Manualmente: si no usas un plugin de seguridad al menos crea un nuevo usuario administrador con un nombre no predecible, asígnale todo el contenido del usuario «admin«, y elimina ese usuario «admin«. Es un cambio de dos minutos que reduce los intentos exitosos de forma considerable.

Cortafuegos a nivel de aplicación

• Qué consigues: una capa de protección dentro de WordPress que analiza cada petición y bloquea las que tengan patrones maliciosos, antes de que WordPress las procese completamente.
• Cómo funciona: el cortafuegos del plugin examina cada petición HTTP en busca de inyecciones SQL, ataques XSS, intentos de inclusión de archivos, exploración de directorios y otros patrones de ataque conocidos. También permite crear listas de IPs y User-Agent permitidos o bloqueados.
• Con qué puedes hacerlo:
  • Vigilante: incluye cortafuegos con protección contra SQL injection, XSS, LFI/RFI, limitación de tráfico, y listas blancas/negras de IPs y User-Agents. Puedes añadir IPs a la lista negra directamente desde el registro de actividad con un clic.
  • Wordfence (versión gratuita): cortafuegos bastante completo con escáner de malware. El pero es que su versión gratuita retrasa las reglas de cortafuegos 30 días respecto a la versión de pago, pero como cortafuegos gratuito funciona.
• Importante: no instales más de un plugin con cortafuegos a la vez. Elige uno.
• Pros: añade protección contra tipos de ataque que van más allá de la fuerza bruta (inyecciones, XSS, exploración de archivos).
• Contras: un cortafuegos dentro de WordPress consume recursos de PHP en cada petición. Si el grueso del tráfico malicioso ya está filtrado por el CDN y el hosting, este cortafuegos solo procesa las peticiones que se han colado, lo que minimiza el impacto. Pero si es tu única capa de defensa la carga puede ser importante bajo un ataque fuerte.

Registro de actividad y monitorización

• Qué consigues: visibilidad total sobre lo que pasa dentro de tu WordPress. Sin un registro de actividad muchos ataques pasan desapercibidos hasta que ya han causado daño.
• Cómo funciona: el plugin registra todos los eventos relevantes. Puedes vigilar intentos de acceso (correctos y fallidos), cambios en usuarios, modificaciones de contenido, activaciones de plugins, amenazas bloqueadas, y además podrás filtrar, buscar patrones y exportar los datos.
• Qué es relevante para fuerza bruta:
  • Qué usuarios están siendo atacados (si prueban «admin» y no tienes ese usuario bien, si prueban tu usuario real es que hay un problema mayor).
  • Desde qué IPs vienen los intentos (para bloquearlas en el CDN o en el hosting).
  • Si hay intentos coordinados desde varios orígenes (indicio de botnet).
  • Si alguien ha conseguido entrar (un login con éxito que no reconoces es señal de alarma inmediata).
• Con qué puedes hacerlo:
  • Vigilante: registro de actividad completo con filtros por tipo de evento, gravedad, método HTTP y fecha y exportación a CSV. Desde cada registro puedes añadir la IP o el User-Agent a la lista blanca o negra del cortafuegos con un clic, y tiene enlaces directos a AbuseIPDB para verificar las IPs. Configura la retención a 30 días como equilibrio entre información útil y espacio en base de datos.
  • WP Activity Log: plugin especializado en el registro de actividad, muy detallado. Si usas un plugin de seguridad sin registro de actividad es un buenísimo complemento.
• Pros: te permite tomar decisiones informadas en vez de actuar a ciegas. Detectas patrones, respondes rápido y aprendes de cada ataque.
• Contras: los registros consumen espacio en la base de datos. Configura un periodo de retención razonable y no acumules meses de logs innecesarios.

Proteger vectores secundarios

• Qué consigues: cerrar puertas laterales que los atacantes pueden usar para obtener información o acceder a tu web sin pasar por el login.
• Qué vectores proteger:
  • API REST y enumeración de usuarios: por defecto la API REST de WordPress expone la lista de usuarios de tu web en /wp-json/wp/v2/users. Un atacante puede obtener nombres de usuario reales y usarlos en ataques de fuerza bruta dirigidos. Bloquea esta exposición para usuarios no verificados.
  • Cabeceras de seguridad: configurar Content Security Policy (CSP), HSTS, X-Frame-Options y otras cabeceras reduce la superficie de ataque general de tu web. No impide la fuerza bruta directamente pero dificulta otros tipos de ataque que pueden complementarla.
  • Archivos sensibles: protege el acceso a .htaccess, wp-config.php, readme.html y otros archivos que pueden revelar información de tu instalación.
• Con qué puedes hacerlo:
  • Vigilante: incluye control de la REST API (tres modos: público, solo autenticados, selectivo), configuración completa de cabeceras de seguridad con herramienta de prueba integrada, y protección de archivos sensibles.
  • AIOS: plugin de seguridad muy completo que incluye protección contra muchos de estos otros vectores de ataque.

Tu último recurso: modo bajo ataque desde la aplicación

Al igual que la CDN tiene su botón de pánico algunos plugins de seguridad tienen el suyo propio dentro de WordPress.

• Qué consigues: reforzar toda la protección de WordPress de golpe cuando estás bajo un ataque que ha conseguido pasar las dos capas anteriores.
• Cómo funciona: es prácticamente lo que hace la CDN pero desde WordPress. Al activarlo se aplican restricciones mucho más agresivas de forma temporal:
  • Desafío JavaScript desde la aplicación
  • Limitación de tráfico muy estricta
  • Bloqueo de métodos HTTP innecesarios
  • Restricción de la REST API
  • Bloqueo total de XML-RPC.
• Con qué puedes hacerlo:
  • Vigilante, que yo sepa ningún otro plugin ofrece esto: el modo bajo ataque aplica todas las restricciones descritas y se desactiva manualmente, o automáticamente a las 4 horas para que no se te olvide que está activo. Te avisa por email cuando se activa y cuando se desactiva.
• Pros: respuesta rápida dentro de WordPress sin necesidad de acceder al CDN o al hosting.
• Contras: siendo honesto, si el ataque es volumétrico (miles de peticiones por segundo), este modo no es el lugar donde deberías frenarlo porque cada petición ya ha llegado a PHP y ha consumido recursos del servidor. El modo bajo ataque del CDN es más efectivo porque frena el tráfico antes. Este modo es útil para ataques dirigidos o persistentes de bajo volumen que las capas anteriores no detectan, o como complemento si no tienes CDN.

¿Qué hago si ya me están atacando?

Has montado todas las capas, todo está configurado, y de repente notas que tu web va lenta, ves cientos de intentos de login en el registro de actividad, o tu hosting te avisa de un consumo de recursos anormal.

Estás bajo un ataque de fuerza bruta activo. Esto es lo que tienes que hacer, en orden, desde fuera hacia dentro.

Activa el modo Under Attack de la CDN

Es la respuesta más rápida y efectiva. En Cloudflare activa el modo Under Attack desde el escritorio de tu dominio (o desde la app del móvil si no estás frente al ordenador). En segundos todo el tráfico tiene que superar un desafío JavaScript y el volumen de peticiones a tu servidor cae drásticamente.

Sí, es incómodo para los visitantes legítimos, y sí, afecta al SEO temporalmente, pero ante un ataque activo priorizar la disponibilidad de tu web es lo fundamental. Un par de segundos de espera es infinitamente mejor que una web caída.

Revisa los logs y bloquea desde el hosting

Con la CDN protegiendo el perímetro, entra en el panel de tu hosting y revisa los registros de acceso.

Si ves IPs o rangos que generan mucho tráfico hacia tu login bloquéalas directamente, si el ataque viene mayoritariamente de un país concreto plantéate bloquear ese país temporalmente.

Revisa el registro de actividad en WordPress

Entra en el registro de actividad de tu plugin de seguridad y analiza:

• ¿Están probando un usuario concreto? Si atacan al usuario «admin», elimínalo o cámbiale el nombre.
• ¿Vienen de muchas IPs o de pocas? Si son pocas bloqueo permanente, si son muchas, como de un botnet, mejor bloqueo geográfico.
• ¿Usan un User-Agent específico? Si hay patrón, bloquéalo en el cortafuegos del plugin o del CDN.
• ¿El ataque viene por wp-login.php o por xmlrpc.php? Si es por XML-RPC bloquéalo ya si no lo tenías ya desactivado.

Activa el modo bajo ataque desde WordPress si fuese necesario

Si el ataque persiste a pesar del CDN y los bloqueos del hosting, o si es un ataque de bajo volumen pero muy dirigido, activa el modo bajo ataque de tu plugin de seguridad como refuerzo adicional.

Reorganiza y optimiza tus defensas

Cada ataque te da información para mejorar.

Crea nuevas reglas de seguridad en el CDN basándote en los patrones detectados, ajusta umbrales en el plugin de seguridad, bloquea rangos de IPs persistentes en el hosting.

La seguridad es un proceso continuo, no una configuración que haces una vez.

Errores típicos que todos cometemos

• Confiar únicamente en el plugin de seguridad: un plugin dentro de WordPress es la última capa, no la primera. Si todo el peso de la seguridad recae en un plugin, tu servidor absorbe toda la carga de los ataques antes de que el plugin pueda actuar.
• No usar CDN/firewall externo: un CDN con plan gratuito te da protección a nivel de red que ningún plugin puede ofrecer. No hay excusa para no usarlo.
• Dejar XML-RPC activo sin necesidad: si no usas aplicaciones que lo requieran bloquéalo. Es un vector de ataque demasiado fácil de explotar.
• No monitorizar: si no tienes registro de actividad no sabes lo que pasa en tu web. Muchos ataques son silenciosos hasta que ya han causado daño.
• Bloquear países sin pensar: bloquear países puede ser efectivo, pero hazlo con criterio. Si bloqueas un país donde operan servicios que tu web necesita (pasarelas de pago, APIs de email, herramientas de monitorización) vas a crear problemas que no tienen nada que ver con la seguridad.
• Instalar varios plugins de seguridad: Wordfence + Security Optimizer + Vigilane no te hace más seguro, te hace más lento y con más probabilidades de conflictos. Elige uno, aprende a configurarlo y compleméntalo con las demás capas.
• No tener copias de seguridad: la seguridad puede fallar, y si todo falla y tu web está comprometida necesitas poder restaurar una copia limpia. Haz copias de seguridad periódicas y guardadas fuera de tu servidor.
• No actualizar: WordPress, plugins, temas y PHP. Todo actualizado, siempre. El caso reciente de los 30 plugins comprados y troyanizados a través de Essential demuestra que incluso plugins legítimos pueden convertirse en amenazas. Si un plugin no se actualiza desde hace más de un año búscate un sustituto.

El plan de batalla completo

Aquí tienes el resumen de toda la estrategia, de fuera hacia dentro, con las herramientas recomendadas en cada paso, configura cada punto en orden.

Lo que hay más arriba en cada tabla es lo primero que actúa y lo más eficiente, lo que está más abajo es la última línea de defensa.

Perímetro: CDN

Muralla: hosting

Guarnición: WordPress

Logística: mantenimiento

Todo lo que ves en esta guía lo puedes configurar en menos de una hora usando solo herramientas gratuitas.

No hace falta gastar dinero en licencias de plugins premium para tener una protección sólida contra ataques de fuerza bruta, lo que hace falta es entender dónde poner cada defensa y configurarla bien.

La seguridad no es cómoda, algunas de estas medidas añaden pasos al login, bloquean visitantes de ciertos países, o te obligan a recordar una URL personalizada, pero la alternativa a la seguridad es peor, porque lo que obtienes es una web caída, datos comprometidos u horas limpiando malware.

Cuando el coste de no protegerte es infinitamente mayor que la pequeña molestia de hacerlo, la decisión es fácil. Y recuerda que la seguridad no es algo que configuras una vez y te olvidas.

Revisa tus logs periódicamente, mantén todo actualizado, y ajusta tus defensas cuando detectes patrones nuevos. Cada ataque que analizas te deja mejor preparado para el siguiente.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!