BilateralNavigator-PageFetch: что это за бот и нужно ли его блокировать

BilateralNavigator-PageFetch — наблюдаемый автоматизированный веб-клиент, связанный по своему User-Agent с проектом Bilateral Navigator.

В публичных crawler-базах фиксируется строка:

BilateralNavigator-PageFetch/1.0 (+https://bilateralnavigator.com/bot)

То есть точнее использовать именно название BilateralNavigator-PageFetch, а не общий токен bilateralnavigator.

При этом исходное описание как «crawler академических или архивных research-проектов» подтверждения не получило.

Сам Bilateral Navigator официально описывает себя как publishing и digital-content project, создающий сравнительные country-to-country публикации о странах, экономике, дипломатии, культуре и международных отношениях. Оператор проекта — Global Brain Power LLC, зарегистрированная в штате Вайоминг, США.

Кто стоит за Bilateral Navigator

В исходном материале оператор был указан как неизвестный. Это можно исправить.

В официальных Terms of Use Bilateral Navigator прямо указано:

• проект называется Bilateral Navigator;
• оператор — Global Brain Power LLC;
• компания зарегистрирована в Wyoming, USA;
• проект создаёт сравнительные публикации между различными странами;
• материалы включают структурированный редакционный контент, статистику и профессиональные комментарии.

То есть сам проект идентифицирован достаточно хорошо.

Для TrafficVeil поэтому лучше:

Operator: Global Brain Power LLC
Project: Bilateral Navigator

вместо:

Operator: unknown

Что делает crawler

Точное техническое описание workflow crawler публично подтверждено хуже, чем существование самого проекта.

Наблюдаемый User-Agent содержит название:

BilateralNavigator-PageFetch

что явно указывает на функцию получения страниц — page fetch.

Сторонние crawler-каталоги классифицируют его как web crawler, который получает и анализирует содержимое страниц.

Однако этого недостаточно, чтобы утверждать, что он:

• работает для академического исследования;
• архивирует интернет;
• создаёт поисковый индекс;
• формирует training dataset;
• используется для LLM training.

Такие утверждения потребовали бы отдельной документации оператора.

Почему версия про академический crawler сомнительна

В исходнике BilateralNavigator описывался как crawler академических или архивных очередей.

При проверке этого подтверждения не нашлось.

Напротив, Bilateral Navigator публично позиционируется как издательский и справочный проект, который создаёт country-to-country материалы для международной аудитории.

Поэтому безопаснее формулировать:

BilateralNavigator-PageFetch — crawler издательского/research-проекта Bilateral Navigator для автоматического получения публичных веб-страниц.

Какую категорию использовать в TrafficVeil

Категория:

Прочие краулеры и сервисы

слишком широкая.

Лучше:

Automated Traffic
→ Content & Research Crawlers
→ Publishing / Research
→ BilateralNavigator-PageFetch

При этом статус:

Identity: Observed
Confidence: Medium

точнее, чем безусловный Verified.

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

Наблюдаемая строка:

BilateralNavigator-PageFetch/1.0 (+https://bilateralnavigator.com/bot)

фиксируется несколькими независимыми crawler/User-Agent каталогами.

Для TrafficVeil основной matcher лучше строить по:

BilateralNavigator-PageFetch

а не просто:

bilateralnavigator

Так уменьшается вероятность случайных совпадений.

Как найти BilateralNavigator-PageFetch в access.log

Базовый поиск:

grep -i "BilateralNavigator-PageFetch" /var/log/nginx/access.log

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

grep -ic "BilateralNavigator-PageFetch" /var/log/nginx/access.log

Топ URL:

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

Топ IP:

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

HTTP-коды:

grep -i "BilateralNavigator-PageFetch" /var/log/nginx/access.log \
| awk '{print $9}' \
| sort \
| uniq -c \
| sort -rn

Как проверить глубину обхода

grep -i "BilateralNavigator-PageFetch" /var/log/nginx/access.log \
| awk '{print $7}' \
| sort -u \
| wc -l

Это покажет, получает ли crawler несколько конкретных страниц или последовательно обходит значительную часть сайта.

Проверьте HTTP-методы

grep -i "BilateralNavigator-PageFetch" /var/log/nginx/access.log \
| awk -F'"' '{print $2}' \
| awk '{print $1}' \
| sort \
| uniq -c \
| sort -rn

Для обычного получения публичных страниц наиболее ожидаемы GET и, возможно, HEAD.

Какие страницы он получает

Публичной документации с фиксированным набором endpoint не найдено.

Поэтому исходный шаблон:

публичные URL
API
статика
пагинация

не стоит выдавать как установленный behavioural fingerprint.

TrafficVeil лучше строить профиль непосредственно по данным:

• Top URLs;
• Unique URLs;
• путь первого запроса;
• переходы между URL;
• частота повторов;
• response size;
• HTTP status.

Есть ли официальный список IP

Публичного официального IP-feed Bilateral Navigator при проверке обнаружить не удалось.

Сторонний сервис WebRobots наблюдал crawler в том числе с адреса:

213.136.70.200

Но сам источник показывает крайне небольшую выборку — всего несколько наблюдений. Поэтому этот адрес нельзя превращать в официальный allowlist.

Правильная запись:

Observed IP: 213.136.70.200

а не:

Official Bilateral Navigator IP

Почему это важно

Если TrafficVeil один раз увидел:

UA: BilateralNavigator-PageFetch
IP: 213.136.70.200

это подтверждает только факт наблюдения.

Оператор может:

• сменить hosting;
• использовать несколько серверов;
• добавить дополнительные IP;
• перенести crawler в другую инфраструктуру.

Поэтому без официального списка IP нельзя делать жёсткую глобальную верификацию по одному адресу.

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

Любой HTTP-клиент способен отправить:

User-Agent: BilateralNavigator-PageFetch/1.0 (+https://bilateralnavigator.com/bot)

Поэтому:

UA match
→ unconditional allow

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

Как верифицировать BilateralNavigator в TrafficVeil

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

• User-Agent;
• IP;
• ASN;
• ASN organization;
• network type;
• reverse DNS;
• TLS fingerprint;
• HTTP fingerprint;
• частоту запросов;
• профиль URL;
• историю наблюдений.

Например:

UA совпадает
+
стабильный ASN
+
одинаковый TLS fingerprint
+
публичные content URL
+
предсказуемая частота
=
Probable BilateralNavigator

Рекомендуемые уровни identity

Для BilateralNavigator на текущем уровне публичной информации разумный default — Observed.

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

Например:

User-Agent: BilateralNavigator-PageFetch/1.0

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

Такой профиль не похож на обычное получение страниц для publishing/research проекта.

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

Security scanning
или
UA spoofing

независимо от заявленного имени.

Behavioural fingerprint

Соблюдает ли BilateralNavigator robots.txt

Сторонние crawler-каталоги предлагают правило robots.txt для этого User-Agent, но отдельного доступного первичного документа оператора с однозначной гарантией соблюдения robots.txt при проверке получить не удалось.

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

robots.txt token: usable
robots.txt compliance: Unverified

robots.txt для BilateralNavigator-PageFetch

Если владелец хочет объявить полный запрет:

User-agent: BilateralNavigator-PageFetch
Disallow: /

Частичное ограничение:

User-agent: BilateralNavigator-PageFetch
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /internal/
Disallow: /api/private/
Allow: /

После изменения нужно проверить access.log и увидеть, изменилось ли поведение crawler.

Почему лучше использовать полное имя User-Agent

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

User-agent: bilateralnavigator

Но наблюдаемое имя:

BilateralNavigator-PageFetch

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

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

if ($http_user_agent ~* "BilateralNavigator-PageFetch") {
    return 403;
}

Такое правило выполняет жёсткий запрет по заявленному UA.

Apache

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

Нужно ли блокировать BilateralNavigator по умолчанию

Я бы не использовал исходный:

Default: Deny

только потому, что crawler малоизвестен.

Более разумно:

Default: Monitor

а затем учитывать:

• реальную нагрузку;
• число страниц;
• периодичность;
• бизнес-пользу;
• поведение клиента.

Когда стоит оставить Monitor

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

• crawler получает небольшое количество публичных страниц;
• origin практически не нагружается;
• security-sensitive URL не запрашиваются;
• поведение стабильно;
• владельцу сайта не мешает такой автоматический доступ.

Когда использовать Rate Limit

Rate Limit разумен, если crawler выглядит легитимно, но:

• слишком часто повторяет URL;
• получает много динамических страниц;
• увеличивает CPU/DB нагрузку;
• создаёт заметный bandwidth.

Для неизвестного по инфраструктуре crawler лимит лучше применять по source IP или behavioural identity, а не объединять все источники с похожим UA в один глобальный bucket.

Когда Block оправдан

Block имеет смысл, если:

• автоматический сбор контента сайту не нужен;
• crawler создаёт измеримую нагрузку;
• получает слишком большую часть сайта;
• robots.txt не учитывается;
• поведение переходит в security scanning;
• UA используется для spoofing.

Нагрузка: смотрите не только hits

Для BilateralNavigator полезнее анализировать:

• Requests;
• Unique URLs;
• Unique IP;
• Unique ASN;
• RPS/RPM;
• Bandwidth;
• Average Response Size;
• Cache HIT Ratio;
• Origin Requests;
• TTFB.

Например:

10 000 requests
98% cache HIT
200 origin requests

могут быть дешевле, чем:

500 requests
0% cache HIT
500 тяжёлых dynamic renders

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

Точечная блокировка остановит клиентов, которые используют User-Agent BilateralNavigator-PageFetch.

Нет оснований считать BilateralNavigator частью Google Search, поэтому отдельный запрет этого UA не является запретом Googlebot или YandexBot.

Но точное влияние на функции самого Bilateral Navigator нельзя описывать слишком категорично: публичной технической документации crawler недостаточно, чтобы обещать конкретное последствие вроде потери цитирования или исключения из определённого индекса.

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

Его HTTP-запросы являются автоматизированным трафиком и не должны считаться обычными пользовательскими сессиями.

Для TrafficVeil:

Automated Traffic
→ Content & Research Crawlers
→ Publishing / Research
→ BilateralNavigator-PageFetch

Рекомендуется:

• исключать из Human Traffic;
• не считать конверсией;
• не считать автоматически malicious;
• учитывать отдельно в Bot Analytics;
• показывать Top URLs;
• показывать Identity Confidence;
• показывать Origin Impact.

С кем не путать BilateralNavigator

В исходнике соседями были просто другие «нежелательные» crawler. Это мало помогает пользователю.

Лучше сравнивать по назначению:

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

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

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

Вместо:

«BilateralNavigator — неизвестный нежелательный crawler. Рекомендуем запрет.»

лучше:

BilateralNavigator-PageFetch — автоматизированный fetcher проекта Bilateral Navigator, которым управляет Global Brain Power LLC. Он получает веб-страницы для задач проекта, но подробная crawler-policy и официальный IP-list публично не подтверждены. При небольшой нагрузке рекомендуем Monitor; если автоматический доступ не нужен или мешает origin — Rate Limit или Block.

Итог

BilateralNavigator-PageFetch нельзя считать полностью неизвестным crawler. Сам проект Bilateral Navigator официально принадлежит Global Brain Power LLC и занимается сравнительными международными публикациями.

Наблюдаемый User-Agent также достаточно конкретен:

BilateralNavigator-PageFetch/1.0 (+https://bilateralnavigator.com/bot)

Он фиксируется независимыми crawler-каталогами.

Однако отдельного официального IP-feed, подтверждённого rDNS-механизма и доступной crawler-policy, позволяющей присвоить высокий уровень technical verification, найти не удалось.

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

Content & Research Crawlers
→ Publishing / Research
→ BilateralNavigator-PageFetch

Operator: Global Brain Power LLC
Identity: Observed
Confidence: Medium
Default: Monitor

И главное — я бы убрал из исходника утверждения про академические и архивные очереди, пока оператор сам их не подтвердит. Здесь лучше опираться на то, что действительно известно: конкретный проект, конкретный оператор, наблюдаемый User-Agent и фактическое поведение в логах.