Resumen

  • El 2 de julio de 2019, Cloudflare distribuyó una regla WAF aprobada a su borde mundial en cuestión de segundos; una expresión regular entró en retroceso catastrófico, agotó la CPU de los procesos HTTP/HTTPS y causó errores 502 durante 27 minutos.
  • La velocidad defensiva debe conservarse para una amenaza activa, pero no como permiso ordinario: el cambio cotidiano requiere límites de recursos, despliegue progresivo y retirada inmediata, mientras que autenticación, estado y mando de emergencia deben sobrevivir fuera del sistema afectado.

No fue un fallo de distribución

A las 13:31 UTC, el cambio había superado revisión y se fusionó. A las 13:37, TeamCity realizó la construcción y las pruebas. A las 13:42, un proceso automatizado puso en marcha la distribución de una modificación menor para detectar ataques XSS.

El sistema de distribución cumplió su promesa. Quicksilver estaba diseñado para llevar configuración a toda la red de Cloudflare con una rapidez excepcional. El informe de la empresa habla de más de 180 ciudades, unas 350 modificaciones por segundo de media y un percentil 99 mundial de 2,29 segundos. Una explicación arquitectónica posterior describe la misma propiedad en cientos de ciudades.

La rapidez tenía un propósito legítimo. Una WAF que espera demasiado frente a una vulnerabilidad explotada permite que el adversario use la ventana. Cloudflare había demostrado el valor de una regla mundial rápida al proteger contra una vulnerabilidad grave de SharePoint.

Pero la modificación del 2 de julio no pertenecía a una emergencia. El procedimiento permitía que una regla normal tomara la vía directa global. Los ensayos comprobaban los casos que debían bloquearse y los que debían pasar. No medían el trabajo máximo que una sola solicitud podía imponer a la expresión.

Ahí aparece la diferencia entre transportar y autorizar. Quicksilver transportó exactamente lo que recibió. La aprobación, sin embargo, había valorado una decisión lógica y había entregado además una facultad computacional: ejecutar esa decisión frente al tráfico de todo el mundo. La expansión ocurrió antes de que la observación pudiera evaluar su precio.

La semántica correcta no limita la CPU

La expresión se ejecutaba en un motor basado en PCRE y producía un retroceso enorme con determinados datos. Un evaluador de retroceso explora alternativas hasta encontrar o descartar una coincidencia. En expresiones habituales puede ser muy eficaz. Una estructura ambigua y repetitiva puede multiplicar las rutas de búsqueda hasta convertir el tiempo de ejecución en exponencial.

La respuesta final no tiene que ser errónea. El daño nace del camino que la máquina recorre para encontrarla.

Por eso una regla tiene dos contratos. El primero define qué tráfico representa una amenaza. El segundo limita CPU, memoria y tiempo de cola por solicitud. Probar el primero sin el segundo demuestra comportamiento funcional, no seguridad operativa.

La WAF de Cloudflare formaba parte del camino de atención HTTP y HTTPS y aplicaba miles de reglas a un caudal inmenso. Al dispararse el coste, los procesos que servían ese tráfico agotaron sus núcleos. Las funciones principales de proxy, CDN y WAF dejaron de responder juntas.

Los servidores web frontales todavía disponían de CPU para generar páginas 502. Lo que no podían hacer era alcanzar los procesos de atención HTTP/HTTPS. Este detalle impide decir que todo núcleo de toda máquina quedó inutilizado: sobrevivía la capa que anunciaba el error, no la que prestaba el servicio.

La cadena causal tampoco termina en la expresión. Cloudflare reveló que anteriormente había existido una protección contra el consumo excesivo de CPU, retirada por accidente durante una refactorización de rendimiento. El motor no ofrecía una garantía de complejidad, las pruebas no detectaban CPU desbocada y el procedimiento no escalonaba reglas normales. Culpar solo al autor conserva intacta la autoridad que hizo mundial el error.

Tres minutos fueron demasiado

A las 13:45, un ensayo sintético externo de la WAF lanzó la primera alerta PagerDuty. Después fallaron otras comprobaciones de extremo a extremo, descendió el tráfico global, se multiplicaron los 502 y los puntos de presencia avisaron del agotamiento de CPU. La nota inicial sitúa la caída máxima del tráfico de Cloudflare en el 82%; no es una medición del 82% de Internet.

Al principio se barajó una forma de ataque desconocida. A las 14:00, datos de rendimiento, registros y strace señalaban la WAF, y se descartó el ataque. A las 14:02, la sala propuso usar global terminate, un mecanismo capaz de apagar un componente en todas partes.

La reversión ordinaria no servía a velocidad de incidente. Para recuperar el conjunto anterior había que construir dos veces toda la WAF. La maniobra eficaz fue retirar el componente completo, no únicamente la regla, y dejar la corrección precisa para después.

El mando también había quedado dentro del área dañada. Cloudflare usaba su producto Access para autenticación interna. El panel habitual, Jira y el sistema de construcción no estaban accesibles con normalidad. Fue necesario un procedimiento de desvío poco practicado, y algunos ingenieros descubrieron credenciales caducadas por una medida de seguridad asociada a la falta de uso.

La terminación se ejecutó a las 14:07. A las 14:09, la CPU y el tráfico habían recuperado niveles esperados, mientras continuaban otras protecciones. Cloudflare retiró después el tráfico de clientes de pago de una ciudad, probó allí con una muestra y volvió a activar la WAF mundial a las 14:52.

El análisis completo habla de 27 minutos de indisponibilidad; la comunicación inicial, de unos 30. Lo sustancial es que la concesión tardó segundos y la retirada necesitó diagnóstico, acceso alternativo y una acción sobre todo el componente. La restauración precisa terminó más de una hora después del despliegue.

Cambiar el lenguaje de ejecución

Cloudflare anunció que devolvería la protección de CPU, inspeccionaría sus 3.868 reglas, incorporaría perfiles de rendimiento y sustituiría el evaluador por RE2 o una alternativa en Rust. Su artículo de julio de 2020 afirma que la WAF pasó en julio de 2019 de una base PCRE a un motor inspirado en RE2.

RE2 hace de la seguridad una propiedad del evaluador. Garantiza tiempo asintóticamente lineal con la longitud de entrada, limita la memoria mediante un presupuesto configurable y falla de forma controlada al agotarlo. No admite referencias inversas ni aserciones generales de contexto cuando exigirían retroceso.

Esa renuncia restringe la autoridad antes de la revisión humana. Algunas reglas cómodas dejan de expresarse igual, pero el sistema ya no depende de que cada analista reconozca toda explosión combinatoria. La capacidad del lenguaje se convierte en un límite organizativo.

No implica que RE2 gane siempre en rendimiento. Su documentación admite factores constantes mayores para expresiones complejas, y las reglas que usen funciones excluidas necesitan rediseño. PCRE2, por su parte, documenta límites de coincidencias, profundidad y montón. Las fuentes no prueban que esos controles generales estuvieran activos en la ruta de Cloudflare de 2019.

La medición posterior aporta una distinción fina. El cambio de motor no produjo una reducción medible de CPU media, pero sí disminuyó valores atípicos en los percentiles 95 y 99 del tiempo. La mejora importante no estaba en abaratar cada petición corriente, sino en suprimir la facultad de una petición rara para reclamar una proporción extrema del procesador.

El motor tampoco acota toda la WAF. Hay decodificación, normalización, analizadores, cachés e interacciones entre reglas. Los presupuestos deben aplicarse al recorrido completo, no solo a una expresión aislada.

Dos carriles para dos riesgos

La estrategia posterior de Cloudflare conservaba el despliegue mundial inmediato para un ataque activo e introducía etapas para reglas normales. Esa bifurcación evita dos errores: hacer lenta toda defensa o llamar urgente a todo cambio.

Una regla ordinaria puede pasar por análisis de complejidad, entradas adversas y medición de la cadena completa; observarse sin aplicar; ejecutarse en una ubicación, luego sobre una pequeña fracción de tráfico y después en una región. Cada promoción necesita precisión de seguridad, CPU por regla, latencia de cola, errores y disponibilidad de los procesos. Un umbral automático debe poder detener el avance.

El carril urgente acorta exposición previa, pero requiere un incidente, una amenaza documentada, un responsable, una fecha de expiración, límites en vivo y una persona distinta del proponente con poder de retirada. No desaparece el gobierno; se hace explícita la comparación entre el daño de esperar y el daño de actuar.

El canario necesita independencia. Una fracción de sitios que comparta la misma cola o pierda su telemetría ante el fallo no contiene el riesgo ni produce evidencia. Debe incluir tráfico representativo, capacidad separada y un grupo de control.

La retirada debe ser un cambio de estado rápido, no dos construcciones completas. Conviene separar la llave que inhabilita una regla de la que termina el componente. Las dos deben probarse sin panel, identidad ni construcción ordinarios.

El plano de mando necesita aire propio

La dependencia de productos propios no originó el fallo, pero dificultó la recuperación. El panel y la API de clientes atravesaban también el borde afectado. Quienes necesitaban actuar perdieron parte de su capacidad de hacerlo.

No hace falta duplicar toda la plataforma. Basta una superficie de supervivencia: autenticación de emergencia, publicación de estado, terminación mundial, modificaciones mínimas, acceso a pruebas y controles de cliente capaces de reducir daños. Debe usar capacidad y ruta aisladas, con credenciales mantenidas mediante simulacros.

La primacía del código en ejecución de Heng Lu ofrece el criterio. Una revisión, un ticket y un plan escrito coordinan; no transforman por sí solos la realidad. Cuando el código que corre agota la CPU y cierra su propia vía de mando, la etiqueta “aprobado” deja de proteger.

También separa control técnico y control práctico. Poseer una orden de parada no equivale a poder usarla si su autenticación, interfaz, personal o sistema de construcción dependen del objeto que debe detenerse. La autoridad real se prueba durante la pérdida, no en el organigrama.

Límites de la evidencia

Cloudflare es la fuente principal de la cronología, el diseño interno, las causas y los compromisos. Su detalle permite el análisis, pero sigue siendo un relato propio. No hay en estas fuentes un recuento independiente y completo de clientes, dominios, solicitudes o pérdidas económicas.

La empresa declaró que no fue un ataque. El artículo no atribuye una intención hostil ni un disparo deliberado. Quicksilver no creó la expresión ni retiró la protección; amplió el radio porque la aprobación normal podía invocar toda su potencia.

La publicación de 2020 confirma el cambio de motor y resultados en la cola de latencia, no la permanencia de cada corrección anunciada. El caso sustenta una arquitectura de autoridad, no la ausencia futura de fallos en un proveedor o motor.

Fuentes