От фичи к продукту: как мы хотели развязать себе руки, а открыли глаза заказчикам

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

Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией MULTISTATUS — сервиса геораспределённого мониторинга доступности веб-ресурсов. В результате появился инструмент, который сначала помогал демонстрировать продукт заказчикам, а затем оказался полезен и для задач информационной безопасности. Рассказываем, как это произошло и как в этом помогла бот-ферма одного из разработчиков.

При чем тут MULTISTATUS

MULTISTATUS — это сервис геораспределённого мониторинга доступности веб-ресурсов. 

Он проверяет доступность инфраструктуры извне — из 15+ локаций в России, Беларуси и Казахстане — так, как её видят реальные пользователи, а не внутренний Zabbix через NAT. В одном окне доступны семь типов проверок: HTTP, Ping, SSL, DNS, Port Scan, Traceroute и WHOIS. Оповещения отправляются в Telegram, MAX, на почту, через webhook или голосовым звонком. Метрики экспортируются в Prometheus, события — в Zabbix. SLA рассчитывается автоматически, а публичный статус-пейдж можно развернуть за минуту.

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

Когда хорошего продукта недостаточно

Во время одной из встреч с отделом продаж всплыла проблема, которая регулярно возникала при подготовке к демонстрациям. Перед тем как показывать сервис, важно понимать масштаб инфраструктуры заказчика: сколько у него доменов, IP-адресов, открытых сервисов, SSL-сертификатов и других внешних ресурсов. Без этой информации сложно предложить подходящий сценарий использования продукта, подобрать тариф и сделать разговор предметным.

На первый взгляд это выглядело как чисто операционная задача, но именно она регулярно замедляла переход от первого контакта к пилотному проекту.

Проблема первого разговора с заказчиком

В большинстве случаев потенциальный заказчик не может быстро оценить собственный внешний периметр. Информация о доменах, IP-адресах, сертификатах и внешних сервисах часто распределена между разными подразделениями, поэтому собрать её к первой встрече бывает непросто.

Конечно, существуют инструменты для разведки и инвентаризации внешнего периметра — Shodan, Censys и различные OSINT-фреймворки. Но большинство из них требуют технической подготовки или ориентированы на специалистов по информационной безопасности, а не на использование во время встречи с заказчиком. Ни один из них не позволяет за полминуты, прямо в браузере, без установки и регистрации получить общую картину внешнего периметра и сразу поставить найденные ресурсы на мониторинг.

Реализация: от идеи до прототипа

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

Неожиданно решение нашлось внутри команды. У одного из DevOps-инженеров уже была собственная бот-ферма на базе Qwen, собранная из бывшей майнинг-фермы. Именно ей и поручили разработку первого прототипа.

Здесь стоит сделать небольшое отступление. Если основная команда занята, это не всегда означает, что задачу нужно откладывать. Иногда её можно решить параллельно, используя уже имеющиеся инструменты и экспертизу. В нашем случае именно такой подход позволил не отвлекать разработчиков от основного продукта и при этом быстро проверить новую идею.

Подход оказался неожиданно эффективным. В качестве локального движка использовали Ollama, а в роли рабочих моделей — qwen3.5:27b и qwen3-coder:30b. Дальше начиналось самое интересное: агенты писали код, коммитили изменения в GitLab, запускали пайплайны, а QA-агент проверял результат и отправлял его на доработку при необходимости. Со стороны это выглядело непривычно, но на практике заметно ускоряло итерации. Инженер при этом не исчезал из процесса — он задавал архитектуру, контролировал качество и принимал финальные изменения.

В результате первый рабочий прототип был подготовлен примерно за три дня, вместо предполагаемых нескольких недель.

После этого были внесены дополнительные доработки: настройка глубины обхода URL, интеграция источников поиска поддоменов через OSINT-базы, использование Certificate Transparency Logs и DNS Bruteforce-механизмов.

Получившийся инструмент позволял по доменному имени собрать информацию о поддоменах, IP-адресах, открытых портах и SSL-сертификатах через обычный веб-интерфейс.

О всех фичах этого инструмента можно говорить очень много, поэтому отдельно хотелось бы описать подробности поиска поддоменов, о чем нас часто спрашивают на созвонах с заказчиками.

Система обнаруживает субдомены целевого домена в два этапа:

1. Пассивный сбор — запрашивает известные публичные источники (OSINT).

2. Активный перебор (опционально) — проверяет распространённые и сгенерированные имена методом DNS-запросов.

Результаты двух этапов объединяются, очищаются от дубликатов и возвращаются пользователю.

Пассивный сбор (OSINT)

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

Источники данных

На основе анализа логов воркеров в проекте используются только стабильно работающие источники:

Ранее использовались дополнительные источники (VirusTotal, BufferOver, AlienVault OTX, ThreatCrowd, Anubis, SubdomainCenter), но они показали себя нестабильными — возвращали ошибки или пустые ответы, поэтому мы от них отказались.

Принцип работы

1. Каждый источник опрашивается параллельно (одновременно).

2. На выполнение всех запросов отводится не более 120 секунд.

3. Полученные данные нормализуются: удаляются протоколы (http://, https://), порты, пути, wildcard (*.), дубликаты.

4. Проверяется, что найденное имя действительно оканчивается на искомый домен.

5. Результат сохраняется во внутренний кэш на время работы сканирования, чтобы повторные запросы к тем же источникам не тратили время.

Активный перебор (DNS Brute-force)

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

• Годы и версии — 2024, 2025, v1, v2 …

• Окружения — dev, staging, prod, test, qa, beta, demo …

• Регионы — us, eu, asia, uk, de, apac, us-east, lon, fra …

• Сервисы — api, mail, cdn, blog, shop, auth, db, jenkins, grafana …

• Инфраструктура — admin, vpn, proxy, bastion, gateway, node, worker …

• Частые префиксы — my, get, try, new, app, go …

Система также содержит стартовый набор из ~80 самых распространённых субдоменов (www, mail, ftp, api, dev и т.д.), которые проверяются в первую очередь.

Процесс перебора

1. Создаётся полный список кандидатов (словарь + пермутации).

2. Для каждого кандидата отправляется DNS-запрос типа A («какой IP у этого имени?»).

3. Проверка выполняется параллельно с настраиваемым уровнем конкурентности.

4. На выполнение brute-force отводится не более 5 минут.

5. Если имя успешно разрешается — оно попадает в результаты.

6. Все промежуточные результаты кэшируются: если один и тот же субдомен проверяется повторно в рамках сканирования, DNS-запрос не отправляется снова.

Аггрегация OSINT и DNS brute-force выглядит так:

• Субдомены из пассивных источников и активного перебора собираются в единый пул.

• Удаляются полные дубликаты.

• Каждое имя проверяется на корректность: допустимы только буквы, цифры, точки и дефисы.

• Дедупликация IP-адресов: если несколько субдоменов разрешаются в один и тот же IP, система создаёт задачу сканирования портов только один раз для этого IP.

• Дедупликация портов: при сохранении результатов сканирования портов дубликаты исключаются на уровне обработки и базы данных (ON CONFLICT по scan_id + ip_address + port).

• Итоговый список передаётся дальше — к сканированию портов, SSL-сертификатов, WHOIS и другим модулям

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

Демонстрация, которая изменила восприятие инструмента

Сканирование чекером запустили прямо во время встречи с заказчиком. Ввели доменное имя, нажали кнопку и начали вместе смотреть на результаты.

Уже через несколько секунд стало понятно, что демонстрация получилась убедительной. Инструмент обнаружил открытый в интернет порт 27017 (MongoDB), а также несколько поддоменов, которые заказчик явно не планировал делать публичными. И всё это без доступа к инфраструктуре, только по имени домена.

Реакция оказалась показательной: сначала тревога, а потом искреннее «Подождите, а откуда вы это знаете?». Для нас это стало лучшей обратной связью. Когда инструмент находит реальные проблемы, о существовании которых заказчик не подозревал или давно откладывал их решение, значит, этот инструмент закрывает не выдуманный сценарий, а настоящую практическую задачу.

От вспомогательного сервиса к отдельному компоненту платформы

Следующим шагом стало развитие чекера в двух направлениях.

Первая — микросервис для сканирования сетевого периметра. Независимый компонент со своей логикой обнаружения: поддомены, открытые порты, IP-адреса, SSL-сертификаты, WHOIS. Его задача — быстро и максимально полно находить ресурсы без лишних действий со стороны пользователя.

Вторая — интеграция с ядром сервиса MULTISTATUS. Найденные ресурсы не просто отображаются в интерфейсе, они автоматически попадают в очередь на постановку на мониторинг. Пользователь выбирает, какие из них добавить — все или только часть. Затем API обрабатывает очередь и создаёт ресурсы в MULTISTATUS в нужном порядке, а шина данных обеспечивает надёжную передачу между сервисами без потерь.

В результате путь от обнаружения ресурса до его постановки на мониторинг сократился до одного клика.

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

Что дальше?

После выделения решения в отдельный микросервис стало понятнее направление дальнейшей эволюции.

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

Следующий логичный этап — автоматизированное выявление известных уязвимостей на внешних ресурсах с использованием подходов, применяемых в ASV- и OWASP-практиках.

Параллельно развивается направление внутренних агентов мониторинга. Такой агент позволяет собирать данные о загрузке серверов, использовании памяти и состоянии приложений, объединяя внутренний и внешний контуры наблюдения в единой системе.

Ещё одна задача — автоматизация расследования инцидентов. Вместо простого уведомления о недоступности сервис сможет самостоятельно запускать дополнительные проверки и помогать локализовать источник проблемы.

Фактически развитие идёт от классического мониторинга доступности к платформе наблюдаемости, которая объединяет эксплуатационные и безопасностные сценарии.

Вместо эпилога

История этого инструмента началась с довольно простого запроса отдела продаж. Команде требовался способ быстрее понимать масштаб инфраструктуры потенциального заказчика и сокращать время до запуска пилотного проекта.

В результате появился сервис, который сначала использовался как внутренний инструмент подготовки к встречам, а затем оказался полезным для задач информационной безопасности и автоматизации мониторинга.

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