El lunes a las 16:24 me llegó un correo automático de Wordfence: 355 ataques bloqueados en los últimos 10 minutos. Uno cada dos segundos. La web era la nuestra, auditour.eu, que no es Amazon ni un medio de comunicación: es la web de una agencia pequeña.
Ese correo lo recibe cualquiera que tenga Wordfence instalado. Casi todo el mundo lo archiva sin abrirlo, o peor, lo lee con un ligero sobresalto y no hace nada. Merece la pena abrirlo, porque lo interesante no es el número. Es qué estaban intentando.
Lo primero que sorprende: no iban a por la contraseña
Cuando alguien piensa en «ataque a WordPress» piensa en un bot probando contraseñas en /wp-login.php. Es la imagen mental que todos tenemos, y es la que menos se corresponde con lo que pasa de verdad.
Los 355 bloqueos de aquella tarde venían todos de la misma regla del firewall: User-Agents maliciosos conocidos. Es decir, herramientas automatizadas de escaneo que ni siquiera se molestan en disfrazarse. Una sola dirección IP, lanzando peticiones en ráfaga contra decenas de rutas distintas, buscando algo muy concreto: una puerta que alguien se haya dejado abierta.
No es un ataque dirigido contra nosotros. Es una draga que pasa por internet arrastrando la red por el fondo, y nuestra web es uno de los millones de sitios por los que pasa cada día.
El coste que nadie contabiliza
Aquí hay un matiz técnico que se pasa por alto y que tiene consecuencias en la factura de hosting y en la velocidad del sitio.
Wordfence, como casi todos los plugins de seguridad, funciona dentro de WordPress. Eso significa que para bloquear una petición maliciosa, primero hay que arrancar PHP, cargar WordPress, cargar el plugin y entonces decidir que esa petición no pasa. Cada uno de esos 355 bloqueos consumió recursos reales del servidor.
Cuando esto ocurre en ráfagas de varios cientos por minuto, en un hosting compartido, el resultado no es una brecha de seguridad: es una web lenta sin motivo aparente. Y ese es un síntoma que muchos clientes achacan al hosting, al tema o a «WordPress, que es pesado».
Los accesos que nadie mira
Si dejamos de fijarnos en el login, el mapa real de lo que recibe una web WordPress cualquiera es bastante más amplio. Por orden de peligrosidad real, no de volumen:
| Vector | Qué buscan |
|---|---|
| Vulnerabilidades conocidas de plugins y temas | El vector real de casi todas las infecciones. Un plugin desactualizado con una vulnerabilidad publicada permite subir ficheros o ejecutar código sin necesitar ninguna contraseña. |
| Reconocimiento de versiones | Ficheros como readme.txt o changelog.txt revelan qué versión de qué plugin tienes. Es la fase previa: primero saben qué explotar, después vuelven. |
| Enumeración de usuarios | Obtener los nombres reales de los administradores para atacar después con credenciales filtradas de otros servicios. |
| XML-RPC | Permite probar cientos de contraseñas en una sola petición. Fuerza bruta amplificada, invisible para quien solo vigila el login. |
| Búsqueda de puertas traseras ajenas | Rutas tipo /wso.php o ficheros PHP dentro de la carpeta de subidas. Buscan backdoors que dejó otro atacante antes. Es más barato reutilizar una puerta abierta que abrir una nueva. |
| Ficheros expuestos | Copias de seguridad .zip o .sql olvidadas en la raíz, .env, wp-config.php.bak, carpetas .git. Una sola de estas puede entregar la base de datos entera sin necesidad de ningún exploit. |
| Formularios de contacto y suscripción | Spam, y en el peor caso, usar tu dominio como relé de correo. El daño no lo ves en la web: lo ves cuando tus emails legítimos empiezan a caer en spam. |
De esta lista, la que más incidentes reales provoca es la primera. En todos los casos de infección que hemos limpiado, el punto de entrada fue un plugin o un tema desactualizado, casi siempre premium y casi siempre con la licencia de soporte caducada. Nunca fue una contraseña adivinada.
Bloquear IPs es un juego que se pierde siempre
La tentación, al ver ese correo, es bloquear la IP. Y sí, se puede hacer, y en Wordfence se hace con dos clics.
El problema es que la IP rota y tu superficie de ataque no. Mañana el mismo escáner llega desde otro rango, desde otro país, desde otro proveedor de cloud. Bloquear direcciones una a una es achicar agua con un vaso.
Lo que sí funciona son capas, y en este orden concreto:
1. Filtrar antes de llegar al servidor
Un CDN con firewall por delante del hosting (Cloudflare tiene un plan gratuito que sirve para esto) descarta el tráfico basura antes de que toque tu servidor. Ni PHP, ni WordPress, ni plugin. Es la única capa que además de proteger, mejora el rendimiento.
2. Cortar en el servidor
Reglas a nivel de .htaccess que bloquean bots identificados, el acceso a XML-RPC y a los ficheros que filtran información. Coste cero en recursos, se aplica en segundos y se puede estandarizar para todas las webs que gestionas.
3. Exprimir el firewall que ya tienes
La versión gratuita de Wordfence trae dos cosas infrautilizadas:
- Limitación de peticiones por IP: bloquea automáticamente a quien supera un umbral de peticiones por minuto. Es lo que más rinde de todo lo gratuito.
- URLs señuelo: defines rutas trampa que ninguna persona real pediría jamás (
/wp-config.php.bak, por ejemplo) y cualquier IP que las solicite queda bloqueada al instante. Los escáneres automáticos caen en todas.
4. Y lo que ninguna capa sustituye
Mantener actualizado el núcleo, los plugins y el tema. Retirar lo que no se usa. Borrar los ficheros y scripts antiguos que quedaron olvidados de otra época. Un firewall bien configurado te da tiempo; no te cierra el agujero.
La conclusión incómoda
Aquel correo del lunes terminaba con la frase que Wordfence pone siempre: «Wordfence está bloqueando estos ataques». Y era verdad. El firewall hizo su trabajo, los 355 se quedaron fuera, no pasó nada.
Pero ese correo llega igual a una web actualizada y a una web con un plugin vulnerable desde hace ocho meses. El aviso es idéntico; el desenlace no. En el primer caso es ruido de fondo. En el segundo es una cuenta atrás, y el propietario está leyendo exactamente la misma frase tranquilizadora.
Esa es la razón por la que en Auditour el mantenimiento no consiste en instalar un plugin de seguridad y olvidarse. Consiste en revisar cada mes qué versión corre cada web, qué vulnerabilidades se han publicado desde la última revisión, y qué se ha quedado olvidado en el servidor. Es un trabajo poco lucido y muy aburrido, y es el único que evita la llamada del viernes por la tarde.
Si gestionas tu web por tu cuenta, empieza por lo barato: mira si tienes ficheros de backup o copias antiguas accesibles desde el navegador, y comprueba la fecha de la última actualización de tus plugins premium. Son diez minutos y cierran la mayor parte del riesgo real.
Si prefieres delegarlo, nuestro servicio de mantenimiento profesional de WordPress parte de 12,50 € al mes por web e incluye exactamente esto: actualizaciones controladas, seguimiento de vulnerabilidades, copias de seguridad y respuesta ante incidentes. Sin sorpresas y sin correos que no sabes si debes abrir.
