Cloudflare se ha ganado en la última década la reputación de ser uno de los gigantes tecnológicos más temidos por los atacantes de Internet. Su infraestructura global actúa como un escudo anti-DDoS capaz de frenar oleadas de tráfico malicioso que dejarían de rodillas a cualquier otra infraestructura online. Es, de hecho, la compañía que presume de haber contenido ataques de más de 11 terabits por segundo y miles de millones de peticiones por segundo.
Además, para entidades como LaLiga, que ha intentado combatir la difusión no autorizada de retransmisiones deportivas en tiempo real, Cloudflare se ha convertido en una pesadilla que no se aviene a pactar con ellos el bloqueo de dichas emisiones, lo que lo ha convertido en la diana de todos sus dardos legales y mediáticos.
Sin embargo, el pasado día 12 de septiembre, el cazador se convirtió en su propia presa: la empresa especializada en parar ciberataques se auto–DDoSéo por culpa de un error de programación en su panel de control. El resultado: más de una hora de caída de sus APIs internas y de su dashboard, herramienta clave para millones de clientes en todo el mundo.
¿Cómo se puede “auto-atacar” una empresa como Cloudflare?
La ironía del suceso no ha pasado desapercibida: Cloudflare explicó en un informe pormenorizado que el incidente comenzó con el despliegue de una nueva versión de su Dashboard (el panel de gestión que usan los clientes). Y dentro del código React de esa interfaz había un error en el uso del hook useEffect.
Así, en lugar de ejecutar una petición a la Tenant Service API (el servicio encargado de autorizar solicitudes) una sola vez por renderizado, el bug hacía que se repitiera en bucle cada vez que cambiaba el estado de la aplicación. En la práctica, esto significaba miles de llamadas redundantes en cuestión de segundos.
El momento no pudo ser peor: casi en paralelo, el equipo de ingeniería había desplegado una nueva versión de la propia Tenant Service API. La combinación de ambos factores desencadenó lo que en la jerga se conoce como un ‘thundering herd’: una estampida de peticiones legítimas, pero descontroladas que saturó al servicio, incapaz de recuperarse por sí solo.
El uso problemático de ‘useEffect’
El epicentro de esta tormenta fue un viejo conocido para la comunidad de desarrolladores de React: el hook useEffect. Esta función, pensada para manejar efectos secundarios, puede convertirse en una trampa si se configuran incorrectamente sus dependencias. En este caso, se incluyó un objeto que React trataba como ‘nuevo’ en cada cambio de estado, lo que provocaba que el efecto se ejecutase repetidamente en un ciclo infinito.
La propia documentación oficial de React advierte de este tipo de errores, y en foros como Reddit el caso de Cloudflare ha reavivado el debate sobre si la industria depende en exceso de useEffect para tareas que deberían resolverse de otra forma.
Cronología de una caída anunciada
El ‘auto-DDoS’ se desarrolló a lo largo de tres horas de vértigo:
- 16:32 UTC: Se lanza la nueva versión del Dashboard con el bug.
- 17:50 UTC: Despliegue de la nueva Tenant Service API.
- 17:57 UTC: El servicio queda abrumado. El dashboard se vuelve inoperativo y las APIs empiezan a devolver errores 5xx.
- 18:17 UTC: Tras añadir más recursos, la disponibilidad de las APIs sube al 98%, pero el dashboard sigue caído.
- 18:58 UTC: Cloudflare publica un parche para eliminar rutas con errores… pero empeora la situación.
- 19:12 UTC: Se revierten los cambios y todo vuelve a la normalidad.
Eso sí, durante todo el incidente, la red de datos de Cloudflare siguió funcionando: el tráfico de webs y servicios protegidos nunca se vio afectado: solo la plataforma de gestión quedó fuera de combate.
Vía | Cloudflare
Imagen | Marcos Merino mediante IA
En Genbeta | Las webs saqueadas por empresas de IA les pagarán con su propia medicina: Cloudflare quiere poner a buen recaudo el contenido ‘humano’
