Firewall правила Cloudflare: блокировка IP и стран

Cloudflare WAF Custom Rules позволяет создавать точные правила фильтрации трафика. Правила выполняются на уровне сети Cloudflare — вредоносные запросы блокируются до сервера.

Создание правила: Security → WAF → Custom Rules → Create

Заблокировать страну

Condition: ip.geoip.country eq "RU"
Action: Block

Защита /wp-login.php

Condition:
  (http.request.uri.path eq "/wp-login.php") 
  AND NOT (ip.src in {123.45.67.0/24})
Action: Managed Challenge (CAPTCHA)

Заблокировать плохие боты

Condition: cf.client.bot
Action: Block

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

Condition: 
  NOT (ip.geoip.country in {"UA" "RU" "BY"})
  AND http.request.uri.path starts with "/admin"
Action: Block

Блокировка конкретного IP

Security → WAF → Tools → IP Access Rules → Add.

IP или диапазон (1.2.3.4 или 1.2.3.0/24) → Action: Block.

Bot Fight Mode

Security → Bots → Bot Fight Mode → On. Автоматически блокирует известных вредоносных ботов без создания ручных правил.

Логи Firewall

Security → Events — полный лог всех заблокированных и проверенных запросов с причиной блокировки, IP, страной и типом запроса.

Действия (Actions) в Custom Rules

Перед включением Block на новом правиле стоит сначала поставить Log и понаблюдать за Security → Events несколько часов — так видно, не попадают ли под правило легитимные запросы.

Типичные ошибки при настройке правил

Правило заблокировало администратора

Часто происходит с правилами по стране или диапазону IP, когда админ подключается из другой страны или через VPN. Добавьте в условие правила исключение через AND NOT (ip.src in {ВАШ_IP}) или создайте отдельное IP Access Rule с действием Allow — оно имеет более высокий приоритет.

Правило создано, но не срабатывает

Проверьте порядок условий: AND означает, что должны выполниться оба условия одновременно, а не любое из них. Часто путают с OR и получают правило, которое не совпадает ни с одним реальным запросом. Также проверьте, что правило включено (переключатель Enabled), а не сохранено в статусе черновика.

Проверка результата

# Проверить что правило блокирует нужный запрос
curl -I -A "BadBot/1.0" https://example.com/wp-login.php

HTTP/2 403
cf-mitigated: challenge

Если ожидаемого статуса нет — откройте Security → Events и найдите запрос по времени: там видно, какое именно правило (или его отсутствие) обработало этот запрос.

Когда Custom Rules не подходят

• Нужна защита от атак на уровне приложения, которые не выражаются простым условием (например, аномалии в бизнес-логике) — тут нужен полноценный WAF Managed Ruleset или анализ на стороне приложения.
• Нужно менять поведение в реальном времени по сложной логике — для этого больше подходит Worker, который может выполнять произвольный код.
• Лимит правил на тарифе исчерпан, а объединять условия через OR уже некуда — часть логики стоит перенести в Rate Limiting Rules или Bot Management, у которых отдельные лимиты.

Условия правил строятся на полях вроде http.request.uri.path, ip.geoip.country, http.user_agent — полный список доступных полей открывается прямо в конструкторе правила при выборе поля из выпадающего списка, не нужно запоминать синтаксис наизусть.

IP Access Rules можно создавать на трёх уровнях: для одного сайта (Zone), сразу для всех доменов аккаунта (Account), или персонально для своей учётной записи (User). Правило на уровне Account удобно для блокировки одного и того же вредоносного IP сразу на всех проектах без дублирования.

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

Поле Description у правила не влияет на логику фильтрации, но экономит время при аудите списка из десятка правил спустя полгода, когда уже не помнишь, зачем создавалось конкретное правило.

Правила из Custom Rules и IP Access Rules применяются раньше, чем запрос доходит до кэша или до кода приложения — заблокированный запрос никогда не попадёт ни в логи сервера, ни в аналитику посещений вашего сайта, только в Security → Events самого Cloudflare.

Частые вопросы

Что произойдёт, если на один и тот же запрос одновременно подходят и Custom Rule, и Bot Fight Mode?

Правила Cloudflare применяются в определённом порядке приоритета, и обычно более специфичные механизмы защиты, включая IP Access Rules и некоторые системные проверки, срабатывают раньше общих Custom Rules и Bot Fight Mode. На практике это означает, что запрос останавливается на первом сработавшем правиле, а остальные механизмы просто не доходят до его обработки.

Можно ли временно отключить правило без удаления, если оно начало мешать части посетителей?

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

Видно ли заблокированные Custom Rules запросы в логах собственного сервера?

Нет, запрос, остановленный на уровне Cloudflare, никогда не достигает самого сервера, поэтому он не появится ни в логах веб-сервера, ни в собственной аналитике посещений сайта. Единственное место, где виден такой запрос, — раздел Security → Events в панели Cloudflare, и именно туда нужно смотреть при расследовании подобных блокировок.

Если IP Access Rule разрешает адрес, а Custom Rule его блокирует — какое правило победит?

IP Access Rules выполняются раньше Custom Rules и имеют более высокий приоритет, поэтому разрешающее правило на уровне IP Access Rules победит блокирующее условие в Custom Rules для того же адреса. Это и делает их удобным инструментом для точечных исключений — например, для своего рабочего IP — независимо от того, как сформулированы более общие правила.