BinaryCanary: что это за бот мониторинга и нужно ли его блокировать

BinaryCanary — автоматизированный агент сервиса Binary Canary, предназначенного для мониторинга доступности и состояния сайтов, серверов и сетевых сервисов.

Это не поисковый crawler и не сервис массового сбора контента.

Binary Canary официально предоставляет:

• website monitoring;
• URL monitoring;
• IP monitoring;
• HTTP monitoring;
• DNS monitoring;
• FTP monitoring;
• SMTP/email monitoring;
• SQL и database monitoring;
• ping monitoring;
• server performance monitoring.

Cloudflare Radar классифицирует BinaryCanary как Monitoring & Operations bot и указывает оператором Binary Canary.

## Зачем BinaryCanary приходит на сайт

Основная задача BinaryCanary — убедиться, что контролируемый ресурс продолжает работать.

Типичная цепочка выглядит так:

Binary Canary
↓
GET monitoring URL
↓
проверка HTTP response
↓
проверка доступности / времени ответа
↓
OK
или
ошибка → повторная проверка → alert

Поэтому несколько одинаковых запросов к одному URL через равные промежутки времени — нормальная модель поведения monitoring agent.

## Это не crawler всего сайта

В исходном шаблоне использовалось описание:

публичные URL
API
статика
контент
ссылочный граф

Для BinaryCanary оно слишком широкое.

Monitoring service обычно интересуется конкретными target URL, которые настроил пользователь.

Например:

/
/health
/status
/api/health
/healthz
/ping
/login

или конкретной бизнес-страницей:

/checkout/
/pricing/
/critical-service/

если владелец хочет контролировать её доступность.

## Почему один URL может запрашиваться очень регулярно

Binary Canary предлагает мониторинг вплоть до интервала в одну минуту.

Поэтому профиль:

12:00 GET /health
12:01 GET /health
12:02 GET /health
12:03 GET /health
12:04 GET /health

не выглядит аномальным сам по себе.

Для uptime monitoring регулярность — ожидаемое поведение.

## Что происходит при ошибке

У Binary Canary есть интересная защитная логика.

Если первая monitoring location считает цель недоступной, сервис заявляет дополнительную перепроверку из другой точки перед отправкой уведомления.

Поэтому в момент реального сбоя в access.log может появиться небольшой всплеск:

Monitoring location A
↓
FAIL

Monitoring location B
↓
double-check

↓
alert владельцу

Такой мини-всплеск не обязательно означает атаку или aggressive crawling.

## Почему BinaryCanary может появляться с разных IP

Binary Canary использует несколько monitoring locations.

Следовательно, проверки одного сайта могут приходить не строго с одного IP.

При сбое дополнительная проверка может специально выполняться из другой location.

Поэтому правило:

BinaryCanary изменил IP
→ spoofing

будет слишком примитивным.

## Как выглядит User-Agent BinaryCanary

Cloudflare Radar указывает:

http://www.binarycanary.com

как User-Agent BinaryCanary.

Это необычная форма: строка состоит фактически из URL сервиса, а не привычного:

BinaryCanary/1.0

Поэтому для TrafficVeil разумно учитывать как минимум:

binarycanary.com

и наблюдаемые исторические варианты семейства Binary Canary.

## Не путайте BinaryCanary и Chirp

В bot directories встречается ещё один агент того же оператора — Chirp.

Он также связан с Binary Canary и monitoring-задачами.

Поэтому правильнее моделировать:

Operator: Binary Canary
├── BinaryCanary
└── Chirp

а не считать их полностью несвязанными ботами.

## Как найти BinaryCanary в access.log

Поиск по названию:

grep -i "binarycanary" /var/log/nginx/access.log

Но поскольку наблюдаемый UA может содержать домен:

grep -i "binarycanary\.com" /var/log/nginx/access.log

Практический объединённый вариант:

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log

## Количество запросов

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log | wc -l

## Топ URL

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

## Топ IP

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn \
| head -30

## HTTP-коды

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -rn

## Как проверить интервал monitoring

Для uptime agent очень полезно посмотреть timestamps.

grep -iE "binarycanary|binarycanary\.com" /var/log/nginx/access.log \
| awk '{print $1,$4,$7,$9}'

Если виден профиль:

IP-A 12:00 /health 200
IP-A 12:01 /health 200
IP-A 12:02 /health 200
IP-A 12:03 /health 200

это гораздо больше похоже на мониторинг, чем на crawler.

## Как выглядит нормальный BinaryCanary

## Как выглядит подозрительный клиент под UA BinaryCanary

Например:

User-Agent: http://www.binarycanary.com

GET /.env
GET /.git/config
GET /wp-config.php.bak
GET /backup.sql
GET /vendor/phpunit/
GET /phpmyadmin/

Это не похоже на uptime monitoring.

Такой источник нельзя автоматически разрешать только потому, что он назвался BinaryCanary.

TrafficVeil должен переклассифицировать его как:

UA spoofing
/
Security scanning
/
Suspicious automation

## User-Agent не является доказательством

Любой HTTP-клиент может установить:

User-Agent: http://www.binarycanary.com

Поэтому:

UA match
→ unconditional allow

использовать нельзя.

## Как верифицировать BinaryCanary

При отсутствии удобного официального machine-readable IP feed лучше анализировать несколько признаков одновременно:

• User-Agent;
• source IP;
• ASN;
• ASN organization;
• PTR;
• network type;
• TLS fingerprint;
• HTTP fingerprint;
• target URL;
• interval;
• history.

Для monitoring agent особенно сильны:

фиксированный URL
+
регулярный интервал
+
стабильный fingerprint
+
ожидаемые HTTP methods

## ASN здесь полезен, но не абсолютен

Binary Canary работает через несколько monitoring locations, поэтому нельзя ожидать один единственный адрес.

TrafficVeil лучше хранить:

asn
asn_org
network_type
is_datacenter
source_ip
monitoring_location_candidate

и строить профиль со временем.

## Identity Confidence для TrafficVeil

## robots.txt для BinaryCanary

Для monitoring agent robots.txt вообще не является идеальной моделью управления.

Если пользователь специально настроил:

https://example.com/health

как monitoring target, задача агента — проверить этот URL, а не индексировать сайт.

Cloudflare Bot Directory показывает robots-токен BinaryCanary, но отдельной подробной crawler-policy самого Binary Canary с гарантированным robots compliance обнаружить не удалось.

Поэтому для TrafficVeil лучше:

robots.txt relevance: Low
robots.txt compliance: Not relied upon
server-side control: Preferred

## Почему robots.txt здесь менее полезен

robots.txt предназначен прежде всего для управления crawling.

BinaryCanary занимается monitoring.

Например:

User-agent: *
Disallow: /health

не означает, что владелец сайта обязательно хочет запретить собственному monitoring provider проверять /health.

Это две разные политики:

Crawl policy
≠
Monitoring policy

## Если всё же хотите объявить запрет

User-agent: http://www.binarycanary.com
Disallow: /

Но для гарантированного запрета лучше использовать TrafficVeil/WAF/server-side policy.

## Блокировка через Nginx

if ($http_user_agent ~* "binarycanary") {
    return 403;
}

Если в логах используется только доменная форма:

if ($http_user_agent ~* "binarycanary\.com") {
    return 403;
}

Комбинированно:

if ($http_user_agent ~* "binarycanary|binarycanary\.com") {
    return 403;
}

## Apache

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} binarycanary [NC]
RewriteRule ^ - [F,L]

## Почему блокировать BinaryCanary по умолчанию не стоит

Monitoring agent очень часто работает в интересах самого владельца сайта.

Если владелец настроил Binary Canary и TrafficVeil автоматически его заблокировал:

Binary Canary
↓
403
↓
monitor считает сайт недоступным
↓
повторная проверка
↓
ложный incident
↓
alert владельцу

То есть защита фактически ломает monitoring.

## Правильная базовая стратегия

Для подтверждённого BinaryCanary:

Default:
Allow / Monitor

а не:

Default:
Deny

## Когда Allow обязателен

Allow нужен, если:

• Binary Canary используется самим владельцем сайта;
• мониторинг настроен хостингом или подрядчиком;
• проверяется SLA;
• контролируется критический endpoint;
• alerting зависит от успешного запроса.

## Когда использовать Monitor

Monitor подходит, если:

• UA обнаружен;
• источник выглядит как нормальный uptime checker;
• владелец пока не знает, кто его настроил;
• нагрузка ничтожна;
• нет подозрительного поведения.

## Нужен ли Rate Limit

Для нормального BinaryCanary агрессивный Rate Limit обычно не требуется.

Если одна проверка выполняется каждую минуту:

60 requests/hour
1440 requests/day

сама по себе такая частота обычно невелика.

Причём это количество для одного monitoring target; реальная нагрузка зависит от числа настроенных проверок.

## Почему 1 440 запросов в день могут почти ничего не стоить

Если проверяется лёгкий endpoint:

GET /health

200 OK
Content-Length: 15

нагрузка крайне мала.

Если же monitoring target:

/catalog/?complex_dynamic_query=...

и каждый запрос запускает тяжёлый backend render, стоимость совсем другая.

## Поэтому нужен отдельный health endpoint

Если владелец сайта использует uptime monitoring, лучше предоставить лёгкий URL:

/health

или:

/healthz

который быстро проверяет состояние приложения без тяжёлой бизнес-логики.

Так monitoring остаётся информативным и практически не нагружает origin.

## Какие метрики показывать в TrafficVeil

## Почему бинарный «бот хороший / плохой» здесь недостаточен

Для BinaryCanary особенно полезно разделять:

Identity
Purpose
Owner relationship
Behavior
Action

Например:

Identity: BinaryCanary
Purpose: Uptime monitoring
Relationship: Customer configured
Behavior: Normal
Action: Allow

и совершенно другой случай:

Identity claim: BinaryCanary
Purpose: Unknown
Behavior: .env scanning
Action: Block

## Что будет после блокировки

Если это настоящий мониторинг, Binary Canary перестанет корректно видеть доступность сайта.

Результатом могут стать:

• ложные downtime alerts;
• искажённый uptime;
• провалы SLA-отчётов;
• ложные incident notifications.

Поэтому блокировать agent, который используется владельцем сайта, вредно.

## Повлияет ли блокировка на SEO

Нет прямой связи.

BinaryCanary — monitoring service, а не поисковый crawler.

Точечное правило для:

binarycanary

не является правилом для:

Googlebot
YandexBot
Bingbot

## Как учитывать BinaryCanary в аналитике

Monitoring request не является реальным посетителем.

Правильная структура:

Automated Traffic
→ Monitoring & Operations
→ Uptime Monitoring
→ Binary Canary
→ BinaryCanary

Трафик следует:

• исключать из Human Traffic;
• не считать сессией;
• не считать конверсией;
• не считать malicious при нормальном поведении;
• учитывать отдельно в Monitoring Analytics.

## С кем не путать BinaryCanary

## Рекомендуемая карточка TrafficVeil

## Стратегия Allow / Monitor / Rate Limit / Block

## Что показывать пользователю TrafficVeil

Вместо:

«binarycanary — неизвестный легитимный сервис, который выполняет автоматический обход.»

лучше:

BinaryCanary — агент сервиса Binary Canary для мониторинга доступности сайтов и серверов. Он регулярно проверяет настроенный URL и может выполнять проверки вплоть до одного раза в минуту. При обнаружении сбоя Binary Canary перепроверяет цель из другой monitoring location перед отправкой уведомления. Если мониторинг настроен вами или вашим подрядчиком, рекомендуем Allow.

## Итог

BinaryCanary — не crawler контента, а легитимный monitoring agent.

Сервис Binary Canary специализируется на website/server uptime monitoring и контролирует HTTP, URL, IP, DNS, FTP, email, базы данных и другие сервисы. Проверки могут выполняться с минутным интервалом.

Cloudflare Radar отдельно классифицирует BinaryCanary как:

Monitoring & Operations
Operator: Binary Canary

Поэтому для TrafficVeil оптимальная структура:

Monitoring & Operations
→ Uptime & Synthetic Monitoring
→ Binary Canary
→ BinaryCanary

Default: Allow / Monitor
Human Traffic: Exclude

Ключевой вопрос здесь не «легитимный ли это бот», а кто настроил мониторинг. Если это ваш Binary Canary — его нужно разрешить. Если происхождение неизвестно, сначала анализируйте target URL, периодичность, IP/ASN и behaviour. А если под именем BinaryCanary начинается перебор .env, backups или exploit paths, доверие к UA нужно отбросить и классифицировать источник по фактическому поведению.