Навіщо взагалі тестувати WAF та бот‑захист “з мобільних мереж”
Cloudflare стоїть між вашим сайтом і користувачем та приймає рішення, що робити з кожним запитом: пропустити, залогувати, видати challenge (CAPTCHA/JS) або заблокувати. Для власника сайту це зручно: не потрібно ставити окремий WAF, а базові правила і “керування ботами” доступні в панелі керування.
Проблема в тому, що мобільний трафік не схожий на “звичайний”. Українські оператори використовують NAT/CGNAT, через який тисячі абонентів можуть виходити в інтернет з одних і тих самих публічних IP. Додайте сюди часті зміни IP, різні ASN, особливості DNS/IPv6, різні браузери й додатки — і отримаєте типову ситуацію: захист “бачить” підозрілу поведінку там, де насправді є легітимні клієнти.
Тому тестування Cloudflare WAF з мобільних IP — це не “хакерська штука”, а нормальна QA‑процедура: перевірити, чи не відрізаєте ви власну аудиторію з lifecell/Vodafone/Kyivstar та інших мереж.
Що таке Cloudflare WAF і бот‑фільтри в контексті власника сайту
У Cloudflare за безпеку відповідає кілька шарів, і їх важливо не плутати:
- WAF Managed Rules — керовані правила від Cloudflare (та партнерів), які ловлять типові атаки й уразливості. Вони мають окремі rule ID та категорії.
- Custom rules (власні правила у WAF/Firewall) — ви самі задаєте умови та дію: Block, Challenge, Log, Skip тощо.
- Bot protection — механізми для оцінки бот‑трафіку (залежно від плану: Bot Fight Mode / Super Bot Fight Mode / Bot Management). Це може впливати на challenge/мітигацію, навіть якщо WAF налаштований “м’яко”.
- Rate limiting / DDoS — окремі механізми проти надмірної частоти запитів.
Ключова думка: false positive може прийти з будь‑якого шару. Тому “вимкнув WAF — не допомогло” часто означає, що спрацював бот‑фільтр або rate limiting. А “додав Allow” інколи обходить більше, ніж ви планували, і створює дірку.
Як виглядають false positive на практиці
Помилкове спрацювання — це коли реальний користувач отримує блок/челендж без очевидної причини. Типові симптоми:
- Скарги “з мобільного не відкривається”, але з Wi‑Fi все нормально.
- Проблема прив’язана до конкретного оператора або регіону (наприклад, тільки lifecell).
- Проблема з’являється після зміни правил, оновлення managed rules або запуску нового антибот‑режиму.
- Блокується конкретний маршрут: /login, /checkout, /api/*, /wp-admin/admin-ajax.php, /graphql тощо.
Важливо: у мобільних мережах часто “піднімається” спільний IP, на якому вже є погана репутація через інших абонентів. Тому не варто робити висновок “lifecell поганий”. Правильний підхід — зібрати докази, знайти правило, що спрацювало, і відкоригувати саме його.
Де в Cloudflare шукати причину блокування
Починайте з Security / Security Center → Events (або Security Events). Це ваш основний журнал. Для кожної події зазвичай є:
- Action (Block/JS Challenge/Managed Challenge/Log/Allow тощо);
- Service або тип правила (WAF Managed, Custom rule, Bot, Rate limiting);
- Rule ID / Managed rule ID, назва правила, правила/пакет;
- Ray ID — ідентифікатор запиту (дуже корисний для підтримки та відтворення);
- Client IP, ASN, країна, user‑agent;
- Host, URI, method, інколи додаткові поля (наприклад, score або категорія).
Якщо команда підтримки/QA отримала скрін “403”, попросіть у користувача (або з вашого логу) Ray ID зі сторінки помилки Cloudflare — це швидко звужує пошук.
Чому мобільні мережі частіше ловлять false positive
- CGNAT і спільні IP: багато користувачів за одним IP = висока “щільність” запитів.
- Часті зміни IP: якщо у вас правила на основі “підозрілої зміни IP”, мобільні клієнти потрапляють під них першими.
- Нестандартні UA/додатки: мобільні in‑app браузери, WebView, старі пристрої з дивними заголовками.
- IPv6/IPv4 змішування: інколи різні маршрути мають різну поведінку і репутацію.
- Поведінкові патерни: автологін, повторні запити до API, “порожні” реферери, багато паралельних ресурсів.
Як мобільні проксі допомагають у QA Cloudflare WAF
Мобільні проксі (зокрема з українських операторів) — це інструмент, щоб відтворити реальні умови клієнта без того, щоб ганяти людей по скриптах і збирати ручні репорти. В QA‑сценаріях це дає:
- Перевірку різних ASN України (Kyivstar/Vodafone/lifecell та інші) з реальними мобільними IP;
- Швидке порівняння “мобільна мережа vs домашній інтернет” при однакових діях;
- Відтворення проблеми “в конкретного оператора” і збір Ray ID/подій у журналі;
- Перевірку, що ваші винятки не надто широкі і не відкривають дірок.
Важливе правило: мобільні проксі мають бути інструментом тестування, а не способом “обходити” ваш захист у продакшені. Мета — зробити правила точнішими для легітимних користувачів.
Покроковий процес: як знайти й виправити помилкове спрацювання
Нижче — робочий алгоритм, який можна повторювати для будь‑якого false positive.
Крок 1. Зберіть мінімальні артефакти
- URL, який блокується, та метод (GET/POST).
- Час інциденту (з запасом ±10 хв).
- Ray ID (якщо є).
- Оператор/мережа (lifecell/Vodafone/Kyivstar), чи був VPN, чи це додаток або браузер.
Крок 2. Відтворіть через мобільний проксі потрібного оператора
Використайте мобільний IP цього оператора та повторіть сценарій (логін, додавання в кошик, виклик API). Якщо проблема відтворюється — одразу копіюйте Ray ID або фіксуйте точний час.
Крок 3. Знайдіть подію в Security Events
У журналі застосуйте фільтри: host, URI, action (Block/Challenge), а якщо є Ray ID — шукайте прямо по ньому. Важливо визначити джерело рішення: managed rule, custom rule, bot‑механіка чи rate limiting.
Крок 4. Визначте “суть” спрацювання
Зазвичай ви побачите rule ID або назву правила. Далі треба відповісти на питання:
- Це кероване WAF‑правило (Managed Rules)?
- Це ваше кастомне правило?
- Це бот‑захист (challenge/мітигація, пов’язана з bot)?
- Це rate limiting або інший механізм?
Від цього залежить правильний спосіб “поправити” ситуацію.
Крок 5. Виправте мінімально достатньою зміною
Найкраща практика — робити зміни найвужчими:
- спочатку перевести правило в Log (як тимчасовий запобіжник);
- далі зробити виняток тільки для потрібного URI/параметрів/методу/країни/ASN;
- і лише якщо треба — змінювати чутливість або повністю вимикати правило.
Як правильно ставити винятки в Cloudflare (щоб не зламати безпеку)
Для managed rules у Cloudflare коректний підхід — Exceptions / Skip: ви пропускаєте виконання певних правил або ruleset для запитів, які відповідають вашій умові (наприклад, конкретний endpoint або конкретний операторський ASN).
Що варто включати в умову винятку:
- Host (якщо у вас кілька піддоменів);
- Path (точний URI або префікс /api/*);
- Method (часто проблема тільки з POST);
- Content-Type (JSON vs form‑data);
- ASN (коли проблема суворо операторська);
- Окремі параметри (інколи фальшивий тригер викликає конкретний параметр).
Чого краще уникати:
- Глобального Allow “для країни UA” або “для всіх мобільних ASN” без обмеження по URI.
- Вимикання всього ruleset замість одного правила.
- Винятків тільки за user‑agent (його легко підробити).
Кейс: сайт ріже клієнтів lifecell через правило WAF
Сценарій типовий для e‑commerce/кабінетів з API:
- Команда підтримки отримує звернення: “з lifecell не можу залогінитися/оформити замовлення”.
- З Wi‑Fi проблема не відтворюється, з іншого оператора — теж ні.
- Після увімкнення/посилення WAF або після оновлення managed rules з’явилися блоки.
Як команда відтворила проблему
- Беруть мобільний проксі саме з lifecell.
- Відтворюють сценарій логіну (POST /api/auth/login або /login).
- Фіксують час і Ray ID з екрана помилки.
Що показали логи Cloudflare
У Security Events видно: action = Block (або Managed Challenge), service = WAF Managed Rules, rule ID = конкретне правило з ruleset (наприклад, спрацювання на “інʼєкцію” через один параметр або через JSON‑тіло). Додатково видно, що ASN належить lifecell і на цьому IP багато запитів у короткий час (через CGNAT).
Як правило скоригували
- Тимчасово перевели дію правила в Log для цього endpoint — щоб не різати користувачів, поки триває розбір.
- Далі створили виняток (Skip) тільки для POST на /api/auth/login при певному форматі JSON, залишивши решту правил активними.
- Додали додаткову серверну валідацію на бекенді (щоб компенсувати зменшення WAF‑контролю саме на цьому endpoint).
Як перевірили результат
- Повторили логін з lifecell‑проксі: блоки зникли.
- Переконалися в Security Events, що тепер події йдуть у Log, а не Block.
- Прогнали негативні тести (типові payload’и), щоб переконатися, що виняток не відкрив шлях реальним атакам.
Що ще корисно дивитися, окрім Security Events
- Origin logs: чи доходить запит до вашого сервера, чи відрізається на edge.
- Application logs: конкретні помилки в авторизації/сесії, які можуть виглядати як “WAF блокує”.
- Analytics / Traffic: різкі провали по країні/ASN або по конкретних URL після зміни правил.
- Частота 4xx/5xx: інколи WAF не блокує, але challenge ламає UX і підвищує відмови.
Практичні поради: як мінімізувати false positive в майбутньому
- Стейджинг‑перевірка: перед застосуванням жорстких правил — тестуйте через мобільні проксі різних операторів.
- Поступове посилення: спочатку Log/Challenge, і лише потім Block для правил з ризиком false positive.
- Сегментація: різні правила для /api, /admin, /checkout, бо профіль ризику різний.
- Нормальна серверна валідація: WAF не має бути єдиним бар’єром, особливо для auth.
- Моніторинг по ASN: раз на тиждень дивіться, чи не ростуть блоки на українських мобільних мережах.
Чек‑лист для “тестування Cloudflare WAF з мобільних ip”
- Прогнати сценарії: головна, пошук, логін, форма, checkout, ключові API.
- Повторити з 2–3 українських операторів (різні ASN).
- Зафіксувати Ray ID для будь‑якої підозрілої поведінки.
- У Security Events визначити джерело рішення (managed/custom/bot/rate).
- Виправити мінімально: Log → вузький Skip/Exception → перевірка негативних сценаріїв.
- Перевірити метрики після зміни (блоки, 4xx, конверсія, bounce).
Висновок
Мобільні мережі України — реальність вашої аудиторії. Якщо ви будуєте захист у Cloudflare, тестування на реальному мобільному трафіку допомагає знайти “сліпі зони”, де WAF або бот‑фільтри помилково ріжуть клієнтів. Правильний шлях — відтворити проблему, знайти конкретне правило в Security Events і виправити його точним винятком, не знімаючи захист глобально.