Новые anti-bot правила никогда не включаются сразу в enforcement. Стандартная практика — shadow/dry-run режим: правило оценивает трафик, логирует решения, но не применяет блокировку.
Реализации у вендоров
| Вендор | Режим | Документация |
|---|---|---|
| Cloudflare | Simulate / Log | Правило срабатывает, трафик не блокируется. Результаты в Firewall Events |
| AWS WAF | Count mode | Считает совпадения без действия. Sampled requests доступны для анализа |
| Oracle WAF | Detect mode | Логирование без блокировки |
| Azure WAF | Detection → Prevention | Стандартный двухфазный rollout |
Типичный процесс
- Разработать правило
- Включить в dry-run на production (с реальным трафиком)
- Мониторить 1–2 недели (зависит от объёма трафика)
- Анализировать false positives и false negatives
- Скорректировать пороги/веса
- Переключить в enforcement
- Продолжить мониторинг первые дни
Тестирование на staging бесполезно
Staging не имеет реального трафика ботов. Dry-run на production — единственный способ калибровки.
Реализация для self-hosted
Env var DRY_RUN=true|false. При true:
- Все сигналы собираются и скор считается
- Prometheus метрики отправляются (чтобы видеть распределение)
- Throttle/tarpit/block логируются, но не применяются
- Лог содержит:
{ score, signals[], tier, dryRun: true, ip, url }
Критично: метрики должны работать одинаково в dry-run и enforcement — иначе дашборды показывают разные картины.
False positive rates
| Диапазон | Оценка | Контекст |
|---|---|---|
| < 0.01% | Отлично | DataDome заявляет этот уровень |
| < 0.1% | Очень хорошо | Enterprise-решения |
| < 1% | Хорошо | Большинство приложений |
| > 5% | Проблема | Немедленный review |
Для graduated response FPR ниже, чем для binary allow/deny — легитимный пользователь максимум получит небольшую задержку, не полную блокировку.
Связанные заметки
- Поведенческий анализ трафика — скоринг и тиры
- Защита API от скрейпинга — общая стратегия