В данном разделе описывается порядок верификации созданных правил WAF, включая проверку корректности логики условий, статуса включения, ожидаемого эффекта на трафик и фиксацию результата в журналах. Правила поддерживают объединение условий внутри группы по логике И, объединение групп по логике "ИЛИ", а также инверсию общего результата через параметр «Инвертировать результат "НЕ"». Действие правила задается как «Разрешить» либо «Запретить», а само правило имеет признак «Включено». Указанные элементы и их семантика соответствуют спецификации конструктора правил.

 

Проверка правила

  1. Убедитесь, что правило сохранено и активно.
    Проверьте, что правило отображается в перечне, действие соответствует требуемому сценарию, переключатель «Включено» активен.
  2. Просмотрите конфигурацию условия.
    Откройте карточку правила и проверьте: область проверки, оператор, содержимое значений, состав групп и наличие/отсутствие инверсии результата. Для составных правил подтвердите ожидаемую логику "И" и "ИЛИ".
  3. Выполните тестовые HTTP‑запросы из среды, подпадающей под условия.
    Рекомендуется использовать изолированный источник трафика (VPN‑выход, отдельный сервер) с предсказуемым исходящим IP. Базовая проверка статуса ответа: 
    curl -s -o /dev/null -w '%{http_code}\n' https://<ваш-домен>/

    Ожидаемые коды: 
    для правил «Запретить» — код блокировки приложения (например, 403) либо фирменная страница WAF;
    для правил «Разрешить» — успешный код приложения (обычно 200/302).
  4. Зафиксируйте проверку поведения при альтернативных группах.
    Если правило содержит несколько групп (логика "ИЛИ"), выполните запросы из каждой релевантной среды, чтобы подтвердить, что срабатывает хотя бы одна группа, а лишние группы не влияют на итоговый результат.
  5. При наличии прокси/CDN проверьте источник IP, который анализирует WAF.
    Убедитесь, что система использует реальный клиентский адрес, а не IP узла CDN. В тестах не полагайтесь на подстановку заголовков со стороны клиента («X‑Forwarded‑For») без правильно настроенного доверенного списка, иначе результат проверки будет недостоверным.
  6. Проверьте журналы событий WAF.
    Откройте журнал и убедитесь, что запросы из тестовой среды зафиксированы с указанием действия правила («разрешено» или «запрещено»), совпадает область проверки и оператор, а также отображается ссылка на имя правила.
  7. Подтвердите отсутствие побочных эффектов.
    Выполните контрольные запросы из легитимных сред, не подпадающих под условия, чтобы убедиться в отсутствии ложных срабатываний.
  8. Рекомендуется хранить артефакты проверки: командные строки, временные IP тестовой среды, отметки из журналов и полученные коды ответов. Для сложных правил документируйте, какие группы и условия обеспечили срабатывание. При изменении набора значений в условиях (например, актуализация подсетей или групп IP) следует повторять проверку по указанной схеме и фиксировать результат в журнале изменений. Логика объединения условий и групп, а также параметр инверсии результата остаются ключевыми точками контроля при каждом цикле проверки.