Разбор конкурента по открытым источникам: что видно снаружи

Основной сбор запускается одной командой

Скрипт 01-recon.sh получает на вход домен и за один заход проходит WHOIS, DNS, разбор сертификата, историческую выборку из журналов прозрачности сертификатов (открытых записей обо всех выпущенных сертификатах), публичные сканы, пассивный DNS и веб-архив. Каждый шаг сохраняется в рабочую папку отдельным файлом. К такому файлу можно вернуться, приложить его к выводу и сравнить с повторным прогоном того же домена через месяц. Результат, который остался только в терминале, через неделю уже не проверить.

Саму страницу открывает отдельный скрипт

Первый скрипт саму страницу не открывает: WHOIS, DNS и архивы он берёт из сторонних источников, а сертификат читает без загрузки страницы. Открытие страницы — единственный шаг, который оставляет след в чужой аналитике. Поэтому он вынесен в отдельный файл 02-live-click.sh и запускается только по отдельному решению. Он снимает то, ради чего разбор и затевался:

• условия и цена на дату разбора: с ними сравнивают ваше предложение
• формы для заявок: сколько полей, какие обязательные, что обещают после отправки
• внешние сервисы, которые загружает страница: аналитика, чат, приём платежей, CDN
• Set-Cookie и заголовки ответа: по ним движок сайта узнаётся точнее, чем по содержимому страницы

Страница сохраняется целиком, вместе с ценами на дату разбора. Если кто-то скажет «весной у них было дешевле», спор решат два сохранённых файла с датами.

Технологии узнаются по отпечаткам

Сайт нигде не сообщает, на чём он собран. Но каждая платформа оставляет отпечаток, и его сложнее подделать, чем надпись на странице. Справочник tracker-signatures.md — это таблица «признак → платформа», которая пополняется на каждом разборе:

• служебный заголовок ответа, который бывает только у одной платформы: самый сильный признак, платформа узнаётся сразу
• вид имени cookie и его структура: по ним видно и движок сайта, и подключённую аналитику
• пути к статике и имена файлов сборки: по ним видно фреймворк и то, чем собран интерфейс сайта
• внешние домены, которые загружает страница: CDN, аналитика, чат, приём платежей
• имена в DNS облачного провайдера: по ним видно, где и на чём размещён сайт

Код интерфейса тоже рассказывает о продукте

Отдельный шаг — чтение собранных файлов JS и CSS. Служебные адреса показывают, какие интеграции подключены. Версии библиотек говорят, насколько свежий код и как часто его обновляют. Названия внутренних сущностей подсказывают, как устроены данные. Шаг недорогой, а рассказывает он много.

Правила выводов записаны отдельно

За одним сайтом стоит несколько независимых участников: хостинг, CDN, конструктор или система управления сайтом, подключённые сторонние сервисы. Каждый из них обслуживает десятки не связанных между собой клиентов. Поэтому в attribution-rules.md признаки разделены на два списка: те, что действительно что-то доказывают, и те, что встречаются у всех подряд. Вывод делается по уникальному признаку.

Только бесплатные источники, и это осознанный выбор

Весь сбор строится на том, что доступно любому: whois-сервер регистратуры, публичные DNS-серверы, журналы прозрачности сертификатов, публичные сканы страниц, пассивный DNS и веб-архив. Это ограничение полезно и для самой методики: каждый признак можно перепроверить независимо.

Самый ценный результат — пойманная собственная ошибка

На третьем разборе вывод сначала был неверным. Два разных сайта пользовались одним и тем же сторонним сервисом, и это выглядело как доказательство, что за ними один продукт. Признак был заметный, повторялся при каждой проверке и оказался ложным. Ошибка вскрылась на следующем шаге: в заголовках ответа нашёлся признак платформы, и у второго сайта он оказался другим. Общим был только сторонний сервис, которым пользуются десятки не связанных между собой компаний.

Правило, которое из этого выросло

Общие инструменты не доказывают общей команды. Эта формулировка попала в attribution-rules.md вместе со списком признаков, которые выглядят убедительно и ничего не доказывают:

• общие адреса популярного CDN (anycast): один набор адресов на всех клиентов тарифа
• самый массовый регистратор и его стандартная услуга скрытия данных владельца: это говорит только о популярности регистратора
• общий сторонний виджет — чат, форма, аналитика: их ставят десятки не связанных между собой компаний
• типовой шаблон посадочной страницы и стандартный набор cookie популярного фреймворка

Итоговый порядок короткий: найти уникальный признак, узнать по нему платформу, подтвердить вторым независимым признаком и только тогда что-то утверждать. Совпадение по общей инфраструктуре входит в вывод только как дополнительный довод.

Что осталось после трёх разборов

Остался репозиторий с пошаговой инструкцией, двумя скриптами и двумя справочниками, которые растут с каждым новым разбором. К ним добавился список обязательных полей, без которых вывод не считается готовым: что за продукт, на чём собран сайт, какие сервисы подключены, чем подтверждён каждый пункт. Этот список нужен для того же, что и правила: чтобы уверенность аналитика не подменяла доказательство.