Egy regex vitte le a Cloudflare-t. 27 percre.
2019.
2019. július 2., 13:42 UTC: a Cloudflare webalkalmazás-tűzfalának egy új szabálya élesedik több mint 180 városban, körülbelül két másodperc alatt. Ez egy XSS szabály szimulációs módban, így semmit sem blokkol, de minden kérésnél fut, és .*(?:.*=.*) végződésű. A PCRE visszalép, minden HTTP-kéréseket kiszolgáló CPU mag 100%-ra pörög, és minden Cloudflare-proxyn keresztül futó oldal 502-es hibát ad vissza 27 percig; a forgalom 82%-kal esik. A "kill switch" a Cloudflare Access mögött van, ami a Cloudflare mögött van. Boncolás a Cloudflare saját beszámolója alapján: a CPU-védelmet hetekkel korábban távolították el egy átalakítás során, aminek célja a CPU megtakarítása volt, az eljárás, amely lehetővé tette, hogy bármely szabály kihagyja a "staging" fázist, a motor, amelynek nincs komplexitási garanciája, a 11 ok és a 7 javítás. A javításra vonatkozó ítélet: SHIP IT.
Olvassa el az írott kiadást (angolul) ↗
Amit ez a videó tartalmaz
- 13:31–13:42 UTC: PR egyesítve, CI zöld (nincs CPU teszt), a Quicksilver a szabályt több mint 180 városba továbbítja; a WAF szabályok kihagyják a DOG → PIG → Canary szakaszokat
- 13:45–14:07: első oldal; CPU 100% világszerte, forgalom −82%, 502-es hibák mindenhol; a belső vezérlőpult a Cloudflare Access mögött van, ami leállt; néhány hitelesítő adat lejárt; egy ritkán gyakorolt bypass
- 14:07–14:09: globális WAF leállítás; forgalom és CPU normális 27 perc után; 14:52 WAF visszatér a szabály nélkül
- Július 2 (15:50 UTC) és július 12: a Cloudflare még aznap közzéteszi a megjegyzést és a teljes utólagos elemzést; a CPU-védelem újra hozzáadva, 3 868 szabály újraolvasva, "staged rollout"-ok, áttérés lineáris idejű regex motorra
Lefordított átirat
Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.
0:00 Egy reguláris kifejezés élesedik egyszerre minden Cloudflare szerveren, és a következő huszonhét percben az általa védett oldalak 502-es oldalt mutatnak, ami egy tűzfal esetében a lehető legszigorúbb beállítás. 2019. július 2., 13:42 UTC. A Cloudflare két órán belül posztol: nem támadás, hanem hibás telepítés, a forgalom 82 százalékkal csökkent. Tíz nappal később John Graham-Cumming CTO közzéteszi a teljes utólagos elemzést, a regexet is beleértve, és a Hacker News 698 pontot ad neki,
0:26 ami egy leállás esetében álló ováció. Hogyan történik, miért lehetséges, és kit terhel valójában a felelősség. Ez a The Daily Diff, boncolás. 13:31. Egy pull request egyesül: egy új tűzfal szabály a cross-site scripting ellen, szimulációs módban, így semmit sem blokkol. 13:37, a tesztek sikeresek; egyik sem méri a CPU-t. 13:42, a szabály két másodperc alatt 180 városba kerül kiszállításra, mert a WAF szabályok kihagyják a "dog", "pig" és "canary" szakaszokat, amiket más kiadások kapnak.
0:54 13:45, az első oldal. 13:49, a Hacker News-on van egy szál az állapotoldalról, ami még mindig azt mutatja, hogy minden rendszer működőképes. A szabály dot-starral, dot-starral, egyenlő jellel, dot-starral végződik: bármi, aztán bármi, aztán egy egyenlőségjel. A PCRE mohón tippel, hibázik, és visszalép az összes többi elválasztáson keresztül. Az x egyenlő x 23 lépést igényel. Húsz x az egyenlő után: 555.
1:15 Húsz x, nincs egyenlő jel: 4 067 lépés, hogy semmit se találjon. Futtassa ezt minden kérésnél, és minden mag száz százalékon fut, alaposan, semmit sem csinálva. Két őrnek el kellett volna kapnia. A szabályokra vonatkozó CPU-korlátot hetekkel korábban tévedésből eltávolították, egy átalakítás során, aminek célja a WAF kevesebb CPU használata volt. És az eljárás lehetővé teszi, hogy bármely szabály kihagyja a "staging"-et, mert a szabályok arra valók, hogy megállítsák az élő támadásokat; ez nem volt vészhelyzet, és mégis globálisan ment.
1:37 14:00, a WAF azonosítva; nincs támadás. 14:02, valaki a globális leállítást javasolja: egy komponens, kikapcsolva, világszerte. A kapcsoló a Cloudflare Access mögött van. A Cloudflare Access a Cloudflare mögött van. Néhány hitelesítő adat lejárt a használaton kívüliség miatt, így az internet leggyorsabb hálózata öt percet töltött egy olyan bypass-on, amit senki sem gyakorolt. 14:07, leállítás. 14:09, forgalom normális. git blame: egy kiadás egy sebességgel, globálisan; egy CPU-védelem véletlenül átalakítva;
2:04 egy regex motor felső korlát nélkül. Nem az a mérnök, aki a szabályt írta: a boncolás tizenegy okot sorol fel és senkit sem nevez meg. Hatótáv: 27 perc, a forgalom 82 százaléka, 100 százalék CPU minden magon, minden városban. A műszerfal és az API ugyanazon az élvonalon helyezkedik el, így az ügyfelek még kikapcsolni sem tudják. Hacker News, a boncolás alatt: volt egy problémájuk, használtak egy reguláris kifejezést, most kettő van. Régi vicc. Még mindig fordítódik.
2:28 Ítélet, boncolás: SHIP IT. A CPU-védelem visszatért, mind a 3868 szabályt kézzel átolvassák, a szabályok átmennek a "staging" fázison, és a motor egy lineáris idejű garanciákkal rendelkezőre vált, amelyet Ken Thompson publikált 1968-ban. Hétfő: nincs dot-star dot-star semmiben, ami kérésenként fut, és tartsa a "kill switch"-et távol attól, amit leállít. Küldje el nekem azt az incidenst, amiről még mindig nem beszélhet, a kommentekben, vagy a daily diff dot dev címen.
2:53 És ez a mai diff. Niko vagyok az Axrisi-től. Merge felelősségteljesen.
Források
- 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
