18 ноября 2025 года инфраструктура Cloudflare, одного из ключевых провайдеров CDN и сетевой безопасности, столкнулась с одним из самых крупных сбоев за последние годы. Проблема затронула глобальную сеть компании и привела к массовым перебоям в работе сайтов и сервисов по всему миру. Позже гендиректор Cloudflare Мэттью Принс подробно объяснил, что в основе инцидента лежала не кибератака, а ошибка при изменении прав доступа к базе данных.
Что произошло: от подозрения на DDoS до выявления ошибки конфигурации
Первые признаки инцидента появились около 11:20 UTC, когда начала «плавать» доступность ряда ресурсов, использующих Cloudflare в качестве обратного прокси и защитного периметра. Из-за масштаба и характера отказов команда изначально предположила масштабную DDoS-атаку. Система то приходила в норму, то снова выходила из строя, что типично для сценариев автоматического противодействия атакам.
Однако детальный анализ показал, что корень проблемы находился внутри инфраструктуры Cloudflare. При обновлении прав доступа в кластере ClickHouse — это распределённая СУБД, используемая компанией для высоконагруженной аналитики — была допущена ошибка в запросе, формирующем служебный конфигурационный файл для системы Bot Management.
Роль ClickHouse и Bot Management в инфраструктуре Cloudflare
Cloudflare активно использует аналитику для фильтрации вредоносного трафика и управления ботами. Отдельный кластер ClickHouse генерирует так называемый feature file — файл с признаками и поведенческими характеристиками ботов. Эти данные распространяются по всей сети Cloudflare и используются прокси-серверами для принятия решений о маршрутизации и блокировке подозрительных запросов.
Именно этот файл, по сути являющийся критическим элементом конфигурации системы защиты, стал «точкой отказа». Любая ошибка в его структуре или размере способна повлиять сразу на значительную часть глобальной инфраструктуры.
Как одна ошибка увеличила файл и запустила цепочку сбоев
Цель изменения прав доступа в ClickHouse заключалась в том, чтобы предоставить пользователям доступ к дополнительным низкоуровневым данным и метаданным. Однако запрос, использованный для извлечения этих данных, был составлен некорректно: он возвращал больше информации, чем предполагалось. В результате размер feature file вырос более чем вдвое.
В системе был предусмотрен жесткий лимит на размер этого файла. Как только новый файл превышал установленный порог, прокси-сервера воспринимали его как недопустимый и завершали работу сбоем. При этом кластер генерировал новую версию файла каждые пять минут, что создало дополнительную нагрузку и волнообразный характер отказов.
Эффект «флаппинга»: почему система казалась атакованной
Дополнительное осложнение внес тот факт, что не все ноды ClickHouse одновременно получили обновлённые права доступа. «Испорченный» файл формировался только на части узлов. В результате одни прокси получали корректную конфигурацию, другие — неправильную. Система постоянно переходила из рабочего состояния в аварийное и обратно, в зависимости от того, какая версия файла оказывалась в раздаче.
По словам Мэттью Принса, именно эти колебания создали иллюзию внешней атаки: сеть Cloudflare то восстанавливалась, то снова падала, как будто кто-то целенаправленно выводил её из строя. К 13:00 UTC все ноды ClickHouse уже генерировали «плохой» файл, и инфраструктура вошла в так называемое «стабильное состояние отказа» — проблемы стали постоянными и массовыми.
География и влияние: от европейских дата-центров до глобальных сервисов
По сообщениям СМИ и данным мониторинговых сервисов, сбои затронули узлы Cloudflare по всей Европе: Амстердам, Берлин, Франкфурт, Варшава, Вена, Цюрих, Стокгольм и ряд других городов. Платформа Downdetector зафиксировала десятки тысяч жалоб на недоступность сайтов и хостингов.
Пользователи также сообщали о проблемах в работе крупных интернет-сервисов, включая Spotify, Twitter, OpenAI, Anthropic, AWS, Google и множество других проектов, полагающихся на Cloudflare для ускорения доставки контента и защиты от атак. Это наглядно демонстрирует, насколько сильно современный интернет зависит от нескольких крупных провайдеров сетевой инфраструктуры.
Как Cloudflare остановила сбой и какие выводы сделаны
Для стабилизации ситуации команда Cloudflare остановила генерацию ошибочных файлов, вручную поместила в очередь заведомо корректную версию конфигурации и выполнила принудительный перезапуск основного прокси. Полное восстановление сервисов заняло около шести часов, и к 17:44 UTC работа сети была приведена в штатный режим.
По оценке Принса, это был самый крупный инцидент в компании с 2019 года. Руководство Cloudflare публично принесло извинения и обозначило приоритетные меры: усиление валидации конфигурационных файлов, внедрение дополнительных механизмов экстренного отключения функций (kill switch), а также пересмотр логики обработки ошибок во всех ключевых модулях прокси.
Для специалистов по кибербезопасности и эксплуатации инфраструктуры этот инцидент подчёркивает важность нескольких практик: автоматической проверки конфигураций перед развёртыванием, поэтапного (canary) выката изменений, строгого контроля за ростом служебных файлов, а также развитой системы наблюдаемости (observability), позволяющей быстро отличить внутренний сбой от внешней атаки.
Организациям стоит использовать этот случай как повод для ревизии собственных процессов: проверить, как управляются права доступа к критичным базам данных, какие есть ограничения и тесты для конфигурационных артефактов, насколько быстро можно откатить неудачное изменение по всей инфраструктуре. Чем больше бизнес зависит от облачных и сетевых провайдеров, тем важнее выстраивать многоуровневую отказоустойчивость и регулярное обучение команд работе с инцидентами, чтобы единичная ошибка в конфигурации не превращалась в глобальный сбой.
