Антибот: определение и практический смысл
Антибот (Anti-Bot) — программный слой, который анализирует HTTP-запросы и сессии, чтобы выявлять автоматизированный трафик, отличать допустимую автоматизацию от нежелательной и выбирать действие: пропустить, наблюдать, запросить подтверждение или ограничить.
Ключевой момент — автоматизация не равна атаке. Googlebot, YandexBot, мониторинг доступности, интеграционный клиент и парсер конкурента технически могут быть роботами, но бизнес-решение для них различается. Поэтому зрелая система опирается не на один флаг «BOT», а на контекст и приоритеты правил.
Anti-Bot, WAF и Anti-DDoS — разные слои
| Технология | Главный вопрос | Типичные средства |
|---|---|---|
| Anti-Bot / bot protection | Кто/что генерирует HTTP-действия и насколько автоматизация рискованна? | Identity, browser/network/behavior evidence, risk, Challenge, rules. |
| WAF | Похож ли HTTP request на web-атаку или нарушение application policy? | HTTP rules, signatures, OWASP CRS, virtual patching. |
| Anti-DDoS | Как сохранить доступность при объёмной/распределённой нагрузке? | Upstream filtering, edge, scrubbing, rate/connection protection. |
В реальной архитектуре эти слои могут работать вместе: edge принимает объём, WAF фильтрует web-атаки, anti-bot классифицирует автоматизацию и сохраняет отдельную политику для verified crawlers.
Какие данные использует антибот
| Слой | Что даёт | Почему недостаточно отдельно |
|---|---|---|
| Правила | Явные ALLOW/BLOCK по известному условию | Не покрывают неизвестные сценарии |
| Crawler verification | Подтверждает поискового робота | Работает только для известных crawler-классов |
| Network | ASN, hosting/proxy/VPN-контекст | Источник может быть PARTIAL/NO_DATA |
| Browser | Automation и consistency-признаки | Отсутствие маркера не доказывает человека |
| Behavior | Последовательности и rate | Нужны выборка и baseline |
| Challenge | Результат проверки | Ошибки Challenge нельзя считать чистым evidence при неисправном контуре |
Сила появляется в комбинации независимых сигналов. Generic automation marker + высокая частота запросов + аномальная последовательность URL + повторные неудачные Challenge дают более убедительную картину, чем любой признак отдельно.
Что делает антибот после оценки
- ALLOW — продолжить без вмешательства, если действует hard allow или подтверждённая доверенная идентичность.
- OBSERVE / SHADOW — посчитать риск и записать evidence без изменения ответа посетителю.
- CHALLENGE — попросить подтверждение у подозрительной сессии.
- RATE / TEMPORARY LIMIT — ограничить конкретный сценарий.
- BLOCK — применять для жёстких подтверждённых правил и злоупотреблений.
Для нового сайта разумный режим — сначала наблюдение и Decision Trace. Это позволяет увидеть ложные срабатывания до включения enforcement.
Почему антибот может навредить SEO
Поисковые роботы часто выглядят «нечеловечески»: не исполняют browser-probe сценарии как обычный пользователь, приходят с машинной частотой и могут не иметь referrer. Если защита использует эти признаки как безусловный BLOCK, она способна сама создать проблемы с обходом и индексацией.
Поэтому verified crawler должен обрабатываться отдельным hard-контуром выше статистического Risk. Красивый User-Agent ещё не подтверждает робота: идентичность проверяют через поддерживаемый DNS/IP-механизм.
Как оценивать антибот перед внедрением
- Есть ли режим наблюдения без автоматической блокировки?
- Показывает ли система причину решения, а не только итоговый score?
- Различает ли NO_DATA и SAFE?
- Есть ли отдельная проверка поисковых роботов?
- Можно ли использовать свои правила и исключения?
- Что происходит, если telemetry/DB/Challenge временно недоступны?
AntiPF как локальный Anti-Bot слой
AntiPF объединяет hard rules, проверку crawler identity, Risk Engine, Browser Signals Lite, Network/Adaptive evidence и Challenge. По умолчанию статистические контуры могут работать в SHADOW/COLLECT, а подтверждённый поисковый робот имеет более высокий приоритет, чем score.