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 — незалежно від того, як сформульовані загальніші правила.