Rule Engine
Точные правила по IP/сети, User‑Agent, URL и комбинациям признаков.
Подробнее →AntiPF помогает разделять полезный, неизвестный и подозрительный трафик по правилам, crawler identity, сетевому контексту, браузерным и поведенческим сигналам. Цель — не «забанить всё необычное», а получить управляемое решение и понятную причину.
Поисковый робот, uptime‑monitor, парсер каталога, рекламный клик‑бот и браузерная автоматизация решают разные задачи. Их нельзя безопасно обрабатывать одним глобальным правилом.
Читают большое число URL и могут создавать нагрузку или копировать данные.
Могут генерировать некачественные переходы, расходовать бюджет и искажать аналитику.
Автоматически отправляют формы, создают регистрации, заявки, комментарии или другой мусорный контент.
Пытается имитировать реальные сессии, последовательности просмотров и взаимодействия.
Поисковые crawler и технические сервисы нельзя смешивать с вредоносной автоматизацией.
Защита работает надёжнее, когда система знает не только IP и User‑Agent, но и причину доверять или не доверять запросу.
Явные allow/block политики и системные исключения.
Проверка поисковой идентичности.
Browser / network / behavior / challenge.
Score, confidence, freshness и доступность источников.
ALLOW, наблюдение, Challenge или ограничение.
Каждый слой решает свою задачу и может использоваться независимо от остальных.
Точные правила по IP/сети, User‑Agent, URL и комбинациям признаков.
Подробнее →Объединяет evidence и показывает predicted action.
Подробнее →Подтверждает подозрительные сессии без обязательного постоянного бана.
Подробнее →Дополнительные automation/consistency‑сигналы.
Подробнее →Последовательности, reputation и baseline с минимальными выборками/decay.
Подробнее →Отдельный hard‑контур для настоящих поисковых роботов.
Подробнее →Обычный антибот легко может принять поискового робота за подозрительный запрос: нет JavaScript, необычный rate, пустой referrer. Поэтому в AntiPF crawler verification стоит выше Browser/Adaptive/Risk.
Практически — сначала классифицировать полезный и неизвестный automated traffic, включить наблюдение, проверить crawler identity, затем добавлять Challenge/rate/hard‑правила на подтверждённые сценарии.
Нет. Hosting/VPN/proxy — контекст, а не универсальное доказательство бота. В AntiPF такие сигналы должны учитывать состояние источника и давать вклад в risk, а не безусловный приговор.
Нет. Challenge — один из вариантов действия. Он должен применяться тогда, когда достаточно evidence и сам challenge‑контур здоров.
Сайт должен продолжить работу. Ошибка probe, CSP‑блокировка или отсутствие JS трактуются fail‑neutral, а не дают visitor 500 или жёсткий BLOCK.
Да. AntiPF не требует быть единственным защитным слоем и может работать на application‑уровне за внешним proxy/WAF, если корректно настроена передача реального клиента и trust boundary.
Для старта достаточно домена и примеров симптомов: нагрузка, массовый просмотр URL, подозрительные лиды, рекламные переходы или fake crawlers.