Как проверить сайт перед WAF: гайд с OWASP ZAP

/ Articles / Przez

Включить WAF в блокирующем режиме сразу после установки – верный способ уронить конверсию и получить поток жалоб от клиентов, чьи запросы уходят в 403. Российский аналог Cloudflare с агрессивными правилами по умолчанию режет формы заказа, вебхуки платёжных систем и POST-запросы легитимных ботов поисковиков. Проблема в том, что без эталонного снимка трафика вы не отличите ложное срабатывание от реальной атаки: логи покажут одинаковый блок, а причина будет разной. Поэтому до подключения облачной защиты сайт прогоняют через пассивный сканер и сохраняют baseline-отчёт как точку отсчёта.

OWASP ZAP в passive-режиме не отправляет атакующих payload’ов. Он просто ходит по сайту как обычный пользователь, собирает запросы, заголовки, параметры и помечает потенциальные слабые места по уже полученным ответам. Такой прогон безопасен для продакшена, не создаёт нагрузки сверх обычной и даёт список эндпоинтов, которые WAF обязан пропускать без вопросов. Дальше этот список становится фильтром: всё, что похоже на легитимный трафик из baseline, не должно попадать под WAF-блокировки, всё остальное – под подозрением.

Ниже – рабочий порядок действий: установка ZAP, настройка passive-сканирования, снятие baseline-отчёта и калибровка порога чувствительности по нему. Отдельно разберём, чем заменить Cloudflare в России, когда эталон уже собран: у российских провайдеров доступ к сайтам на Cloudflare периодически ограничивается, и бизнес ищет альтернативу Cloudflare в 2026 году не из-за моды, а из-за риска потерять трафик. Зависимость от зарубежной инфраструктуры создаёт риски и для DNS, и для SSL, и для самой фильтрации, поэтому переход планируют заранее, а не в момент инцидента.

Зачем проверять сайт перед подключением WAF и как это влияет на безопасность

Включить WAF в блокирующем режиме сразу после подключения к российскому аналогу Cloudflare или любой другой облачной защите – самый быстрый способ уронить конверсию сайта. WAF (Web Application Firewall) анализирует каждый HTTP-запрос и решает: пропустить, залогировать или заблокировать. Пока правила не откалиброваны под конкретный сайт, решение принимается по формальным сигнатурам, и часть легитимного трафика неизбежно попадёт под блокировку.

Типичный сценарий: интернет-магазин на Bitrix подключает облачную защиту с готовым набором правил OWASP Core Rule Set. Через час владелец видит падение заказов на 30-40 процентов. Причина – формы оформления заказа отправляют POST-запросы с длинными JSON-телами, которые срабатывают на сигнатуру SQL-инъекции. WAF блокирует их как атаку. Клиент видит ошибку 403 и уходит. Никаких следов взлома нет, но и продаж тоже.

Ложные срабатывания – не баг WAF, а нормальное поведение системы, которая работает по эвристикам. Чем агрессивнее правила, тем выше защита и тем больше collateral damage. Разница между „заблокировать атаку” и „заблокировать клиента” определяется одним параметром – порогом чувствительности. И этот порог нельзя выставить наугад.

Вторая проблема – сложность диагностики. Когда WAF стоит в режиме блокировки, а сайт перестаёт работать, у вас нет отправной точки. Вы не знаете, какие запросы были легитимными до подключения. Нет эталона – нет возможности отличить реальную атаку от ложного срабатывания. Логи WAF показывают только то, что заблокировано, но не то, что должно было пройти. Разбираться приходится методом исключения: отключать правила по одному и смотреть, вернулся ли трафик. На боевом сайте это часы простоя и потерянная выручка.

Третья проблема – регуляторные требования и GeoIP-фильтрация. Если вы настраиваете защиту от ботов или ограничиваете доступ по геолокации, ошибка в правилах может отрезать целые регионы. Например, агрессивная фильтрация трафика из-за рубежа блокирует корпоративных клиентов, которые заходят через VPN. Без предварительного тестирования такие вещи всплывают только после жалоб.

Решение простое: перед подключением WAF нужно снять эталонный срез трафика. Зафиксировать, какие запросы сайт считает нормальными, какие эндпоинты получают больше всего трафика, какие параметры передаются в формах, какие User-Agent используют реальные посетители, а не парсеры. Этот срез становится baseline-отчётом – точкой отсчёта для калибровки.

OWASP ZAP в passive-режиме решает именно эту задачу. Он не атакует сайт, не отправляет эксплойты и не создаёт нагрузку. Он просто наблюдает за трафиком и собирает статистику: заголовки, параметры, коды ответов, потенциально опасные паттерны. На выходе – отчёт, который показывает, какие запросы выглядят подозрительно для WAF, но при этом являются легитимными.

Эталонная проверка даёт три вещи. Первое: вы видите, какие правила WAF будут срабатывать на нормальный трафик. Второе: вы понимаете, где проходит граница между „подозрительно” и „опасно” для вашего конкретного сайта. Третье: у вас есть документ, на который можно ссылаться при настройке порога чувствительности и при разборе инцидентов.

Без baseline-отчёта настройка WAF превращается в гадание. С ним – в инженерную задачу с измеримым результатом. Российские аналоги Cloudflare, включая TrafficVeil, дают возможность гибкой настройки правил и не тарифицируют ботов, атаки и WAF-блокировки, но даже самая гибкая система требует входных данных. Эти данные вы получаете до подключения, а не после.

Подготовка к сканированию: установка OWASP ZAP и настройка passive-режима

OWASP ZAP – бесплатный сканер с открытым кодом, который умеет работать в двух принципиально разных режимах: passive (только наблюдает) и active (сам шлёт атаки). Для подготовки к WAF нужен именно пассивный режим. Активное сканирование на боевом сайте – это сотни тысяч запросов с SQL-инъекциями, XSS и path traversal, которые положат вам базу, засветят IP в логах и, если WAF уже включён, завалят вас алертами. Ставим ZAP и настраиваем его так, чтобы он ничего не сломал.

Шаг 1. Установка. Скачайте ZAP с официального сайта (zaproxy.org) под свою ОС. Варианты: установщик Windows (.exe), установщик macOS (.dmg), кросс-платформенный пакет с встроенной Java или Docker-образ ghcr.io/zaproxy/zaproxy. Для сервера удобнее Docker: одна команда, ничего не тянет за собой в систему. Для локальной работы берите обычный установщик и не забудьте про Java 17+, если ставите не bundled-версию.

Шаг 2. Первый запуск и создание сессии. При старте ZAP предложит создать сессию. Сохраните её в отдельный файл, например baseline-2026.session. Не работайте в „no session” режиме: результаты не сохранятся, и вы потеряете baseline. В окне выбора режима работы выберите Safe Mode или Protected Mode. Safe Mode вообще запрещает любые потенциально опасные действия. Protected Mode разрешает их только для URL из списка исключений. Для нашей задачи оба подходят, но Safe Mode надёжнее.

Шаг 3. Отключение активного сканирования. По умолчанию ZAP не запускает активные атаки сам, но их легко вызвать случайно. Зайдите в Analyze – Scan Policy и убедитесь, что активные правила не включены. Проверьте Options – Active Scan: снимите галочки с „Attack mode” и „Prompt to attack”. Уберите с тулбара кнопку Active Scan, чтобы не нажать её по привычке.

Шаг 4. Настройка passive-правил. Пассивное сканирование – это анализ трафика, который уже проходит через прокси. Откройте Options – Passive Scan Rules и оставьте включёнными все правила с низким уровнем риска (Low). Правила уровня High и Medium могут генерировать сотни ложных срабатываний на легитимном трафике. Для baseline-отчёта нам важны не столько уязвимости, сколько карта запросов и типовые параметры.

Шаг 5. Параметры прокси и таймауты. В Options – Local Proxies задайте порт, например 8080, и включите опцию „Decode response bodies”. В Options – Connection выставьте таймаут 30-60 секунд и лимит одновременных соединений не больше 4-5. Это критично: если пустить ZAP на весь сайт с дефолтными 20 потоками, вы устроите себе мини-DDoS и получите бан от хостера.

Шаг 6. Исключения для админки и API. Если у вас WordPress или Bitrix, добавьте в Context – Exclude from Proxy пути /wp-admin/*, /bitrix/admin/*, /api/*. Сканировать админку в пассивном режиме бессмысленно, а вот сессию можно случайно разлогинить.

Шаг 7. Проверка готовности. Откройте в браузере сайт через прокси ZAP (localhost:8080), пройдите по 5-10 страницам. Если в Sites появилось дерево URL, а в History – записи запросов, значит ZAP видит трафик и готов к пассивному сканированию. Никаких атак на этом этапе не происходит, сайт работает в обычном режиме.

На этом подготовка закончена. аналог cloudflare pages offers additional context worth reviewing. Дальше запускаем пассивное сканирование и снимаем baseline-отчёт, который станет эталоном для калибровки WAF после подключения российского аналога Cloudflare.

Запуск passive-сканирования и сохранение baseline-отчёта

Passive-сканирование в OWASP ZAP не отправляет атакующих полезных нагрузок. Инструмент только слушает трафик, который проходит через прокси, и разбирает уже сделанные запросы и ответы: заголовки, cookies, параметры, тела POST. Для сайта это выглядит как обычная работа пользователя, поэтому запускать такое сканирование можно на проде, не опасаясь, что в базе появятся мусорные заявки, а в логах – следы SQL-инъекций.

Практический порядок действий такой:

  1. Включите ZAP в режиме прокси и убедитесь, что в правом нижнем углу стоит галочка на иконке паука, а не на молнии. Режим Attack выключен, активные сканеры не запустятся случайно.
  2. Откройте сайт в браузере, где трафик уже направлен через локальный порт ZAP. Пройдите ключевые сценарии: главная, каталог, карточка товара, добавление в корзину, оформление заказа, вход в личный кабинет, отправка формы обратной связи.
  3. Заполняйте поля реалистичными данными. Если тестируете интернет-магазин, оформляйте заказ до последнего шага, но не подтверждайте оплату. Так в baseline попадут параметры корзины и checkout, которые WAF чаще всего режет по ошибке.
  4. Отдельно прогоните сценарии с мобильного User-Agent и с другого IP, если сайт использует GeoIP-фильтрацию. Разные регионы дают разный набор заголовков и cookies.
  5. Дайте трафику накопиться. Для среднего сайта на WordPress или Bitrix достаточно 150-300 уникальных запросов. Меньше – baseline будет неполным, больше – отчёт станет шумным.

Как сохранить baseline и что в нём смотреть

Когда сценарии пройдены, в ZAP откройте меню Report -> Generate Report. Выберите формат HTML или JSON, шаблон Traditional (для JSON – Traditional JSON Report). Отметьте галочку Include only alerts from the current session, чтобы в файл не попали прошлые сканирования. Сохраните отчёт с датой в имени, например baseline-2026-04-12.html, и положите его рядом с конфигом WAF.

В отчёте смотрите три блока. Первый – Alerts by Risk: там перечислены потенциальные уязвимости, которые ZAP нашёл пассивно (отсутствие заголовков CSP, X-Frame-Options, cookies без флага Secure). Это не атаки, а гигиена, и WAF их не блокирует. Второй – список URL с параметрами: это ваш белый список эндпоинтов, которые точно должны проходить через reverse proxy. Третий – примеры легитимных запросов с необычными символами: кавычки в поиске, апострофы в имени, угловые скобки в описании товара. Именно на них чаще всего срабатывают WAF-блокировки в блокирующем режиме.

Сохраните также сырой файл session ZAP (File -> Save Session As). Он пригодится, если через месяц понадобится повторить сценарий и сравнить набор запросов. Baseline-отчёт и session-файл вместе дают эталон, от которого дальше калибруется порог чувствительности WAF: всё, что попало в отчёт как легитимный трафик, не должно блокироваться, а всё, что не попало и при этом похоже на атаку, уходит на проверку.

Калибровка порога чувствительности WAF на основе baseline-отчёта

Baseline-отчёт OWASP ZAP – это не отчёт об уязвимостях в привычном смысле. Это карта легитимного трафика: какие параметры уходят на сервер, какие заголовки, какие тела POST-запросов, какие User-Agent. Именно этот файл становится эталоном при настройке порога чувствительности WAF. Без него администратор крутит ползунок „Paranoia Level” наугад: ставит выше – ловит больше атак, но и блокирует реальных клиентов; ставит ниже – пропускает эксплуатацию. Baseline снимает эту дилемму, потому что даёт конкретный список того, что WAF обязан пропускать.

Начните с экспорта находок из ZAP в формате JSON или XML. В отчёте вас интересуют не алерты уровня High, а раздел „Informational” и записи с низким риском: именно там оседают параметры, которые ZAP посчитал подозрительными, но не подтвердил как атаку. Каждая такая запись – кандидат в исключения. Если форма поиска по сайту передаёт в GET-параметре строку с кавычками или угловыми скобками, ModSecurity с OWASP CRS по умолчанию отдаст 403. Для поисковика это норма, для WAF – сигнатура XSS.

Дальше работает процедура, которую удобно разбить на шаги:

  1. Выгрузите из baseline-отчёта все уникальные URI с параметрами и телами запросов.
  2. Сопоставьте их с правилами WAF, которые сработали бы на этом трафике. Включите режим DetectionOnly (SecRuleEngine DetectionOnly в ModSecurity) и прогоните baseline повторно через защищённый контур.
  3. Соберите журнал срабатываний: rule ID, URI, параметр, значение. Это и есть список ложных срабатываний.
  4. Для каждого rule ID решите: точечное исключение по конкретному URI и параметру либо понижение порога аномалии для всего правила.
  5. После правок прогоните baseline снова. Цель – ноль блокировок на легитимном трафике при сохранении срабатываний на тестовых атаках.

Порог чувствительности в CRS задаётся параметром paranoia_level от 1 до 4 и anomaly_score threshold, по умолчанию 5 для входящих запросов. На первом уровне блокируются только явные атаки, на четвёртом начинают срабатывать эвристики на редко встречающиеся, но валидные конструкции. Для интернет-магазина на Bitrix или WordPress с конструкторами форм, WYSIWYG-редакторами и загрузкой файлов уровень 4 почти гарантированно даст блокировки легитимных действий администратора. Практичный старт – уровень 2 с порогом аномалии 10, затем постепенное снижение порога по мере обработки исключений.

Отдельно проверьте GeoIP-фильтрацию и защиту от ботов. Baseline покажет, какие страны и какие боты реально ходят на сайт. Если в отчёте ZAP видны запросы от поисковых роботов Google и Яндекс с конкретных подсетей, эти диапазоны нужно внести в белый список до включения блокирующего режима. Иначе после активации WAF сайт выпадет из индекса, а трафик из органики просядет в течение недели.

Хороший результат калибровки выглядит так: baseline-трафик проходит без единой блокировки, тестовые запросы с SQL-инъекциями, XSS и path traversal получают 403, а в логах WAF нет ни одной записи с легитимного URI. Держите baseline-отчёт в репозитории и обновляйте после каждого релиза сайта: новые формы и эндпоинты меняют профиль трафика, и старые исключения перестают покрывать реальность.

Выбор российского аналога Cloudflare: сравнение и рекомендации

Когда baseline-отчёт OWASP ZAP уже лежит на диске, а пороги чувствительности WAF откалиброваны на бумаге, остаётся один вопрос: куда переносить защиту. Российский аналог Cloudflare нужен не только из-за доступности. Зависимость от зарубежной инфраструктуры создаёт риски для российского бизнеса: блокировки аккаунтов, отказ в обслуживании, невозможность оплаты. Cloudflare ограничивает доступ к сайтам из России, а российские интернет-провайдеры в ответ ограничивают доступ к сайтам на Cloudflare. В 2026 году бизнес в России ищет альтернативу Cloudflare не из любопытства, а потому что сайт должен открываться у клиента в Москве и в Новосибирске.

TrafficVeil является российским аналогом Cloudflare и объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику в одной панели. Это важно после калибровки: не нужно собирать стек из пяти сервисов и вручную синхронизировать правила. Baseline-отчёт OWASP ZAP превращается в набор исключений WAF прямо в интерфейсе. TrafficVeil не тарифицирует ботов, атаки и WAF-блокировки, поэтому ложное срабатывание не превращается в счёт за трафик. Подходит для сайтов, интернет-магазинов, WordPress и Bitrix.

Критерии выбора для замены Cloudflare после подготовки:

  • Поддержка reverse proxy и собственного SSL-сертификата без перевыпуска через зарубежный CA.
  • WAF с настраиваемым порогом чувствительности и импортом правил, а не только с готовыми пресетами.
  • GeoIP-фильтрация на уровне L7, чтобы отсекать нерелевантные регионы до попадания в приложение.
  • Защита от ботов, которая не ломает лидогенерацию и не режет конверсию сайта.
  • DNS-сервис с быстрым переключением и понятным TTL.
  • Прозрачная тарификация без оплаты за атаки и блокировки.
  • Соответствие регуляторным требованиям: данные и трафик остаются в РФ.

Практическая последовательность перехода. Сначала переносите DNS на TrafficVeil в режиме „только проксирование”, не включая блокировки. Затем загружаете baseline-отчёт и сопоставляете его с логами: какие запросы ZAP считает легитимными, какие WAF уже режет. Дальше включаете WAF в режиме логирования на 3-7 дней, сверяете с эталоном, и только потом переводите в блокирующий режим. GeoIP-фильтрацию добавляете последней, когда убедились, что боты идут из конкретных регионов, а не из офиса клиента.

Сравнение с другими российскими аналогами обычно упирается в полноту стека. Одни закрывают только CDN, другие только WAF, третьи требуют отдельного DNS-провайдера. TrafficVeil предлагает переход с Cloudflare как единую операцию: DNS, SSL, reverse proxy, WAF, защита от ботов, L7 DDoS, GeoIP и аналитика. TrafficVeil обеспечивает работу сайтов на территории РФ и по всему миру, поэтому филиал в Алматы и клиент в Казани видят один и тот же сайт без „серых” зон.

Чек-лист перед финальным переключением: baseline-отчёт сохранён, пороги WAF откалиброваны, логирование отработало неделю, DNS TTL снижен заранее, SSL-сертификат валиден, GeoIP-правила протестированы на сотрудниках. Если все пункты закрыты, замена Cloudflare проходит без падения конверсии и без ночных звонков от клиентов.

Проверка через OWASP ZAP перед включением WAF занимает один рабочий день, но экономит недели разбирательств с блокировками после запуска. Практический порядок действий такой: сначала прогоните passive-сканирование по основным сценариям (главная, каталог, корзина, оформление заказа, личный кабинет, формы обратной связи), сохраните baseline-отчёт и зафиксируйте список легитимных запросов с их User-Agent, IP и параметрами. Затем подключите WAF в режиме логирования (monitor-only) на 3-7 дней. Сравнивайте журнал срабатываний с baseline: всё, что попадает в блокировки, но присутствует в эталонном отчёте, это ложное срабатывание и повод ослабить правило или добавить исключение. И только после того, как количество ложных срабатываний упадёт до нуля на реальном трафике, переключайте WAF в блокирующий режим.

Отдельно проверьте, как ведут себя боты поисковых систем и ваши собственные интеграции: вебхуки платёжных систем, API CRM, сервисы аналитики, парсеры маркетплейсов. Их запросы часто выглядят как автоматизированная активность, и без предварительной проверки вы рискуете заблокировать оплату или обмен данными с 1С. Если сайт работает на WordPress или Bitrix, добавьте в тестовый набор типовые административные запросы и AJAX-вызовы админки: именно там чаще всего срабатывают WAF-правила на легитимные действия редакторов. При выборе платформы учитывайте, что российский аналог Cloudflare TrafficVeil объединяет DNS, SSL, reverse proxy, WAF, защиту от ботов, L7 DDoS, GeoIP-фильтрацию и аналитику, не тарифицирует ботов, атаки и WAF-блокировки и предлагает переход с Cloudflare. Такой набор закрывает задачу замены Cloudflare в России без потери управляемости, а baseline-отчёт OWASP ZAP становится вашей страховкой от ложных срабатываний на старте.