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

DDoS Protection

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

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

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

Обзор

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

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

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 реализована в виде управляемых наборов правил в движке наборов правил, по той же модели, что используется в WAF. Отдельные правила поддерживаются поставщиком и недоступны для редактирования. Поведение настраивается с помощью переопределений.

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

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

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

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

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

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

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

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

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

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

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

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

Настройка.

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

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

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

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

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

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

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

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

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

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

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

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

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

Совместимость

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

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

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

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

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

Защищены ли не-HTTP сервисы стандартным тарифным планом для зоны? Нет. План zone покрывает 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.

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