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

Web Application Firewall (WAF)

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

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

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

Обзор

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

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

Содержимое правил в управляемых наборах правил Cloudflare поддерживается компанией 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, приведён в справочнике по фазам, на который есть ссылка ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как отслеживается ложное срабатывание? Скопируйте Ray ID из затронутого ответа, найдите событие в Security Events и определите по записи ID ruleset и правила. Ограничьте исключение этим 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.

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