+− THE DAILY DIFFdev & AI news
SHIP IT

Una expresión regular tumbó Cloudflare. 27 minutos.

2 de julio de 2019, 13:42 UTC: una nueva regla para el Firewall de Aplicaciones Web de Cloudflare entra en funcionamiento en más de 180 ciudades en unos dos segundos.

2 de julio de 2019, 13:42 UTC: una nueva regla para el Firewall de Aplicaciones Web de Cloudflare entra en funcionamiento en más de 180 ciudades en unos dos segundos. Es una regla XSS en modo de simulación, por lo que no bloquea nada, pero aun así se ejecuta en cada solicitud, y termina en .*(?:.*=.*). PCRE retrocede, cada núcleo de CPU que sirve HTTP alcanza el 100 %, y cada sitio proxy de Cloudflare devuelve 502 durante 27 minutos; el tráfico cae un 82 %. El interruptor de emergencia se encuentra detrás de Cloudflare Access, que a su vez está detrás de Cloudflare. Postmortem, del propio informe de Cloudflare: la protección de CPU eliminada semanas antes en una refactorización destinada a ahorrar CPU, el procedimiento que permitía a cualquier regla saltarse el "staging", el motor sin garantía de complejidad, las 11 causas y las 7 soluciones. Veredicto sobre la solución: SHIP IT.

Leer la edición escrita (inglés) ↗

Qué cubre este vídeo

  • 13:31–13:42 UTC: PR fusionado, CI en verde (sin prueba de CPU), Quicksilver envía la regla a más de 180 ciudades; las reglas de WAF se saltan las etapas DOG → PIG → Canary
  • 13:45–14:07: primera página; CPU al 100 % en todo el mundo, tráfico -82 %, 502 por todas partes; el panel de control interno está detrás de Cloudflare Access, que está caído; algunas credenciales han caducado; un desvío raramente practicado
  • 14:07–14:09: terminación global de WAF; tráfico y CPU normales después de 27 minutos; 14:52 WAF vuelve sin la regla
  • 2 de julio (15:50 UTC) y 12 de julio: Cloudflare publica la nota del mismo día y el informe postmortem completo; se vuelve a añadir la protección de CPU, se vuelven a leer 3.868 reglas, despliegues por etapas, se pasa a un motor de expresiones regulares de tiempo lineal

Transcripción traducida

Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube.

0:00 Una expresión regular entra en funcionamiento en todos los servidores de Cloudflare a la vez, y durante los siguientes veintisiete minutos los sitios detrás de ella muestran una página 502, lo que, para un firewall, es la configuración más estricta posible. 2 de julio de 2019, 13:42 UTC. Cloudflare publica en dos horas: no es un ataque, un despliegue defectuoso, tráfico caído un 82 por ciento. Diez días después, el CTO John Graham-Cumming publica el postmortem completo, expresión regular incluida, y Hacker News le da 698 puntos,

0:26 lo que para una caída es una ovación de pie. Cómo sucede, por qué es posible y quién recibe la culpa. Esto es The Daily Diff, postmortem. 13:31. Se fusiona una solicitud de extracción: una nueva regla de firewall contra scripts entre sitios, en modo de simulación, por lo que no bloquea nada. 13:37, las pruebas pasan; ninguna mide la CPU. 13:42, la regla se envía a 180 ciudades en dos segundos, porque las reglas del WAF se saltan las etapas de perro, cerdo y canario que reciben otras versiones.

0:54 13:45, la primera página. 13:49, Hacker News tiene un hilo sobre la página de estado, que todavía dice que todos los sistemas están operativos. La regla termina en punto-asterisco, punto-asterisco, igual, punto-asterisco: cualquier cosa, luego cualquier cosa, luego un signo igual. PCRE adivina de forma codiciosa, falla y retrocede a través de todas las demás divisiones. x igual a x toma 23 pasos. Veinte x después del igual: 555.

1:15 Veinte x, sin signo igual: 4.067 pasos para no encontrar nada. Ejecuta eso en cada solicitud y cada núcleo estará al cien por cien, sin hacer nada, completamente. Dos guardias deberían haberlo detectado. El límite de CPU en las reglas fue eliminado por error semanas antes, en una refactorización destinada a hacer que el WAF usara menos CPU. Y el procedimiento permite que cualquier regla se salte el "staging", porque las reglas existen para detener ataques en vivo; esta no era una emergencia, y se globalizó de todos modos.

1:37 14:00, se identifica el WAF; no hay ataque. 14:02, alguien propone la terminación global: un componente, apagado, en todo el mundo. El interruptor está detrás de Cloudflare Access. Cloudflare Access está detrás de Cloudflare. Algunas credenciales han caducado por desuso, por lo que la red más rápida de internet pasa cinco minutos en un desvío que nadie había practicado. 14:07, "kill". 14:09, tráfico normal. git blame: un despliegue con una velocidad, global; una protección de CPU eliminada por

2:04 accidente; un motor de expresiones regulares sin límite superior. No el ingeniero que escribió la regla: el postmortem enumera once causas y no nombra a nadie. Radio de impacto: 27 minutos, 82 por ciento del tráfico, 100 por cien de CPU en cada núcleo, en cada ciudad. El panel de control y la API están detrás del mismo borde, por lo que los clientes ni siquiera pueden apagarlo. Hacker News, bajo el postmortem: tenían un problema, usaron una expresión regular, ahora tienen dos. Viejo chiste. Todavía compila.

2:28 Veredicto, postmortem: SHIP IT. La protección de CPU ha vuelto, las 3.868 reglas se leen a mano, las reglas pasan por el "staging", y el motor se mueve a uno con garantías de tiempo lineal, publicado por Ken Thompson en 1968. Lunes: no punto-asterisco punto-asterisco en nada que se ejecute por solicitud, y mantén el interruptor de apagado fuera de lo que apaga. Envíame el incidente del que todavía no se te permite hablar, en los comentarios, o en the daily diff dot dev.

2:53 Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusione responsablemente.

Fuentes

  1. John Graham-Cumming, "Details of the Cloudflare outage on July 2, 2019" (Jul 12, 2019)blog.cloudflare.com
  2. Matthew Prince, "Cloudflare outage caused by bad software deploy (updated)" (Jul 2, 2019)blog.cloudflare.com
  3. Matthew Prince on X, Jul 2, 2019, 14:22 UTCx.com
  4. Matthew Prince on X, Jul 2, 2019, 14:36 UTC ("No evidence yet attack related")x.com
  5. Hacker News, Jul 2, 2019, 13:49 UTC — "Cloudflare Network Performance Issues" (631 points)news.ycombinator.com
  6. Hacker News, Jul 2, 2019 — "Cloudflare outage caused by bad software deploy" (348 points)news.ycombinator.com
  7. Hacker News, Jul 12, 2019 — "Details of the Cloudflare outage on July 2, 2019" (698 points)news.ycombinator.com
  8. TechCrunch, Jul 2, 2019techcrunch.com

Vídeos relacionados