Wyrażenie regularne uszkodziło Cloudflare. 27 minut.
2 lipca 2019, 13:42 UTC: jedna nowa reguła dla zapory sieciowej Cloudflare (Web Application Firewall) zostaje wdrożona w ponad 180 miastach w około dwie sekundy.
2 lipca 2019, 13:42 UTC: jedna nowa reguła dla zapory sieciowej Cloudflare (Web Application Firewall) zostaje wdrożona w ponad 180 miastach w około dwie sekundy. Jest to reguła XSS w trybie symulacji, więc niczego nie blokuje, ale nadal działa przy każdym żądaniu i kończy się na .*(?:.*=.*). PCRE wykonuje operację wycofywania, każdy rdzeń CPU obsługujący żądania HTTP osiąga 100%, a każda strona proxy przez Cloudflare zwraca błąd 502 przez 27 minut; ruch spada o 82%. Wyłącznik awaryjny znajduje się za Cloudflare Access, który z kolei znajduje się za Cloudflare. Analiza powypadkowa, z własnego opisu Cloudflare: osłona CPU usunięta tygodnie wcześniej w refaktoryzacji mającej na celu oszczędność CPU, procedura, która pozwalała każdej regule pominąć etap przejściowy, silnik bez gwarancji złożoności, 11 przyczyn i 7 poprawek. Werdykt dotyczący poprawki: SHIP IT.
Przeczytaj wydanie pisemne (angielski) ↗
Co obejmuje ten film
- 13:31–13:42 UTC: Scalono PR, CI zielone (brak testu CPU), Quicksilver wypycha regułę do ponad 180 miast; reguły WAF pomijają etapy DOG → PIG → Canary
- 13:45–14:07: pierwsza strona; CPU 100% na całym świecie, ruch −82%, wszędzie błędy 502; wewnętrzny panel kontrolny znajduje się za Cloudflare Access, który nie działa; niektóre poświadczenia wygasły; rzadko ćwiczona procedura obejścia
- 14:07–14:09: globalne wyłączenie WAF; ruch i CPU normalne po 27 minutach; 14:52 WAF wraca bez reguły
- 2 lipca (15:50 UTC) i 12 lipca: Cloudflare publikuje notatkę z tego samego dnia i pełną analizę powypadkową; ponownie dodano zabezpieczenie CPU, ręcznie sprawdzono 3 868 reguł, wdrożenia etapowe, przejście na silnik wyrażeń regularnych o liniowym czasie wykonania
Przetłumaczona transkrypcja
Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.
0:00 Jedno wyrażenie regularne zostaje jednocześnie uruchomione na każdym serwerze Cloudflare, a przez następne dwadzieścia siedem minut strony za nim pokazują stronę z błędem 502, co, dla zapory sieciowej, jest najsurowszym możliwym ustawieniem. 2 lipca 2019 roku, 13:42 UTC. Cloudflare publikuje w ciągu dwóch godzin: to nie atak, tylko błędne wdrożenie, ruch spadł o 82 procent. Dziesięć dni później CTO John Graham-Cumming publikuje pełną analizę powypadkową, włączając wyrażenie regularne, a Hacker News przyznaje mu 698 punktów,
0:26 co w przypadku awarii jest owacją na stojąco. Jak to się stało, dlaczego było to możliwe i kto faktycznie ponosi winę. To jest The Daily Diff, analiza powypadkowa. 13:31. Żądanie pull zostaje scalone: jedna nowa reguła zapory sieciowej przeciwko skryptom międzywitrynowym, w trybie symulacji, więc niczego nie blokuje. 13:37, testy przechodzą; żaden nie mierzy obciążenia CPU. 13:42, reguła jest wysyłana do 180 miast w dwie sekundy, ponieważ reguły WAF pomijają etapy dog, pig i canary, które otrzymują inne wydania.
0:54 13:45, pierwsza strona. 13:49, Hacker News ma wątek na stronie statusu, która nadal mówi, że wszystkie systemy działają. Reguła kończy się na gwiazdka-kropka, gwiazdka-kropka, równa się, gwiazdka-kropka: cokolwiek, potem cokolwiek, potem znak równości. PCRE zgaduje zachłannie, zawodzi i wraca przez każdy inny podział. x równa się x zajmuje 23 kroki. Dwadzieścia x-ów po znaku równości: 555.
1:15 Dwadzieścia x-ów, brak znaku równości: 4 067 kroków, aby niczego nie znaleźć. Uruchom to na każde żądanie, a każdy rdzeń jest w stu procentach, gruntownie, nic nie robiąc. Dwa zabezpieczenia powinny to wychwycić. Limit CPU dla reguł został omyłkowo usunięty tygodnie wcześniej, w refaktoryzacji mającej na celu zmniejszenie zużycia CPU przez WAF. A procedura pozwala każdej regule pominąć etap testowania, ponieważ reguły istnieją, aby powstrzymać ataki na żywo; ta nie była pilna, a i tak objęła cały świat.
1:37 14:00, WAF zostaje zidentyfikowany; brak ataku. 14:02, ktoś proponuje globalne wyłączenie: jeden komponent, wyłączony, na całym świecie. Przełącznik jest za Cloudflare Access. Cloudflare Access jest za Cloudflare. Niektóre poświadczenia wygasły z powodu nieużywania, więc najszybsza sieć w internecie spędza pięć minut na obejściu, którego nikt nie ćwiczył. 14:07, zabicie. 14:09, ruch normalny. git blame: wdrożenie z jedną prędkością, globalne; zabezpieczenie CPU omyłkowo usunięte przez
2:04 refaktoryzację; silnik wyrażeń regularnych bez górnego limitu. Nie inżynier, który napisał regułę: analiza powypadkowa wymienia jedenaście przyczyn i nie wymienia nikogo z imienia. Promień rażenia: 27 minut, 82 procent ruchu, 100 procent CPU na każdym rdzeniu, w każdym mieście. Pulpit nawigacyjny i API znajdują się za tą samą krawędzią, więc klienci nie mogą nawet ich wyłączyć. Hacker News, pod analizą powypadkową: mieli jeden problem, użyli wyrażenia regularnego, teraz mają dwa. Stary żart. Nadal się kompiluje.
2:28 Werdykt, analiza powypadkowa: SHIP IT. Zabezpieczenie CPU jest z powrotem, wszystkie 3 868 reguł są odczytywane ręcznie, reguły przechodzą przez etap testowania, a silnik przechodzi na taki z gwarancjami liniowego czasu wykonania, opublikowanymi przez Kena Thompsona w 1968 roku. Poniedziałek: brak gwiazdka-kropka gwiazdka-kropka w czymkolwiek, co działa na żądanie, i trzymaj wyłącznik awaryjny z dala od rzeczy, które zabija. Wyślij mi incydent, o którym nadal nie wolno ci mówić, w komentarzach, lub na daily diff dot dev.
2:53 I to jest różnica na dziś. Jestem Niko z Axrisi. Scalaj odpowiedzialnie.
Źródła
- John Graham-Cumming, "Details of the Cloudflare outage on July 2, 2019" (Jul 12, 2019)blog.cloudflare.com
- Matthew Prince, "Cloudflare outage caused by bad software deploy (updated)" (Jul 2, 2019)blog.cloudflare.com
- Matthew Prince on X, Jul 2, 2019, 14:22 UTCx.com
- Matthew Prince on X, Jul 2, 2019, 14:36 UTC ("No evidence yet attack related")x.com
- Hacker News, Jul 2, 2019, 13:49 UTC — "Cloudflare Network Performance Issues" (631 points)news.ycombinator.com
- Hacker News, Jul 2, 2019 — "Cloudflare outage caused by bad software deploy" (348 points)news.ycombinator.com
- Hacker News, Jul 12, 2019 — "Details of the Cloudflare outage on July 2, 2019" (698 points)news.ycombinator.com
- TechCrunch, Jul 2, 2019techcrunch.com



