← Документация WAF / reference / legacy

Обновление правил брандмауэра

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

• Старая панель управления: Безопасность > WAF > Custom rules.
• Новая панель управления безопасности: Безопасность > Правила безопасности.

Основные различия между правилами брандмауэра и пользовательскими правилами WAF заключаются в следующем:

• Улучшенный ответ для действия Block
• Другая страница ошибки для заблокированных запросов
• Новое действие Skip, заменяющее действия Allow и Bypass
• Пользовательские правила оцениваются по порядку
• Логи и события
• Новые ресурсы API и Terraform

В пользовательских правилах WAF можно настроить ответ для Block действие.

Ответ блокировки по умолчанию представляет собой стандартную HTML-страницу Cloudflare. Если вам нужно отправить пользовательский ответ для Block действия, настройте пользовательское правило так, чтобы оно возвращало фиксированный ответ с пользовательским кодом ответа (по умолчанию 403) и пользовательским телом (HTML, JSON, XML или обычный текст).

Запросы, заблокированные правилом брандмауэра с Block действие получило бы Cloudflare код ошибки 1020 ответ. Пользователи Cloudflare могли настраивать эту страницу ошибки для зоны в Error Pages > ошибки класса 1000.

Запросы, заблокированные пользовательским правилом WAF, получат другой ответ: ответ блокировки WAF. Чтобы изменить стандартный ответ блокировки, можно либо:

• Задайте пользовательский ответ блокировки WAF для всей зоны в Error Pages ↗ > WAF block. Эта страница ошибки всегда будет иметь тип содержимого HTML.
• Определение пользовательского ответа для запросов, заблокированных конкретным пользовательским правилом WAF. Этот пользовательский ответ поддерживает и другие типы содержимого, помимо HTML.

Если вы настроили собственную страницу ошибки 1XXX в Error Pages для запросов, заблокированных правилами брандмауэра, вам нужно будет создать новую страницу ответа для заблокированных запросов одним из описанных выше способов.

Дополнительную информацию о функции Error Pages см. в Custom Errors.

Firewall Rules поддерживали Allow и Bypass действия, которые часто использовались вместе. Эти действия обычно применялись для обработки заведомо легитимных запросов, например запросов от доверенных IP-адресов.

Когда запрос вызвал Allow, все оставшиеся правила брандмауэра не оценивались, что фактически позволяло запросу перейти к следующему продукту безопасности. Bypass действие было разработано, чтобы указывать, какие продукты безопасности (такие как WAF managed rules, правила ограничения частоты запросов и User Agent Blocking) не должны запускаться для запроса, вызвавшего это действие.

Если бы вы хотели с помощью Firewall Rules полностью остановить выполнение всех продуктов безопасности для конкретного запроса, вам нужно было бы создать два правила:

• Одно правило с Bypass действие (выбор всех продуктов безопасности).
• Одно правило с Allow действие (чтобы прекратить выполнение остальных правил брандмауэра).

Требование иметь два правила для этого распространённого сценария больше не применяется к пользовательским правилам WAF. Теперь вам следует используйте Пропустить действие, который объединяет Allow и Bypass действия. Пропустить действие полностью заменяет Allow и Bypass действия, которые не поддерживаются в пользовательских правилах WAF.

С Пропустить действие, вы можете сделать следующее:

• Прекращает выполнение всех оставшихся пользовательских правил (эквивалентно Allow действие)
• Не запускайте другие продукты безопасности (что эквивалентно Bypass действие)
• Комбинация перечисленного выше.

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

Действия правил брандмауэра имели особый порядок приоритета при использовании упорядочивание по приоритету. В отличие от этого, у действий пользовательских правил такого порядка нет. Пользовательские правила всегда обрабатываются по порядку, и некоторые действия, например Block остановит оценку остальных правил.

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

• Правило брандмауэра №1: приоритет 2 / действие: Block
• Правило брандмауэра №2: приоритет 2 / действие: Allow

Запрос будет разрешён, так как Allow действие в Firewall Rules имело бы приоритет над Block действие.

Для сравнения: если создать два пользовательских правила, оба из которых совпадают со входящим запросом:

• Пользовательское правило #1, действие: Block
• Пользовательское правило #2, действие: Пропустить (настроено на пропуск всех оставшихся пользовательских правил)

Запрос будет заблокирован, так как пользовательские правила применяются по порядку и Block действие остановит оценку остальных правил.

События, зарегистрированные пользовательскими правилами, отображаются в Security Events с Custom Rules в качестве своего источника.

На странице Security Events могут по-прежнему отображаться события, созданные Firewall Rules, если выбранный период включает дни перехода на пользовательские правила. Аналогично, могут по-прежнему отображаться события с обоими Пропустить и Allow действия в одном и том же представлении в течение переходного периода.

Предпочтительным API для управления пользовательскими правилами WAF является Rulesets API. Rulesets API используется во всех недавних продуктах безопасности Cloudflare, чтобы обеспечить единообразный пользовательский опыт при работе с нашим API. Дополнительную информацию о переходе на Rulesets API см. в Важные изменения для пользователей API.

Firewall Rules API и Filters API больше не поддерживаются начиная с 2025-06-15. Теперь существует единый список правил как для firewall rules, так и для пользовательских правил WAF, и этот список содержит пользовательские правила WAF. Благодаря внутреннему процессу преобразования Firewall Rules API и Filters API возвращают firewall rules/filters, преобразованные из этих пользовательских правил WAF, вплоть до даты прекращения поддержки API.

Если вы используете Terraform, необходимо обновить конфигурацию, чтобы использовать cloudflare_ruleset ↗ ресурсы с http_request_firewall_custom фаза для управления пользовательскими правилами. Дополнительную информацию об обновлении конфигурации Terraform см. в разделе Важные изменения для пользователей Terraform.

Вкладка Firewall Rules в дашборде Cloudflare теперь устарела. Правила брандмауэра отображаются как пользовательские правила в Cloudflare dashboard.

Для пользователей, у которых есть доступ к обоим продуктам, Правила Firewall вкладка доступна только в старой панели управления в Безопасность > WAF.

Firewall Rules API и соответствующий Cloudflare Filters API теперь считаются устаревшими. Эти API больше не поддерживаются с 2025-06-15. Необходимо вручную обновить любую автоматизацию, основанную на Firewall Rules API или Cloudflare Filters API, перейдя на Rulesets API чтобы избежать проблем. Идентификаторы правил отличаются между правилами брандмауэра и пользовательскими правилами, что может повлиять на автоматизированные процессы, использующие конкретные ID правил.

До даты прекращения поддержки API Cloudflare автоматически преобразует ваш Firewall Rules API и Filters API вызовы в соответствующий Rulesets API вызовы. Преобразованные вызовы API между Firewall Rules API/Filters API и Rulesets API отображаются в журналах аудита как созданные Cloudflare, а не непосредственно пользователем, выполнившим запрос. Единый список правил будет действовать как для firewall rules, так и для WAF custom rules.

Некоторые новые функции пользовательских правил WAF, такие как пользовательские ответы для заблокированных запросов и Пропустить действие, не поддерживаются в Firewall Rules API. Чтобы воспользоваться этими возможностями, Cloudflare рекомендует использовать страницу пользовательских правил в панели управления Cloudflare или Rulesets API.

См. документацию WAF для примеры управления пользовательскими правилами WAF с помощью Rulesets API.

Следующие ресурсы Terraform от провайдера Cloudflare теперь устарели:

• cloudflare_firewall_rule ↗
• cloudflare_filter ↗

Эти ресурсы больше не поддерживаются с 2025-06-15. Если вы используете их для управления конфигурацией Firewall Rules, необходимо вручную обновить конфигурацию Terraform до cloudflare_ruleset ↗ ресурсы, чтобы избежать проблем.

Для правил брандмауэра и пользовательских правил WAF будет единый список правил.

Некоторые новые функции пользовательских правил WAF не поддерживаются в устаревших ресурсах Terraform. Чтобы воспользоваться этими функциями, Cloudflare рекомендует использовать cloudflare_ruleset ресурс.

См. документацию о Terraform для примеры настройки пользовательских правил WAF с помощью Terraform.

Вы можете использовать cf-terraforming ↗ для создания конфигурации Terraform для текущих пользовательских правил WAF (преобразованных Cloudflare из ваших правил брандмауэра). Затем импортируйте новые ресурсы в состояние Terraform.

Ниже приведены рекомендуемые шаги для замены конфигурации правил брандмауэра (и фильтров) в Terraform на новую конфигурацию набора правил.

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

   cf-terraforming generate --zone <ZONE_ID> --resource-type "cloudflare_ruleset"

   resource "cloudflare_ruleset" "terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31" {
     kind    = "zone"
     name    = "default"
     phase   = "http_request_firewall_custom"
     zone_id = "<ZONE_ID>"
     rules {
       [...]
     }
     [...]
   }
   [...]

2. Предыдущая команда может также возвращать конфигурации наборов правил для других продуктов Cloudflare, основанных на Ruleset Engine. Поскольку вы переносите правила брандмауэра в пользовательские правила, оставьте только ресурс Terraform для http_request_firewall_custom фаза и сохранить его в .tf файл конфигурации. Полное имя ресурса понадобится вам на следующем шаге.

3. Импортируйте cloudflare_ruleset ресурс, который вы ранее определили, в состояние Terraform с помощью terraform import команду. Например:

   terraform import cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31 zone/<ZONE_ID>/3c0b456bc2aa443089c5f40f45f51b31

   cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: Importing from ID "zone/<ZONE_ID>/3c0b456bc2aa443089c5f40f45f51b31"...
   cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: Import prepared!
     Prepared cloudflare_ruleset for import
   cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: Refreshing state... [id=3c0b456bc2aa443089c5f40f45f51b31]
   
   Import successful!
   
   The resources that were imported are shown above. These resources are now in
   your Terraform state and will henceforth be managed by Terraform.

4. Запустите terraform plan чтобы убедиться, что Terraform теперь проверяет состояние нового cloudflare_ruleset ресурс в дополнение к другим существующим ресурсам, уже управляемым Terraform. Например:

   terraform plan

   
   cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: Refreshing state... [id=3c0b456bc2aa443089c5f40f45f51b31]
   [...]
   cloudflare_filter.my_filter: Refreshing state... [id=14a2524fd75c419f8d273116815b6349]
   cloudflare_firewall_rule.my_firewall_rule: Refreshing state... [id=0580eb5d92e344ddb2374979f74c3ddf]
   [...]

5. Удалите из состояния Terraform все данные, связанные с правилами брандмауэра и фильтрами:

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

      terraform state list | grep -E '^cloudflare_(filter|firewall_rule)\.'

      cloudflare_filter.my_filter
      cloudflare_firewall_rule.my_firewall_rule

   2. Выполните terraform state rm ... команду в режиме dry-run, чтобы оценить последствия удаления этих ресурсов без внесения фактических изменений:

      terraform state rm -dry-run cloudflare_filter.my_filter cloudflare_firewall_rule.my_firewall_rule

      Would remove cloudflare_filter.my_filter
      Would remove cloudflare_firewall_rule.my_firewall_rule

   3. Если результат выглядит корректно, выполните ту же команду без -dry-run параметр, чтобы фактически удалить ресурсы из состояния Terraform:

      terraform state rm cloudflare_filter.my_filter cloudflare_firewall_rule.my_firewall_rule

      Removed cloudflare_filter.my_filter
      Removed cloudflare_firewall_rule.my_firewall_rule
      Successfully removed 2 resource instance(s).

6. После удаления ресурсов правил брандмауэра и фильтров из состояния Terraform удалите cloudflare_filter и cloudflare_firewall_rule ресурсы из .tf файлы конфигурации.

7. Запустите terraform plan чтобы убедиться, что удалённые вами из конфигурационных файлов ресурсы больше не отображаются. У вас не должно быть отложенных изменений.

   terraform plan

   cloudflare_ruleset.terraform_managed_resource_3c0b456bc2aa443089c5f40f45f51b31: Refreshing state... [id=3c0b456bc2aa443089c5f40f45f51b31]
   [...]
   
   No changes. Your infrastructure matches the configuration.
   
   Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Сведения об импорте ресурсов Cloudflare в Terraform и об использовании cf-terraforming см. следующие материалы:

• Импорт ресурсов Cloudflare
• cf-terraforming репозиторий GitHub ↗

Любые неприостановленные правила файрвола с приостановленным фильтры будет включено при преобразовании в пользовательские правила.