18 листопада 2025 року інфраструктура Cloudflare пережила один із наймасштабніших збоїв за останні роки. Помилка в конфігурації внутрішньої аналітичної системи призвела до ланцюгової відмови проксі-інфраструктури, що тимчасово вивело з ладу тисячі сайтів і сервісів по всьому світу. Керівництво компанії підтвердило, що інцидент не був наслідком кібератаки, а став результатом некоректної зміни прав доступу в базі даних ClickHouse.
Хронологія збою Cloudflare: від підозри на DDoS до виявлення помилки конфігурації
Перші симптоми інциденту з’явилися приблизно о 11:20 UTC: ресурси, що використовують Cloudflare як CDN і захисний периметр, почали періодично втрачати доступність. Картина була схожа на масштабну DDoS-атаку: сервіси то відновлювали роботу, то знову «падали», що типово для сценаріїв автоматичного протидії атакам на відмову в обслуговуванні.
Однак подальший аналіз телеметрії, логів та внутрішніх метрик показав, що джерело проблеми знаходиться всередині самої інфраструктури Cloudflare. Під час оновлення прав доступу (ACL/RBAC) у кластері ClickHouse було виконано помилковий запит, який вплинув на формування службового конфігураційного артефакту для системи Bot Management.
ClickHouse та Bot Management: критичний ланцюг у системі захисту Cloudflare
Cloudflare широко застосовує аналітику трафіку для управління ботами та фільтрації шкідливих запитів. Окремий кластер ClickHouse використовується для побудови так званого feature file — файлу з поведінковими ознаками й характеристиками ботів та підозрілих патернів трафіку.
Цей feature file розповсюджується по всій глобальній мережі Cloudflare та завантажується на проксі-сервери. На його основі механізми Bot Management приймають рішення: пропустити запит, застосувати додаткову перевірку чи заблокувати його. Таким чином, файл фактично є центральним елементом конфігурації системи кіберзахисту.
Будь-яке порушення структури, формату або розміру такого конфігураційного файлу миттєво впливає на значну частину інфраструктури, що й стало точкою відмови в цьому інциденті.
Як одна SQL-помилка збільшила конфігураційний файл і запустила ланцюг відмов
Метою зміни в ClickHouse було надати розширений доступ до низькорівневих даних і метаданих для аналітики. Однак запит, який формував feature file, був сконструйований так, що повертав істотно більше інформації, ніж планувалося. Внаслідок цього розмір конфігураційного файлу збільшився більш ніж удвічі.
У проксі-інфраструктурі Cloudflare був зафіксований жорсткий ліміт на максимальний розмір цього файлу. Коли нова версія перевищила порогове значення, проксі-сервіси почали інтерпретувати її як некоректну та аварійно завершували роботу. Додатково ситуацію ускладнювало те, що кластер генерував оновлений feature file кожні п’ять хвилин, без повноцінної валідації, створюючи хвилеподібний характер збоїв.
«Флаппінг» інфраструктури: чому це виглядало як атака
Не всі вузли ClickHouse одночасно отримали нові права доступу, тому некоректний файл формувався лише на частині нод. У результаті одні проксі-сервери завантажували коректну конфігурацію, інші — перевантажений та неприйнятний файл. Це призводило до ефекту flapping: система то поверталася в робочий стан, то знову переходила в аварійний, залежно від того, яка версія конфігурації потрапляла в кеш і розповсюдження.
За публічними коментарями керівництва Cloudflare, саме ці коливання створювали враження зовнішньої DDoS-атаки. Близько 13:00 UTC всі ноди ClickHouse вже генерували «поганий» файл, і інфраструктура досягла фактично «стабільного стану відмови» — збої стали масовими та постійними.
Масштаб впливу: європейські дата-центри та глобальні онлайн-сервіси
За даними сервісів моніторингу доступності, проблеми фіксувалися в європейських точках присутності Cloudflare, включно з Амстердамом, Берліном, Франкфуртом, Варшавою, Віднем, Цюріхом, Стокгольмом та іншими містами. Платформи на кшталт Downdetector зареєстрували десятки тисяч скарг на недоступність вебсайтів та хостингів.
Користувачі повідомляли про перебої в роботі великих онлайн-платформ, зокрема Spotify, Twitter, OpenAI, Anthropic, AWS, Google та інших сервісів, які покладаються на Cloudflare для доставки контенту та захисту від атак. Інцидент ще раз показав, наскільки сильно сучасний інтернет залежить від небагатьох великих провайдерів мережевої інфраструктури.
Як Cloudflare локалізувала збій і які уроки має винести бізнес
Для стабілізації ситуації команда Cloudflare зупинила автоматичну генерацію пошкоджених конфігураційних файлів, вручну помістила у чергу перевірену «здорову» версію feature file і виконала примусовий перезапуск основних проксі-компонентів. Повне відновлення роботи зайняло близько шести годин, і до 17:44 UTC глобальна мережа була повернута в штатний режим.
За оцінкою керівництва, це став найбільший інцидент з 2019 року. У відповідь Cloudflare анонсувала посилення валідації конфігураційних файлів, впровадження додаткових механізмів екстреного відключення функціоналу (kill switch) та перегляд обробки помилок у критичних модулях проксі.
Для організацій цей кейс є наочним нагадуванням про важливість низки практик кібербезпеки й експлуатації: обов’язкова автоматична перевірка конфігурацій перед розгортанням, поетапний (canary) вивід змін, контроль розміру й структури службових файлів, розвинена система observability, що дозволяє швидко відрізнити внутрішній технічний збій від зовнішньої атаки. Варто провести ревізію керування правами доступу до критичних баз даних, протестувати сценарії швидкого відкату змін і побудувати багаторівневу відмовостійкість. Чим вищою є залежність бізнесу від хмарних і CDN-провайдерів, тим обов’язковішими стають регулярні навчання команд та відпрацювання інцидентів, щоб одна помилка в конфігурації не переростала у глобальний збій.
