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

Web Application Firewall (WAF)

Cloudflare WAF проверяет проксируемые HTTP-запросы по пользовательским правилам, правилам ограничения скорости и управляемым наборам правил Cloudflare, прежде чем передать их на origin-сервер. На этой странице описаны модель оценки, объекты конфигурации, задокументированные лимиты, доступность по тарифным планам и порядок развёртывания.

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

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

Обзор

Веб-межсетевой экран проверяет HTTP-запросы до того, как их обработает приложение, и применяет правила, которые разрешают, регистрируют, проверяют, перенаправляют или блокируют запрос. Это механизм фильтрации, который действует наряду с установкой исправлений, а не вместо неё: он снижает подверженность известным классам эксплойтов и автоматизированному сканированию в период между раскрытием уязвимости и выпуском исправления.

Cloudflare WAF выполняет проверку в дата-центрах Cloudflare, которые проксируют трафик для зоны. По данным Cloudflare, её сеть работает в 348 городах (https://www.cloudflare.com/network/, дата обращения 2026-08-28). Проверяется только трафик, проксируемый через Cloudflare. Запросы к записям DNS only и к именам хостов, которые разрешаются вне зоны, а также прямые подключения к IP-адресу origin-сервера проходят в обход WAF.

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

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

Архитектура

TLS-соединение для запроса к проксируемому имени хоста завершается в дата-центре Cloudflare, выбранном anycast-маршрутизацией. Затем запрос проходит через движок наборов правил (ruleset engine), который выполняет правила, сгруппированные в упорядоченные фазы. Фазы, связанные с безопасностью, выполняются в следующем порядке:

1. Нормализация URL и очистка запросов.
2. http_request_firewall_custom: пользовательские правила зоны и аккаунта.
3. http_ratelimit: правила ограничения скорости.
4. http_request_firewall_managed: Cloudflare Managed Ruleset, Cloudflare OWASP Core Ruleset и другие управляемые наборы правил, развёрнутые в зоне.

Внутри фазы правила проверяются в заданном порядке. Терминирующее действие останавливает проверку остальных правил для этого запроса, нетерминирующее позволяет её продолжить. Полный список фаз, включая фазы transform, redirect и cache, приведён в справочнике по фазам, на который есть ссылка ниже.

Механизмы обнаружения (detections) работают отдельно от правил. Attack score, обнаружение утекших учётных данных, сканирование вредоносных загрузок и обнаружение чувствительных данных вычисляют значения в процессе обработки запроса и предоставляют их в виде полей. Сами по себе они не блокируют трафик: правило должно ссылаться на поле и указывать действие. Поэтому включённое обнаружение не влияет на трафик, пока его не использует какое-либо правило.

Cloudflare Managed Ruleset применяет сигнатурные и эвристические методы обнаружения, которые ведёт Cloudflare. OWASP Core Ruleset работает иначе: он оценивает запрос по типовым паттернам атак, накапливает балл и срабатывает, когда балл превышает заданный порог при заданном уровне паранойи. Эти два набора правил настраиваются независимо друг от друга.

Возможности

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

Конфигурация WAF состоит из наборов правил, развёрнутых по фазам. У правила есть выражение, действие, порядок и необязательные параметры действия. Выражения записываются на языке Cloudflare Rules для типизированных полей, таких как http.request.uri.path, http.request.headers, ip.src.country, ip.src.asnum, cf.bot_management.score и cf.waf.score. Доступность полей различается в зависимости от тарифного плана: поля bot score и attack score требуют соответствующих прав доступа.

В фазах firewall доступны действия Block, Managed Challenge, Interactive Challenge, JS Challenge, Redirect, Serve Error, Skip, Execute и Log. Поведение управляемого набора правил меняют не редактированием правил поставщика, а с помощью переопределений: переопределение на уровне набора правил меняет действие или статус для всего набора, переопределение на уровне тега меняет группу правил, а переопределение на уровне правила меняет одно правило. Исключения, выраженные как правила пропуска, убирают определённый трафик из проверки управляемым набором правил, не отключая правила целиком.

Для OWASP Core Ruleset поведение определяется двумя параметрами: уровнем паранойи, который задаёт, сколько правил участвует в подсчёте баллов, и пороговым значением баллов, при котором набор правил начинает действовать. Повышение уровня паранойи увеличивает как уровень обнаружения, так и долю ложных срабатываний.

Конфигурацией можно управлять через панель управления, Rulesets API и Cloudflare Terraform provider. Порядок правил и порядок развёртывания наборов правил входят в конфигурацию; если правила управляются как код, их нужно хранить в системе контроля версий.

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

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

На Pro доступны те же характеристики подсчёта, что и на Free. Для правила ограничения скорости, которое считает запросы не только по IP-адресу клиента, нужен план Business или Enterprise. Из-за этого правило, созданное на одном плане, часто не удаётся развернуть на другом.

Дополнительные ограничения, которые применяются независимо от тарифного плана:

• Проверяется только проксируемый трафик. Записи DNS-only, прямые подключения к IP-адресу origin-сервера и протоколы, отличные от HTTP, находятся вне пути обработки данных WAF.
• Проверка тела запроса ограничена максимальным проверяемым размером тела; содержимое за этой границей не анализируется. Актуальное значение уточняйте в исходной документации.
• Содержимое управляемых правил контролируется поставщиком. Отдельные управляемые правила можно отключить или переопределить, но не переписать.
• Механизмы обнаружения сами по себе ничего не блокируют. Включённые attack score, обнаружение утекших учётных данных или сканирование загрузок не влияют на трафик, пока на соответствующее поле не сошлётся какое-либо правило.
• Выборка и срок хранения данных аналитики зависят от тарифного плана, что влияет на объём данных, доступных для настройки на младших планах.

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

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

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

• Составьте перечень приложений, фреймворков, открытых конечных точек и путей API, обслуживаемых зоной, включая административные интерфейсы и конечные точки взаимодействия между машинами.
• Запишите, какие имена хостов проксируются, а какие работают в режиме DNS-only.
• Определите интеграции, которые нельзя подвергать проверке или блокировать: системы мониторинга, платёжные обратные вызовы, партнёрские системы, CI-конвейеры и мобильные клиенты.
• Уточните тарифный план зоны: от него зависят действие Log и поддержка регулярных выражений.
• Подготовьте путь отката: экспортируйте текущую конфигурацию набора правил через API или Terraform и сохраните её.

Поэтапная проверка. Выберите один из следующих вариантов в зависимости от прав доступа:

1. На плане Enterprise разверните управляемые наборы правил с переопределением на уровне набора правил, задав действие Log. Собирайте совпадения в Security Events в течение заданного периода наблюдения, охватывающего как минимум один полный бизнес-цикл.
2. На планах Free, Pro или Business, где Log недоступен, используйте непроизводственную зону или выделенный хост, который получает репрезентативный трафик, либо ограничьте применение выражением, которое сужает управляемые наборы правил до небольшого среза трафика, например до одного префикса пути или тестового cookie. Просмотрите Security Events для этого среза, а затем постепенно расширяйте выражение.

Настройка. Применяйте изменения в следующем порядке:

1. Разверните Cloudflare Managed Ruleset в режиме блокировки с исключениями, выявленными в ходе проверки.
2. Разверните OWASP Core Ruleset с низким уровнем паранойи и мягким пороговым значением оценки. Ужесточайте его постепенно, оценивая результаты после каждого шага.
3. Добавляйте пользовательские правила для путей, специфичных для конкретного приложения: административных интерфейсов, конечных точек аутентификации, обработчиков загрузки файлов и внутренних API.
4. Добавляйте правила ограничения скорости для конечных точек аутентификации, сброса пароля, оформления заказа и других ресурсоёмких конечных точек API. Пороговые значения определяйте по наблюдаемому трафику, а не берите значения по умолчанию.
5. Ограничивайте область действия исключений настолько узко, насколько это позволяет язык выражений. Исключение по пути, методу и ID правила лучше, чем отключение правила для всей зоны.

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

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

• Синтетические транзакции для основных пользовательских сценариев выполняются без проверки или блокировки.
• Интеграции, зафиксированные на этапе подготовки, продолжают работать успешно, что подтверждается их собственными логами, а не только аналитикой Cloudflare.
• Security Events показывает заблокированный трафик, соответствующий ожидаемым классам эксплойтов, без скопления блокировок на легитимных путях.
• Счётчики ограничения скорости срабатывают на заданных пороговых значениях при нормальной нагрузке.

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

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

Настраивайте защиту по фактическим данным. У каждого заблокированного запроса есть Ray ID, а соответствующая запись в Security Events указывает набор правил, ID правила и совпавшее поле. Служба поддержки должна запрашивать у пользователя Ray ID: это единственный надёжный способ найти, какое правило сработало.

Выборка и срок хранения данных аналитики зависят от тарифного плана. На младших планах ложное срабатывание, не расследованное своевременно, может стать недоступным для просмотра. Если доступен Enterprise Logpush, направляйте события файрвола в SIEM и храните их согласно собственной политике, а не полагайтесь на срок хранения в дашборде.

Содержимое управляемых правил изменяется по расписанию Cloudflare. Новые правила могут начать срабатывать на трафик, который раньше проходил без блокировки. Настройте оповещения по объёму Security Events, чтобы замечать изменения в частоте совпадений, и проверяйте новые управляемые правила после того, как они будут анонсированы в Changelog Cloudflare.

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

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

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

• Развёртывание только в режиме журналирования недоступно ниже уровня Enterprise. Процедуры, скопированные из документации для Enterprise, не будут применимы на планах Free, Pro или Business.
• WAF защищает только трафик, который идёт через Cloudflare. Если IP-адрес origin-сервера доступен из интернета, злоумышленник, узнавший его, обходит WAF полностью. Разрешите на файрволе origin-сервера только диапазоны IP-адресов Cloudflare (https://www.cloudflare.com/ips/), включите Authenticated Origin Pulls или подключите origin-сервер через Cloudflare Tunnel.
• OWASP Core Ruleset и Cloudflare Managed Ruleset ведут себя по-разному. Если повысить уровень паранойи OWASP, не снизив порог (или наоборот), результаты при настройке легко истолковать неправильно.
• Отключение управляемого правила для всей зоны часто используют как быстрое решение для одной конечной точки. Но это снимает защиту со всего трафика. Вместо этого используйте точечное исключение.
• Регулярные выражения недоступны на тарифах Free и Pro, поэтому правило, написанное для зоны на плане Business, может не развернуться в зоне на плане Pro.
• Запросы, обслуживаемые из кеша, и запросы к хостам с записью DNS-only проходят по другому пути обработки; не делайте вывод о полноте покрытия на основании одного успешного теста.
• Если у аккаунта нет прав на поля attack score и bot score, правило, которое на них ссылается, будет работать не так, как ожидается. После смены тарифного плана поведение правила может незаметно измениться.

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

WAF использует общий движок наборов правил (Ruleset Engine) и язык Rules вместе с правилами ограничения скорости, правилами преобразования, правилами перенаправления, правилами кеширования и правилами конфигурации. Поэтому правила в разных фазах могут ссылаться на одни и те же поля, а порядок фаз определяет, какое из них выполняется первым.

Bot Management предоставляет cf.bot_management.score и связанные поля, на которые могут ссылаться пользовательские правила WAF: это штатный способ объединить классификацию ботов с фильтрацией эксплойтов в одном решении.

Turnstile может выдавать pre-clearance для сессии, чтобы посетитель, уже прошедший проверку в виджете, не получал повторную проверку от правил WAF в проксируемой зоне.

Workers запускаются уже после фаз безопасности в конвейере обработки запросов Cloudflare, поэтому запрос, заблокированный WAF, до Worker вообще не доходит. Если кажется, что Worker и правило WAF конфликтуют, сверьтесь с документированной последовательностью обработки трафика.

API Shield добавляет проверку схемы, принудительную проверку клиентских сертификатов mTLS и обнаружение конечных точек для API-трафика, а также сочетается с правилами WAF на тех же именах хостов.

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

Проверяет ли WAF тела запросов? Да, до документированного максимального проверяемого размера, при этом доступные для проверки тела запроса поля зависят от тарифа и типа содержимого. Содержимое, превышающее проверяемый размер, пересылается без проверки тела запроса.

Применяются ли правила WAF к трафику API? Да. Правила применяются к любому проксируемому HTTP-запросу, включая JSON API и конечные точки взаимодействия между машинами. Небраузерный клиент не может пройти проверку (challenge), поэтому для путей API используйте Block или ограничение скорости, а не проверку.

Как найти причину ложного срабатывания? Скопируйте Ray ID из затронутого ответа, найдите событие в Security Events и определите по записи ID набора правил и правила. Ограничьте исключение этим ID правила, путём и методом.

Источники

• https://developers.cloudflare.com/waf/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/waf/custom-rules/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/waf/rate-limiting-rules/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/waf/managed-rules/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/waf/detections/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/rules-language/actions/, дата обращения 2026-08-28.
• https://developers.cloudflare.com/ruleset-engine/reference/phases-list/, дата обращения 2026-08-28.
• https://www.cloudflare.com/network/, дата обращения 2026-08-28.
• https://www.cloudflare.com/ips/, дата обращения 2026-08-28.

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

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