← Все продукты

DDoS Protection

Cloudflare DDoS Protection автоматически обнаруживает и подавляет атаки типа «отказ в обслуживании» на сетевом и прикладном уровнях в трафике, проходящем через сеть Cloudflare. На этой странице описаны путь подавления атак, объекты конфигурации, ограничения и доступность по тарифам.

Управление документом

Дана
Технический писатель, Integrity Czech Republic s.r.o.

Обзор

Распределённая атака типа «отказ в обслуживании» пытается сделать сервис недоступным, исчерпав один из ресурсов: пропускную способность канала, обработку пакетов, состояние соединений или параллелизм приложения. Атаки обычно делят по уровням. Атаки на сетевом уровне (L3 и L4) нацелены на пропускную способность и обработку пакетов. Атаки на уровне приложений (L7) отправляют корректно оформленные HTTP-запросы, которые истощают вычислительные ресурсы origin-сервера или бэкенд-сервисов, от которых он зависит.

Cloudflare подавляет атаки в трафике, который попадает в её сеть одним из трёх путей: имя хоста проксируется через Cloudflare, префиксы анонсируются через Magic Transit или TCP- либо UDP-приложение работает через Spectrum. Атаки в трафике, который приходит на origin-сервер другим путём, не подавляются.

Cloudflare указывает, что подавление DDoS-атак предоставляется без тарификации по размеру или частоте атак на всех тарифах (https://developers.cloudflare.com/ddos-protection/, дата обращения: 2026-08-28). Это условие тарификации, а не гарантия доступности при любой нагрузке.

Cloudflare не публикует показатель ёмкости сети в терабитах в секунду на своей публичной странице о сети (по состоянию на 2026-08-28). Поэтому конкретное значение ёмкости здесь не указано. Если вам нужно обязательство по ёмкости, закрепляйте его в договоре, а не берите из документации.

Архитектура

Cloudflare анонсирует одни и те же IP-префиксы из всех своих дата-центров с помощью anycast. Каждый источник трафика маршрутизируется до ближайшей анонсирующей точки, поэтому географически распределённая атака делится между множеством точек, а не сходится в одном центре очистки. Так атака подавляется распределённо, рядом с её источниками, и суммарная мощность подавления равна сумме мощностей всех участвующих точек, а не мощности одного центра.

В каждой точке присутствия системы сэмплирования сравнивают характеристики пакетов и запросов с сигнатурами атак в управляемых наборах правил защиты от DDoS-атак, а также с профилями трафика. При совпадении сигнатуры к тракту передачи данных применяется правило подавления. На сетевом уровне атаки подавляют пакетные фильтры. На уровне приложений их подавляет управляемый набор правил HTTP DDoS Attack Protection, который может применить к подходящим запросам действие block или challenge.

Подавление работает автономно: платформа включает его без действий со стороны клиента и без обращения в поддержку. Cloudflare указывает, что обнаружение и подавление начинаются автоматически, но гарантированного времени подавления не публикует, поэтому числового значения здесь нет.

Есть три модели подключения защиты, и они существенно различаются:

• Обратный прокси. HTTP- и HTTPS-трафик для проксируемых имён хостов. Подавление применяется к запросам, а адрес origin-сервера не виден в DNS.
• Spectrum. Произвольные TCP- или UDP-приложения, проксируемые через Cloudflare, для таких сервисов, как почта, игровые протоколы или сигнализация VoIP.
• Magic Transit. Принадлежащие клиенту IP-префиксы, анонсируемые Cloudflare через BGP, с возвратом очищенного трафика в сеть клиента через GRE, IPsec или CNI. Так защищается вся сеть, включая инфраструктуру, не связанную с HTTP.

Возможности

Модель настройки

Защита от DDoS устроена как управляемые наборы правил в движке наборов правил (ruleset engine), по той же модели, что и WAF. Сами правила ведёт поставщик, редактировать их нельзя; поведение меняют переопределениями.

Переопределять можно два параметра. Чувствительность определяет, насколько легко срабатывает правило; уровни обычно называются default, medium, low и essentially off. Действие определяет, что происходит при совпадении, например block, managed challenge или более мягкая мера. Переопределения задаются для всего набора правил, для отдельного правила или с ограничением по выражению, если это поддерживает тарифный план.

Adaptive DDoS Protection настраивается отдельно и строит профили трафика по одному из признаков: например, по стране клиента, ASN, User Agent или заданной группе origin-серверов. Сначала её включают в режиме наблюдения, а затем переводят в режим принудительного применения.

Для Magic Transit настройка включает подключение префиксов и управление анонсированием BGP, настройку туннеля для возврата очищенного трафика, а также правила Magic Firewall для фильтрации на сетевом уровне. Для Spectrum настраиваются описание приложения, адрес origin-сервера, протокол и порт.

Всеми этими объектами можно управлять через дашборд, API и провайдер Terraform.

Лимиты и ограничения

Значения и состав возможностей ниже взяты из документации Cloudflare по состоянию на 2026-08-28 и могут меняться без уведомления.

• Подавление работает только для трафика, проходящего через Cloudflare. Если IP-адрес origin-сервера доступен напрямую, хост не проксируется или служба работает на порту, который не охвачен зоной или приложением Spectrum, такой трафик идёт в обход защиты.
• Стандартная защита зоны охватывает HTTP и HTTPS. Для протоколов, отличных от HTTP, нужен Spectrum, а для защиты всей сети нужен Magic Transit. Оба продукта относятся к плану Enterprise.
• Adaptive DDoS Protection доступна только на плане Enterprise с подпиской Advanced DDoS Protection и не входит в базовые возможности ни одного тарифа.
• Детализация переопределений для управляемого набора правил HTTP DDoS зависит от тарифа. У зон на тарифе Free возможности управления наиболее ограничены, что усложняет настройку для снижения ложных срабатываний.
• Правила защиты от DDoS работают по паттернам трафика. Атаки на уровне приложений, которые не выходят за обычную частоту запросов, но истощают ресурсоёмкий бэкенд, эти правила могут не остановить. Для таких случаев нужны правила ограничения частоты запросов, кеширование или изменения на стороне приложения.
• Cloudflare не публикует ни гарантированное время подавления атаки, ни показатель ёмкости сети. Обязательства по доступности определяются договором и применимым соглашением об уровне обслуживания, а не документацией по продукту.
• Magic Transit устанавливает минимальные требования к размеру префикса для анонсирования BGP и требует, чтобы клиент контролировал анонсируемое адресное пространство. Перед планированием миграции адресов уточните актуальный минимум у Cloudflare.
• Срок хранения аналитических данных и доступность Logpush для данных об атаках зависят от тарифного плана.

Доступность по планам

Развёртывание

Предварительные требования.

• Перечислите общедоступные имена хостов, публичные IP-адреса, анонсируемые префиксы, открытые порты и не-HTTP службы, такие как почта, VPN-точки входа и интерфейсы управления.
• Определите, какие из них подлежат проксированию, каким требуется Spectrum, а каким Magic Transit.
• Проверьте, не раскрыт ли где-то IP-адрес origin-сервера: журналы Certificate Transparency, исторические записи DNS, заголовки писем с того же хоста, страницы ошибок, раскрывающие имя хоста, и виртуальные хосты по умолчанию, отвечающие на этот IP-адрес.
• Задокументируйте интеграции, которые должны продолжать работать во время переключения и после него: мониторинг, платёжные колбэки, API партнёров и входящие вебхуки.
• Зафиксируйте текущую конфигурацию DNS и значения TTL, чтобы изменение можно было отменить.

Поэтапная проверка. Сначала подключите представительную тестовую зону или имя хоста вне продакшена. Проверьте, что проксирование не меняет поведение приложения, что IP-адреса клиентов считываются из нужного заголовка и что настройки TLS соответствуют возможностям origin-сервера. Сгенерируйте характерную нагрузку и убедитесь, что легитимный трафик не получает challenge.

Настройка.

1. Проксируйте нужные имена хостов, анонсируйте префиксы через Magic Transit или создайте приложения Spectrum для сервисов, работающих не по HTTP.
2. Смените IP-адреса origin-сервера, чтобы ранее известные адреса больше не обслуживали приложение.
3. Настройте межсетевой экран origin-сервера так, чтобы он принимал трафик только из диапазонов IP-адресов Cloudflare (https://www.cloudflare.com/ips/), либо полностью закройте входящий доступ, подключив origin-сервер через Cloudflare Tunnel.
4. Включите Authenticated Origin Pulls, чтобы origin-сервер отклонял соединения без клиентского сертификата Cloudflare.
5. Проверьте переопределения управляемого набора правил HTTP DDoS. Оставляйте чувствительность по умолчанию, если не обнаружено конкретное ложное срабатывание.
6. Если у вас есть лицензия Advanced DDoS Protection, сначала включите Adaptive DDoS Protection в режиме мониторинга и лишь затем в режиме принудительного применения.

Переключение. Заранее снизьте TTL записей DNS, переключите трафик в согласованное окно и держите прежний путь до origin доступным, но закрытым файрволом, пока не завершится проверка.

Верификация.

• Из внешней сети убедитесь, что IP-адрес origin-сервера больше не отвечает на запросы к приложению на портах 80 и 443.
• Убедитесь по соответствующим журналам, что мониторинг, платёжные callback-запросы и интеграции с партнёрами по-прежнему работают корректно.
• Убедитесь, что уведомления об атаках доходят до нужного канала, отправив тестовое уведомление.
• Убедитесь, что после проксирования журналы origin-сервера корректно фиксируют IP-адрес клиента.

Откат. Восстановите прежние записи DNS или отзовите анонс BGP, снова откройте файрвол origin для прежних диапазонов адресов и убедитесь в корректности резолвинга и доступности, прежде чем закрывать инцидент. Поскольку откат снова раскрывает адрес origin, считайте это временным состоянием и повторите ротацию адреса перед следующей попыткой.

Вопросы эксплуатации

Направляйте оповещения об атаках в канал, за которым следят и в нерабочее время, и согласуйте регламент реагирования на инциденты: кто вправе менять переопределения наборов правил во время атаки. Переопределения, изменённые в спешке, часто затягивают инциденты.

Во время атаки отличайте подавленный трафик от влияния на origin-сервер. Много срабатываний подавления при стабильной задержке origin-сервера означает, что защита работает. Если origin-сервер страдает, а срабатываний мало, обычно это значит, что есть обходной путь или атака похожа на легитимный трафик; против такой атаки нужны ограничение частоты запросов или кеширование, а не правила DDoS.

Следите, чтобы изоляция origin-сервера оставалась актуальной. Диапазоны IP-адресов Cloudflare периодически меняются, поэтому подпишитесь на публикуемые диапазоны и настройте автоматическое обновление файрвола либо используйте Cloudflare Tunnel, чтобы полностью отказаться от списков адресов.

Сохраняйте отчёты по итогам инцидентов и сопоставляйте их с метриками origin-сервера. Там, где доступен Logpush, экспортируйте данные вместо того, чтобы полагаться на хранение данных в дашборде.

Сценарии сбоев, которые стоит учесть: адрес origin-сервера, который снова стал известен через недавно выпущенный сертификат; непроксируемый субдомен, повторно созданный скриптом автоматизации; сторонняя интеграция, заблокированная переопределением чувствительности, которое применили во время инцидента и забыли отменить; почтовая инфраструктура в том же адресном пространстве, что и origin-сервер сайта.

Известные особенности

• Само по себе проксирование не делает адрес origin-сервера секретным. Адреса origin-серверов часто утекают через журналы Certificate Transparency, исторические данные DNS, заголовки исходящей почты, неправильно настроенные виртуальные хосты и сканирование IPv4. Эту лазейку закрывает смена адресов в сочетании либо с межсетевым экраном origin-сервера, который пропускает только диапазоны Cloudflare, либо с Cloudflare Tunnel.
• Почтовые записи не должны проксироваться. Если у почты и сайта общий адрес, то смена адреса origin-сервера без отделения почтовой инфраструктуры оставляет адрес видимым в заголовках писем.
• Adaptive protection не входит в базовый продукт. Документация, которая упоминает её наравне со стандартными возможностями без оговорки об отдельной подписке, вводит в заблуждение при планировании ресурсов.
• Атаки на уровне приложений, которые не превышают пороговую частоту запросов, не относятся к задачам набора правил защиты от DDoS. Для ресурсоёмких поисковых эндпоинтов, генерации отчётов без аутентификации и некешируемых динамических страниц нужны правила ограничения частоты запросов, кеширование или меры на уровне приложения.
• Меры подавления могут задеть легитимную автоматизацию: зонды мониторинга и программные клиенты не могут пройти challenge.
• Термин Unmetered mitigation описывает условие тарификации. Он не означает, что атака любого объёма будет поглощена без последствий для работы сервиса.

Взаимодействие с другими продуктами

Управляемые наборы правил защиты от DDoS, правила WAF и правила ограничения частоты запросов выполняются в движке наборов правил в порядке фаз. Защита от DDoS подавляет объёмные флуд-атаки и флуд-атаки с узнаваемой сигнатурой, а WAF и ограничение частоты запросов защищают от целенаправленных злоупотреблений конкретными эндпоинтами. Эти три механизма дополняют друг друга и обычно настраиваются совместно.

Поля Bot Management можно использовать в пользовательских правилах для фильтрации автоматизированного трафика, который не достигает порогов DDoS.

Cloudflare Tunnel полностью закрывает входящий доступ к origin-серверу и поэтому хорошо дополняет защиту от DDoS там, где origin-серверу не нужно принимать прямые соединения.

Magic Transit работает вместе с Magic Firewall (политики сетевого уровня) и Magic WAN (подключение площадок). Spectrum использует те же управляемые наборы правил DDoS для протоколов, отличных от HTTP.

Часто задаваемые вопросы

Защищены ли не-HTTP сервисы стандартным тарифным планом для зоны? Нет. Тарифный план зоны покрывает HTTP и HTTPS для проксируемых имён хостов. Для TCP- и UDP-сервисов нужен Spectrum, а для целых сетей нужен Magic Transit.

Что требуется для применения защиты к сервису? Трафик должен проходить через Cloudflare. Это означает проксируемую запись DNS, приложение Spectrum, анонс Magic Transit или Cloudflare Tunnel. Запись DNS-only защиту не получает.

Как проверить, что защиту обходят? Сравните логи доступа origin-сервера с количеством запросов в Cloudflare за тот же период. Если в логах origin-сервера есть запросы с адресов вне диапазонов Cloudflare, к серверу есть прямой путь, и его нужно закрыть на файрволе origin-сервера.

Источники

• https://developers.cloudflare.com/ddos-protection/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/ddos-protection/managed-rulesets/adaptive-protection/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/magic-transit/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/spectrum/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/, дата обращения 2026-08-31.
• https://www.cloudflare.com/ips/, дата обращения 2026-08-28.
• https://www.cloudflare.com/network/, дата обращения 2026-08-28.

Снимок контента: 2026-08-28.

История изменений