Безопасность

Как включить режим «Under Attack» в Cloudflare при DDoS-атаке на сайт

  • 13 минут чтения
  • Команда Hostragons
Как включить режим «Under Attack» в Cloudflare при DDoS-атаке на сайт

Режим «Under Attack» в Cloudflare — это экстренная защита, которая отображает посетителям короткую проверку безопасности и фильтрует бот-трафик на сайте во время DDoS-атаки. В панели Cloudflare достаточно выбрать нужный сайт, перейти в раздел Security и включить режим «Under Attack». Это позволит за считанные минуты замедлить интенсивные HTTP/HTTPS запросы, сохранить доступ реальных пользователей и снизить нагрузку на сервер. Однако этот режим не является постоянным решением — его нужно использовать вместе с правильными настройками прокси DNS, правилами WAF, ограничением скорости запросов, кешированием и безопасностью исходного сервера.

В этом руководстве мы подробно разберём, как включить режим «Under Attack» в Cloudflare, когда его стоит применять, какие настройки его поддерживают и как безопасно вернуть сайт в обычный режим после атаки. Цель — дать понятный чек-лист для быстрого реагирования и как можно скорее восстановить доступность сайта.

Что такое режим «Under Attack» в Cloudflare?

Режим «Under Attack» — это повышенный уровень защиты от Cloudflare для экстренных ситуаций. При его активации Cloudflare заставляет посетителей пройти короткую проверку браузера, которая занимает несколько секунд. Это усложняет задачу автоматическим ботам, простым HTTP-флуд-атакам и другим вредоносным клиентам, которые пытаются напрямую нагружать сайт.

Основная задача этого режима — смягчать атаки на уровне приложения (Layer 7). Например, если на главную страницу идут тысячи GET-запросов в секунду, на страницу входа WordPress — интенсивные POST-попытки, на поисковую страницу — ресурсоёмкие запросы, а на корзину — поддельный трафик, «Under Attack» быстро помогает сдержать напор.

Важно понимать, что «Under Attack» фильтрует веб-запросы, но если IP сервера открыт и атакуется напрямую, или если атака идёт на уровне сетевых протоколов (Layer 3/4), нужны дополнительные меры. Поэтому крайне важно, чтобы DNS-записи были настроены на проксирование через Cloudflare, IP адрес исходного сервера был скрыт, а на стороне хостинга были реализованы надёжные меры безопасности. Для выбора безопасной инфраструктуры рекомендуем ознакомиться с материалами Услуги безопасного веб-хостинга и Установка SSL сертификата.

Признаки DDoS-атаки: что проверить перед включением режима «Under Attack»?

Не всякое замедление сайта связано с DDoS. Иногда виноваты сбои в плагинах, блокировки базы данных, ресурсоёмкие задачи cron или неправильные настройки кеша. Поэтому перед активацией режима полезно провести быструю диагностику. Но если сервер не справляется, пользователи получают ошибки 502, 503 или 504, а в логах наблюдается всплеск аномальных запросов — включать «Under Attack» нужно без промедления.

Типичные признаки DDoS-атаки

  • Резкий рост трафика в 5, 10 или 50 раз за короткое время.
  • Сотни запросов в секунду на одну страницу или API endpoint.
  • Трафик с разных стран с похожими User-Agent.
  • Атаки на ресурсоёмкие URL, например страницы администрирования, входа, поиска, корзины в WordPress, WooCommerce, OpenCart или кастомных решениях.
  • Перегрузка CPU, RAM, PHP-FPM воркеров или лимитов MySQL на сервере.
  • В Cloudflare Analytics резкий рост 4xx и 5xx ошибок.
  • Реальные пользователи заходят с перебоями, а боты постоянно шлют запросы.

Например, если обычный e-commerce сайт с 2000 запросами в минуту внезапно получает 80 000 запросов в минуту, из которых 70% приходится на корзину или поиск — это явный Layer 7 DDoS. В такой ситуации режим «Under Attack» включают в первые 5 минут, затем добавляют специальные WAF-правила и ограничение скорости запросов.

Когда стоит использовать режим «Under Attack»?

Режим «Under Attack» не предназначен для постоянной работы, так как он показывает посетителям дополнительный экран с проверкой, что может ухудшить пользовательский опыт, особенно на конверсионных страницах, в платежных шагах и API. Его разумно включать только временно — во время атаки, а после восстановления трафика возвращать настройки в более сбалансированный режим.

Подходящие ситуации для включения

  • Если на сайт идёт аномально высокий поток HTTP/HTTPS запросов.
  • Если серверные ресурсы быстро исчерпываются и растёт количество ошибок 502/503.
  • Если WAF ещё не настроен под конкретные сценарии и нужна быстрая защита.
  • Если бот-трафика заметно больше, чем реальных пользователей.
  • Если атакуются веб-страницы, формы входа, поисковые запросы или другие уязвимые эндпоинты.

Когда стоит пользоваться осторожно

  • Если активно используется мобильное приложение, платёжные шлюзы, webhook или API.
  • Если идёт критический период для индексации сайта поисковыми ботами.
  • Если корпоративные пользователи заходят с устаревших браузеров или ограниченных сетей.
  • Если на сайте есть поддомены, не проксируемые через Cloudflare.

Для сайтов с API режим «Under Attack» применяется ко всему домену, что может нарушить работу интеграций. Рекомендуется для API использовать отдельные WAF-правила, allowlist или иной уровень защиты. Подробности по безопасности API — в Руководство по безопасности API и ограничению частоты.

Как включить режим «Under Attack» в Cloudflare: пошаговая инструкция

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

1. Войдите в аккаунт Cloudflare

Зайдите в свой аккаунт Cloudflare и выберите домен, подвергающийся атаке. Если управляете несколькими сайтами, убедитесь, что работаете с нужным. Ошибочный выбор приведёт к потере времени и продолжению атаки.

2. Проверьте, что DNS-записи проксируются

Для работы режима «Under Attack» трафик должен проходить через Cloudflare. В разделе DNS убедитесь, что записи A, AAAA и CNAME имеют оранжевое облачко (proxied). Записи с серым облаком (DNS only) не защищены Cloudflare. Особое внимание уделите www, корневому и используемым поддоменам.

Если IP исходного сервера виден в интернете, злоумышленники могут обходить Cloudflare и атаковать напрямую. Рекомендуется на сервере разрешать HTTP/HTTPS трафик только с IP-адресов Cloudflare. За помощью обратитесь к хостинг-провайдеру или воспользуйтесь руководством Как настроить DNS Cloudflare.

3. Включите режим «Under Attack» в разделе Security

В панели Cloudflare выберите нужный домен, откройте раздел Security или Overview и найдите опцию «Under Attack Mode». При активации Cloudflare начнёт показывать посетителям страницу проверки безопасности. В некоторых интерфейсах этот режим называется «I am Under Attack» и находится под Security Level.

Изменения вступают в силу быстро. В первые минуты следите за метриками в Cloudflare Analytics, Security Events и нагрузкой на сервер. Если CPU и количество соединений снижаются, режим работает эффективно. Если количество ошибок остаётся высоким — добавьте дополнительные правила.

4. Проверьте работу сайта с точки зрения пользователей

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

5. Определите целевые URL атаки

Режим «Under Attack» — это общий фильтр, но максимальный эффект дают таргетированные правила. Посмотрите в Cloudflare Security Events, веб-аналитику, логи хостинга и приложения, чтобы выявить URL с максимальным количеством запросов, например /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, /checkout.

Для таких URL создайте кастомные правила WAF, учитывая страну, user-agent, метод запроса, путь URI или уровень подозрительности бота. Например, для страницы входа можно выставить managed challenge для IP, превышающих определённый лимит запросов. Для WordPress рекомендована статья Меры безопасности WordPress.

Чем режим «Under Attack» отличается от других средств защиты Cloudflare?

Инструменты безопасности Cloudflare имеют разные задачи. «Under Attack» — это быстрый и общий фильтр на случай экстренной атаки. WAF и rate limiting — более точечные, долговременные решения с меньшим влиянием на пользователей.

Чем режим «Under Attack» отличается от других средств защиты Cloudflare?
ФункцияНазначениеКогда использоватьВлияние на пользователя
Режим «Under Attack»Показывает всем посетителям проверку, снижает бот-трафик.Во время активной DDoS или интенсивного HTTP-флуда.Посетители видят короткую проверку перед доступом.
Кастомные правила WAFСоздают правила для конкретных URL, стран, IP, методов или user-agent.Если известна схема атаки и нужно точечное блокирование.При правильной настройке минимальное влияние.
Rate LimitingОграничивает количество запросов от клиента за период.Для защищаемых страниц входа, поиска, API, корзины.Неправильные пороги могут ограничить реальных пользователей.
Bot Fight ModeУменьшает простой бот-трафик.При постоянном низком или среднем уровне ботов.Как правило, минимальное влияние.
Правила кешированияОбслуживает статический и кэшируемый динамический контент с CDN.Для постоянного снижения нагрузки на сервер.При правильной настройке — положительный эффект.

Практически эффективная стратегия: сначала быстро снизить нагрузку режимом «Under Attack», затем проанализировать атаку, добавить WAF и rate limiting, а в конце усилить кеширование и настройки firewall на сервере.

Рекомендуемые дополнительные настройки Cloudflare во время атаки

Хотя режим «Under Attack» включается одной кнопкой, успех защиты зависит от дополнительных настроек. Ниже — самые часто применяемые рекомендации.

Настройте таргетированные правила WAF

Cloudflare WAF позволяет задавать действия по заданным условиям. Например, можно применять challenge только к POST-запросам к /wp-login.php из определённых стран, не замедляя весь сайт.

  • Ограничьте доступ к админским и страницам входа по странам или IP.
  • Блокируйте неиспользуемые эндпоинты, например XML-RPC.
  • Для подозрительных user-agent применяйте managed challenge.
  • Ограничьте частоту запросов к критичным URI с помощью rate limiting.

Правильно настройте кеширование

Если каждый запрос идёт на origin-сервер, ресурсы быстро исчерпываются. Статические файлы — изображения, CSS, JS и кешируемые страницы — должны обслуживаться с CDN. Для динамических сайтов, например WordPress, полезно использовать кеш-плагины, правила кеша Cloudflare и заголовки cache-control.

Для сайтов с новостями или блогами страницы для неавторизованных посетителей можно кешировать 5–30 минут. Это снижает время отклика и нагрузку даже вне атаки. Для оптимизации производительности рекомендуем Руководство по ускорению веб-сайта.

Задайте реалистичные лимиты rate limiting

Ограничение скорости запросов эффективно для дорогих по ресурсам страниц. Но слишком жёсткие лимиты могут помешать настоящим пользователям. Например, на странице поиска нормально до 5–15 запросов в минуту, а 100 — аномалия. На странице входа 10 неудачных попыток за 5 минут — повод для блокировки.

Пример: для /wp-login.php — более 10 запросов в минуту вызывает managed challenge, более 50 за 5 минут — временная блокировка. Для API лучше применять более тонкие ограничения с учётом сессий, IP, токенов и методов.

Скрывайте IP origin-сервера и ограничивайте доступ через firewall

Одна из распространённых ошибок — оставлять IP сервера открытым. Старые DNS-записи, поддомены с прямым доступом, почтовые сервисы, незащищённые конфигурации позволяют атакующим обходить Cloudflare.

Настройте сервер так, чтобы порты 80 и 443 принимали трафик только с IP Cloudflare. Не открывайте SSH, панели управления, базы данных в интернет — используйте IP-фильтры, сложные пароли, двухфакторную аутентификацию и VPN. Для безопасности хостинга полезны материалы Настройки безопасности cPanel и Настройка фаервола VPS.

Особые рекомендации для WordPress, WooCommerce и корпоративных сайтов

Разные типы сайтов имеют разные особенности и уязвимости. Режим «Under Attack» надо настраивать с учётом специфики проекта.

WordPress-сайты

Чаще всего под атаками оказываются /wp-login.php и /xmlrpc.php. Если XML-RPC не используется — его безопасно блокировать. Админ-панель можно ограничить по странам или IP. Следите, чтобы правила Cloudflare не конфликтовали с плагинами безопасности, чтобы не создавать бесконечных циклов проверки для пользователей.

WooCommerce-магазины

Особое внимание уделите страницам корзины, оплаты и аккаунта — они динамические и не должны кэшироваться агрессивно. При включённом режиме «Under Attack» убедитесь, что callback’и платёжных систем и webhook’и работают корректно. IP платёжных провайдеров желательно внести в allowlist или создать для них отдельные правила.

Корпоративные проекты и сайты с API

Корпоративные порталы, CRM и мобильные приложения могут не справляться с JavaScript challenge. В таких случаях для основного сайта включайте «Under Attack», а для API — отдельные настройки безопасности с токенами, rate limiting и allowlist. Например, www.example.com может быть под защитой, а api.example.com — с особым режимом.

Какие метрики нужно отслеживать после включения режима «Under Attack»?

Какие метрики нужно отслеживать после включения режима «Under Attack»?

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

  • Cloudflare Security Events: сколько запросов было заблокировано или проверено.
  • HTTP-коды ответов: динамика ошибок 403, 429, 502, 503, 504.
  • Использование CPU и RAM на сервере: должны снижаться после включения режима.
  • Количество PHP-FPM воркеров и соединений MySQL: отражает нагрузку на приложение.
  • Трафик и количество запросов: соотношение общего и пропущенного трафика.
  • Конверсии реальных пользователей: отправка форм, заказы, входы, платежи.

Например, если общее число запросов не уменьшилось, но на сервер доходит на 60% меньше запросов, значит Cloudflare эффективно фильтрует нежелательный трафик. Если при этом CPU MySQL остаётся загруженным, возможно, атакуется конкретный тяжелый запрос — стоит проанализировать логи приложения.

Как корректно выключить режим «Under Attack» после атаки?

После нормализации трафика не рекомендуется оставлять режим «Under Attack» постоянно включённым — это ухудшает конверсию, поисковую индексацию и пользовательский опыт. Выключение должно быть плавным и контролируемым.

Шаги для безопасного возврата к обычному режиму

  • Подождите как минимум 30–60 минут, пока трафик стабилизируется.
  • Убедитесь, что в Cloudflare Security Events количество блокировок и проверок снижается.
  • Перед отключением проверьте, что WAF-правила и rate limiting настроены и активны.
  • Переведите уровень безопасности на High или Medium — более сбалансированные режимы.
  • Проверьте сайт с разных устройств, следите за ошибками 5xx.
  • В течение суток мониторьте логи, чтобы не пропустить повторную атаку.

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

Распространённые ошибки и чего следует избегать

Во время DDoS-атаки важно принимать решения быстро, но не ошибаться, чтобы не блокировать реальных пользователей.

  • Ожидать защиты от режима «Under Attack» без проксирования DNS-записей.
  • Оставлять открытым IP сервера и не ограничивать доступ по firewall.
  • Применять проверку на весь домен без тестирования API, webhook и callback’ов платёжных систем.
  • Создавать слишком жёсткие WAF-правила, блокирующие клиентов.
  • Кешировать динамические страницы корзины, оплаты и личного кабинета.
  • Оставлять «Under Attack» включённым неделями после атаки.
  • Принимать решения, опираясь только на панель Cloudflare, без анализа серверных логов.

В e-commerce особенно важно не блокировать callback'и платёжных систем — это может привести к серьёзным финансовым потерям. Всегда сначала тестируйте правила в лог-режиме или с managed challenge, а уж потом переходите к жёсткой блокировке.

Как на платформе Hostragons построить более устойчивую защиту?

Cloudflare — мощный фронтальный щит, но полноценная защита от DDoS достигается комплексным подходом. Хостинг, оптимизация кода, SSL-конфигурация, управление DNS и стратегии резервного копирования должны работать в едином тандеме. В идеале: Cloudflare фильтрует трафик, хостинг принимает только чистый, а приложение оптимизировано, чтобы не создавать лишнюю нагрузку на базу данных.

Перед запуском проекта важно правильно настроить DNS, корректно установить SSL и выбрать серверные ресурсы под профиль трафика. Для помощи рекомендуем Проверка домена и регистрация имени, Пакеты веб-хостинга, решения для корпоративного хостинга и Бесплатный SSL сертификат.

Для проектов с высоким трафиком или риском атак стоит рассмотреть VPS или управляемые серверы вместо стандартного шаред-хостинга. Это даст гибкость в настройках firewall, веб-сервера, PHP-FPM, Redis, кешей и баз данных. Но в любом случае режим «Under Attack» — лишь аварийный инструмент, а долгосрочная безопасность строится на WAF, анализе логов и регулярных обновлениях.

Чек-лист на первые 15 минут при DDoS-атаке

В критической ситуации важна скорость. Вот что нужно сделать в первые 15 минут:

  • Зайти в панель Cloudflare и выбрать правильный домен.
  • Проверить, что DNS-записи проксируются (оранжевое облако).
  • Включить режим «Under Attack».
  • Протестировать главную, страницы входа, корзины, оплаты и API.
  • Определить целевые URL по безопасности и аналитике.
  • Добавить WAF или rate limiting для самых атакуемых страниц.
  • Проверить нагрузку CPU, RAM, PHP-FPM и MySQL.
  • Проверить, доступен ли origin IP напрямую.
  • Проверить allowlist для платёжных провайдеров, webhook’ов и интеграций.
  • Задокументировать все действия с указанием времени.

Регулярно отрабатывая этот чек-лист, команда снизит панику и повысит качество реагирования. Для больших проектов рекомендуется оформить план реагирования на инциденты.

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

Защищает ли режим «Under Attack» сайт полностью?

Нет. Он эффективно снижает бот-трафик и HTTP/HTTPS флуд, но не заменяет комплексной защиты. Важно использовать его вместе с проксированием DNS, скрытием IP origin, WAF, rate limiting, кешем и firewall на сервере.

Вредит ли режим SEO?

Кратковременное использование обычно не наносит серьёзного вреда SEO. Если режим включён долго, это может ухудшить индексацию и пользовательский опыт. Поэтому после атаки лучше выключать «Under Attack» и продолжать с таргетированными правилами.

Как долго держать режим «Under Attack» включённым?

Пока атака продолжается. После нормализации трафика рекомендуется наблюдать 30–60 минут и постепенно выключать. Перед этим должны быть настроены постоянные правила WAF и rate limiting.

Влияет ли режим на работу API и платёжных систем?

Да, иногда. Некоторые API-клиенты, webhook’и и callback’и платёжных систем не проходят браузерную проверку. Их нужно тестировать и при необходимости создавать исключения (allowlist) или специальные правила.

Нужно ли дополнительно защищать сервер при использовании Cloudflare?

Да. Cloudflare даёт мощную фронтальную защиту, но IP origin должен быть скрыт, firewall настроен на приём трафика только с Cloudflare, софт должен обновляться, а кеширование — работать корректно. Безопасный хостинг — ключевой элемент защиты от DDoS.

Выводы

Режим «Under Attack» Cloudflare — эффективный инструмент экстренной помощи при DDoS-атаках. При правильной настройке прокси DNS он снижает бот-трафик, снижает нагрузку на сервер и повышает шансы реальных пользователей попасть на сайт. Для максимальной защиты режим нужно дополнять правилами WAF, ограничением скорости запросов, оптимизацией кеша и firewall на сервере.

Чтобы сайт был устойчив к атакам, регулярно проверяйте инфраструктуру, настройки DNS и SSL. Изучите предложения Hostragons по хостингу, регистрации доменов и SSL, чтобы создать надёжную и долговременную защиту.

Поделитесь этой статьей:

Команда Hostragons

Актуальные руководства от нашей команды экспертов по хостингу, серверам и доменным именам. Давайте вместе найдем оптимальное решение для вашего проекта.

Свяжитесь с нами