No hace falta ser un objetivo importante para recibir un ataque automatizado a gran escala. No hace falta tener datos valiosos, ni ser conocido, ni haber hecho nada mal. Basta con tener un WordPress público en Internet. Esto es lo que ocurrió, capa por capa, cuando un sitio protegido por SeenSecure recibió una ráfaga de más de 300 peticiones por minuto en cuestión de segundos.
No es una persona, es un escáner
Un ataque como este casi nunca lo lanza una persona sentada frente a un teclado decidiendo qué probar. Es un script que recorre una lista de miles de rutas conocidas — carpetas de plugins antiguos, archivos de demostración, scripts de prueba olvidados — y las prueba contra millones de dominios, uno detrás de otro, sin descanso ni criterio. El objetivo no es «tu» WordPress en concreto: es cualquier WordPress que responda con un «sí» a alguna de esas rutas.
En este caso concreto, las peticiones incluían patrones muy reconocibles para cualquiera que lleve tiempo en seguridad WordPress:
- Peticiones a archivos de demostración de librerías de terceros (como
getid3) que en versiones antiguas de ciertos plugins permitían leer o incluso escribir archivos en el servidor. - Scripts de prueba abandonados de integraciones de pago/CRM (como Infusionsoft) que a veces exponen funciones internas sin autenticación.
- Intentos de recorrido de directorios (path traversal) del tipo
../../../etc/passwd, buscando escapar de la carpeta del sitio para leer archivos del sistema. - Cargas con sintaxis de inyección SQL, probando si algún parámetro de la URL llega sin sanear hasta una consulta a la base de datos.
Ninguna de estas técnicas es nueva ni sofisticada. Son, literalmente, las mismas categorías de fallo que explotaba el gusano Morris en 1988 — solo que hoy se prueban contra millones de sitios a la vez, de forma automática, gratis y sin esfuerzo para quien lanza el escáner.
Capa por capa: qué detuvo cada intento
Un sitio sin protección específica para esto tiene que confiar en que el propio WordPress, el plugin en cuestión y el servidor estén perfectamente actualizados y bien configurados — una apuesta arriesgada cuando basta un solo archivo olvidado para abrir la puerta. Así es como se rompe la cadena en cada capa:
- Rate Limiting: en cuanto una misma IP supera el número de peticiones por minuto permitido, se corta — sin esperar a analizar qué está pidiendo exactamente. Es la primera barrera, y la más barata de mantener bajo carga alta.
- Reglas del Firewall (WAF): cada petición restante se compara contra patrones conocidos de ataque — path traversal, inyección SQL, XSS. Si coincide, se bloquea antes de que llegue a WordPress.
- Protección de archivos sensibles: las rutas a archivos de demostración, backups, logs o manifiestos de dependencias se bloquean a nivel de servidor, sin ni siquiera ejecutar PHP.
- Persistencia de bloqueo: una IP que dispara varias de estas alarmas en poco tiempo queda bloqueada por un periodo, así que las siguientes peticiones de esa misma IP ni siquiera llegan a evaluarse — se cortan en el primer paso, con coste casi cero para el servidor.
El resultado, en este caso concreto: más de 300 peticiones por minuto, atravesando esas capas, y cero peticiones que llegaran a ejecutar código no autorizado o acceder a un archivo que no debían ver.
Por qué esto no es un caso aislado
Lo inquietante de este tipo de ataque no es su sofisticación — no la tiene — sino su normalidad. Este mismo patrón se repite, con variaciones menores, contra prácticamente cualquier WordPress público, todos los días, a todas horas. La diferencia entre un sitio comprometido y uno que ni se entera de que fue sondeado no suele estar en tener «más seguridad» en abstracto, sino en tener capas que se complementan: una que corta por volumen, otra que corta por patrón, otra que corta por reputación, y un registro de todo ello para saber exactamente qué pasó si algo se escapa.
Si quieres ver este mismo tipo de tráfico en tu propio WordPress — probablemente lo estés recibiendo ahora mismo sin saberlo — el Monitor de Tráfico en tiempo real de SeenSecure muestra cada petición bloqueada, con el motivo exacto en lenguaje llano, sin necesidad de leer un log técnico para entender qué está pasando.