RecordedFuture Global Inventory Crawler: что это за бот и нужно ли его блокировать

RecordedFuture Global Inventory Crawler — наблюдаемый веб-краулер с User-Agent RecordedFuture Global Inventory Crawler. По названию он выглядит связанным с Recorded Future, известной платформой threat intelligence, однако при подготовке этой карточки не удалось найти официальную документацию Recorded Future, которая прямо описывала бы именно этот User-Agent и предоставляла способ его технической верификации.

Поэтому для TrafficVeil правильнее разделять два факта: Recorded Future как компания и threat-intelligence платформа подтверждены, а принадлежность конкретного UA RecordedFuture Global Inventory Crawler этому оператору следует считать вероятной, но не Verified, пока нет первичного источника или официального механизма проверки.

Что такое Recorded Future

Recorded Future — платформа threat intelligence. Компания описывает свою Intelligence Platform как систему, которая объединяет и анализирует данные из большого количества внешних и внутренних источников для выявления и приоритизации киберугроз.

В публичном описании платформы Recorded Future говорится, что Intelligence Graph индексирует, организует и анализирует информацию более чем из миллиона источников, включая открытый веб, технические feeds и другие источники.

Это делает гипотезу о назначении Global Inventory Crawler для сбора публичной web-информации логичной, но само по себе описание платформы не является доказательством того, что каждый HTTP-клиент с соответствующим UA действительно принадлежит Recorded Future.

Что может собирать такой crawler

По названию Global Inventory Crawler и контексту threat-intelligence систем наиболее вероятен сценарий инвентаризации публично доступных web-ресурсов.

В таком сценарии автоматизация может получать:

• публичные HTML-страницы;
• HTTP-заголовки;
• редиректы;
• метаданные;
• доступные снаружи web endpoint;
• технические признаки публичного web-сервиса.

Однако конкретный набор собираемых данных для этого UA не стоит выдавать за официально подтверждённый без документации оператора.

Как найти RecordedFuture в access.log

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

Для точного UA:

grep -F "RecordedFuture Global Inventory Crawler" /var/log/nginx/access.log

Топ URL:

grep -F "RecordedFuture Global Inventory Crawler" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

Топ IP:

grep -F "RecordedFuture Global Inventory Crawler" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

Коды ответа:

grep -F "RecordedFuture Global Inventory Crawler" /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Почему одного User-Agent недостаточно

Строка User-Agent не подтверждает личность отправителя. Любой HTTP-клиент может представиться RecordedFuture Global Inventory Crawler.

Если официальный IP feed или DNS-механизм проверки отсутствует, TrafficVeil стоит использовать дополнительные сигналы:

• IP и ASN;
• network type;
• reverse DNS;
• TLS/HTTP fingerprint;
• частоту запросов;
• набор URL;
• стабильность инфраструктуры во времени;
• историю поведения.

Observed IP не означает официальный IP

Если TrafficVeil увидел этот UA с конкретного IP, адрес следует хранить как Observed IP, а не автоматически как официальный диапазон Recorded Future.

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

Здесь исходный черновик был слишком категоричным. Сторонние каталоги расходятся: некоторые ожидают соблюдение robots.txt, другие прямо отмечают compliance как неподтверждённый. Официальную страницу Recorded Future, которая однозначно связывает эту политику именно с RecordedFuture Global Inventory Crawler, при проверке найти не удалось.

Поэтому корректная формулировка для TrafficVeil: robots.txt compliance — не подтверждено первичным источником.

Как запретить crawler через robots.txt

Как декларативную политику можно использовать точное имя:

User-agent: RecordedFuture Global Inventory Crawler
Disallow: /

После изменения обязательно проверьте access.log. Если crawler продолжает обращаться к запрещённым URL, используйте серверное правило или TrafficVeil.

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

User-agent: RecordedFuture Global Inventory Crawler
Disallow: /account/
Disallow: /admin/
Disallow: /internal/
Disallow: /api/private/
Allow: /

robots.txt не является механизмом защиты секретной информации. Непубличные данные должны быть закрыты аутентификацией и серверными ACL независимо от поведения crawler.

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

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

Для минимизации ложных совпадений лучше использовать максимально точный паттерн UA.

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

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "RecordedFuture Global Inventory Crawler" [NC]
RewriteRule ^ - [F,L]

Как оценивать нагрузку

Несколько тысяч запросов сами по себе ещё не означают проблему. Важнее смотреть распределение активности:

• RPS/RPM;
• число уникальных URL;
• глубину обхода;
• response bytes;
• cache HIT/MISS;
• нагрузку на origin;
• долю 4xx/5xx;
• повторяемость запросов;
• число IP и ASN.

Если по внутренней сводке TrafficVeil наблюдалось около 2,6 тыс. запросов, эту цифру лучше показывать как собственную статистику TrafficVeil с периодом измерения, а не как глобальный объём активности crawler.

Стоит ли блокировать RecordedFuture Global Inventory Crawler

Универсального ответа нет. Поскольку это не поисковый crawler, его блокировка не должна напрямую влиять на индексирование Google или Яндекса.

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

Запросы такого типа не являются человеческими посещениями. В TrafficVeil их логично относить к:

Automated traffic → Threat Intelligence / Web Inventory.

Их следует исключать из human visits и конверсий, но сохранять в bot/service analytics.

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

Итог

RecordedFuture Global Inventory Crawler — наблюдаемый автоматизированный клиент, название которого указывает на связь с Recorded Future и задачами глобальной web-инвентаризации. Такая функция хорошо согласуется с профилем Recorded Future как threat-intelligence платформы, однако техническую принадлежность конкретного UA лучше не считать полностью Verified без официального IP feed, DNS verification или первичной документации.

Для TrafficVeil оптимальная базовая политика — Monitor. Если доступ не нужен, crawler можно ограничить через robots.txt и при необходимости принудительно заблокировать на reverse proxy. Если он полезен, Allow лучше выдавать после дополнительной проверки инфраструктуры и поведения.