Cloudflare пояснила глобальний збій помилкою Bot Management

Після масштабного збою, який ми висвітлили в матеріалі-аналізі, Cloudflare уточнила, що неполадки стартували о 11:20 UTC: системи почали видавати лавину HTTP-помилок 5xx через внутрішній баг, що не має відношення до кібератак. До 14:30 UTC було відновлено основний трафік, а о 17:06 UTC компанія оголосила про повне повернення сервісів до робочого режиму.

Технічний розбір показує, що збій виник о 11:05 UTC: зміна прав доступу в ClickHouse-кластері змінила поведінку запитів до метаданих і викликала генерацію «feature file» з дублікатами рядків. Його розмір подвоївся і був розісланий по всьому периметру — на всі сервери Cloudflare, що беруть участь в обробці вхідного трафіку.

Цей feature-файл обробляється компонентами базового проксі Cloudflare, які призначають bot-score і застосовують захисні політики до вхідних HTTP-запитів. Проксі-ПЗ мало суворі обмеження на розмір і кількість ознак, які воно здатне завантажити без ризику. Коли в мережу надійшла нова — занадто важка — версія файлу, Bot Management вийшов за ліміт і викликав «panic» в Rust-частині нового движка FL2, через що проксі почало повертати HTTP 5xx на обслуговуваний трафік.

Як пояснила Cloudflare, першим симптомом став стрибок 5xx-відповідей о 11:20 UTC. Далі показник «плавав»: нові feature-файли створювалися раз на п’ять хвилин, і якщо запит на генерацію виконувався на оновленому ClickHouse-вузлі, з’являвся поганий файл; на старому — коректний. Тому система чергувала періоди короткого відновлення і нової відмови, поки всі вузли не перейшли на генерацію помилкової конфігурації, після чого аварія закріпилася остаточно.

Інцидент торкнувся не тільки доставки контенту і захисних механізмів. У переліку Cloudflare фігурують CDN-сервіси, security-інструменти, Turnstile, розподілене сховище Workers KV, продукт Access і адміністративна панель. Користувачі отримували внутрішні екрани помилок, Turnstile не завантажувався на сторінках логіну, Workers KV видавав підвищений потік 5xx, а Access не дозволяв входити в нові сесії — тоді як вже активні з’єднання продовжували працювати. Зростання затримок по CDN пояснювалося тим, що засоби налагодження і спостережності активно споживали ресурс CPU.

На ранніх етапах збою співробітники запідозрили саме атаку: публічна статус-сторінка лягла практично одночасно з сервісами, хоча вона розміщена поза інфраструктурою Cloudflare. Внутрішні чати обговорювали ймовірність потужного удару по production-середовищу і по статус-сторінці одночасно, поки інженери не простежили збій до feature-файлу Bot Management і зміненого запиту метаданих в ClickHouse.

Заходи з відновлення вводилися послідовно. О 13:05 UTC Cloudflare налаштувала обхідні механізми, завдяки яким Workers KV і Access змогли тимчасово працювати на попередньому проксі-ядрі, що знизило рівень помилок. О 14:24 UTC команда зупинила випуск нових конфігів Bot Management і протестувала справну версію. О 14:30 UTC коректний файл розгорнули по всьому периметру, відновивши більшість систем. Решту вузлів перезапускали і очищали від помилок протягом наступних годин. Повне відновлення зафіксували о 17:06 UTC.

Компанія охарактеризувала те, що сталося, як найбільший за впливом збій з 2019 року. Зазвичай проблеми обмежувалися панеллю або новими функціями, але відмову, яка позбавила мережу можливості проводити більшу частину базового трафіку, Cloudflare не переживала більше шести років. Навіть короткочасна неможливість маршрутизації трафіку для провайдера інфраструктури такого високого рівня обертається великими проблемами, що вже й казати про тривалі збої.