El costo oculto de las solicitudes automatizadas en nuestro sitio web
— El 20 de septiembre, unas miles de solicitudes automatizadas recorrieron el sitio de BerylCode en dos ráfagas breves. Nueve días después, el mismo tráfico volvió a varios de nuestros sitios públicos y los Cloudflare Workers alcanzaron otra vez sus límites de CPU (capacidad de procesamiento).
A primera vista, parecía ruido de fondo habitual. Pero las solicitudes buscaban secretos, herramientas de depuración y programas que no usamos. El patrón automatizado era evidente, y los errores de Workers mostraron que ese ruido tenía un costo operativo.
Los informes no muestran accesos exitosos, credenciales expuestas ni interrupciones confirmadas para visitantes. Sí registran dos ocasiones en que la ejecución de Workers falló al superar los límites de CPU. Aquí contamos cómo investigamos esas señales y qué cambiaremos para responder mejor.
Dos oleadas de tráfico automatizado
La primera oleada llegó el 20 de septiembre. Entre las 12:01 y las 12:06 UTC, Cloudflare registró cerca de 2.260 solicitudes. Otras 2.220 llegaron entre las 12:30 y las 12:34 UTC. Cada ráfaga provino principalmente de una sola fuente. Las rutas buscaban diagnósticos de PHP, archivos secretos, claves de API, GraphQL y páginas de depuración: señales típicas de un escaneo automático en busca de vulnerabilidades.
Ese día, el Worker de nuestro sitio web registró 4.200 ejecuciones y 492 errores, todos atribuidos a superar los límites de CPU. La tasa de error fue de 11,7 % y la mediana rondó los 143 milisegundos. El límite de ejecución afectó ambas oleadas; Cloudflare bloqueó pocas solicitudes durante esas ventanas.
El 29 de septiembre, el tráfico automatizado regresó durante varias horas y llegó a distintos dominios: los sitios de Estados Unidos y LATAM, Requesto y el sitio de demostración. Security Analytics contabilizó 19.680 solicitudes; 407 fueron mitigadas y 240 llegaron al servidor de origen.
Workers registró 7.290 ejecuciones, 1.470 errores y cerca de 1.000 errores por límite de CPU. El firewall bloqueó solicitudes que buscaban explotar una vulnerabilidad de ejecución remota de código en React y localizar archivos de configuración de WordPress. La alerta de confiabilidad volvió a aparecer, esta vez en más sitios y durante más tiempo.
Qué nos dicen los números y qué no
Un Cloudflare Worker ejecuta el código que atiende una solicitud y dispone de un presupuesto de CPU para hacerlo. Si la ejecución supera el límite, la solicitud puede fallar antes de que la aplicación termine de responder. Por eso una secuencia de rutas inválidas puede importar aunque nadie esté intentando usar el sitio de manera normal.
El panel del 29 de septiembre mostró una mediana de CPU cercana a 74 milisegundos y 443 milisegundos en P99. Son mediciones observadas, no el límite configurado por Cloudflare. El 20 de septiembre, la mediana fue de unos 143 milisegundos.
Cloudflare recoge métricas en su red antes de que las solicitudes lleguen al Worker; esas métricas pueden incluir solo una muestra. El panel de Workers, en cambio, registra ejecuciones. Que una solicitud aparezca en los datos de la red no permite reconciliar las dos fuentes ni obtener un conteo confiable por solicitud.
En conjunto, la evidencia apunta a escaneos automáticos en busca de vulnerabilidades, y las métricas confirman errores de CPU en ambas fechas. Pero los informes no vinculan cada solicitud con un error específico, no confirman un ataque de denegación de servicio distribuido ni indican cuántas personas pudieron verse afectadas.
Seguir una solicitud problemática dentro de la aplicación
La pregunta fue qué parte del sitio trabajaba tanto para una solicitud que debería terminar en un error 404. Los paneles registraban los fallos, pero no mostraban paso a paso el recorrido de cada solicitud por el código.
Usamos herramientas locales para medir qué partes del código consumen tiempo al procesar solicitudes de prueba. Una medición sugirió que repetir tareas de generación de metadatos podría sumar costo al solicitar una página inexistente. Es una pista concreta que debemos investigar, pero no demuestra cuál fue la causa raíz en producción.
Esta medición orienta, pero no dicta el veredicto: los entornos locales y de producción son distintos. No prueba que los metadatos causaran los picos ni explica los cientos de milisegundos registrados en Cloudflare. En las pruebas locales del sitio LATAM, las respuestas 404 tuvieron entre 7 y 8 milisegundos de tiempo activo por solicitud.
Más adelante, algunas muestras de los logs de producción aportaron otra pista: ciertas rutas inválidas usaron cientos de milisegundos de CPU, pero también ocurrió con solicitudes a la página de inicio. Por eso ahora medimos por separado el tiempo que consumen las rutas desconocidas y las páginas normales. Estamos siguiendo la solicitud completa antes de atribuir el problema a un componente sin suficiente evidencia.
Qué cambiamos para responder mejor
Añadimos una regla de seguridad de Cloudflare para rutas que nunca pueden ser válidas en los sitios de BerylCode: archivos secretos, configuración de WordPress, depuración de PHP y otras solicitudes de búsqueda similares. Ahora Cloudflare puede bloquearlas en su red, antes de que lleguen al Worker y consuman recursos de la aplicación.
También activamos logs detallados de Workers para los sitios de Estados Unidos y LATAM. Los logs incluyen la ruta, el método, el estado, el resultado y los datos de duración o CPU cuando están disponibles. No guardan el contenido de las solicitudes, secretos ni valores sensibles de las consultas. Así podremos relacionar mejor un error futuro con la solicitud y el despliegue que lo produjo.
Al detectar solicitudes automáticas dirigidas a una dirección alternativa, como berylcode.com:8443, revisamos el manejo de dominios y puertos. Las pruebas confirmaron que solo los dominios previstos llegan a la aplicación y que las redirecciones canónicas funcionan. No hay evidencia de que ese puerto causara los errores de CPU; lo revisamos como punto de entrada expuesto, no como causa raíz.
Filtrar temprano evita trabajo innecesario en solicitudes inválidas; los logs mejorados ayudan a encontrar rutas costosas cuando otras sí llegan a la aplicación. Validamos páginas, buscadores, formularios y APIs para proteger el sitio sin afectar visitantes.
Lo que todavía estamos investigando
Los eventos de septiembre no fueron evidencia de una intrusión confirmada, pero sí pusieron a prueba la resiliencia de nuestros sitios. Nos recordaron que el tráfico habitual no es el único para el que debemos prepararnos. Un bot puede convertir un 404 aparentemente simple en una solicitud costosa si activa suficiente trabajo compartido de la aplicación.
Ahora tenemos un mapa más claro de las solicitudes, una hipótesis sobre los metadatos y mejor visibilidad en producción. Aún necesitamos datos por solicitud para identificar qué código consume más CPU y medir si los cambios mantienen el tráfico inválido dentro del presupuesto.
El siguiente paso es comparar páginas normales, errores 404 y rutas usadas por escáneres de seguridad en condiciones controladas, y contrastar los resultados con producción. Seguiremos los errores de CPU junto con el volumen de solicitudes, usando las muestras parciales de Cloudflare como señal y no como un log completo. Responder bien empieza con evidencia, y ahora tenemos una base más sólida para actuar.
Si quieres entender mejor el rendimiento de tu sitio y priorizar las mejoras que más importan, solicita nuestra auditoría web en 48 horas. Te ayudaremos a convertir síntomas confusos en un plan práctico y priorizado.