Эта история началась не с продуктовой сессии, не с исследования рынка и даже не с запроса заказчиков. Отправной точкой стала встреча с коммерческой командой.
Коллеги из отдела продаж искали способ быстрее оценивать внешний периметр потенциальных заказчиков перед демонстрацией 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-сертификатах через обычный веб-интерфейс.
О всех фичах этого инструмента можно говорить очень много, поэтому отдельно хотелось бы описать подробности поиска поддоменов, о чем нас часто спрашивают на созвонах с заказчиками.
Система обнаруживает субдомены целевого домена в два этапа:
Пассивный сбор — запрашивает известные публичные источники (OSINT).
Активный перебор (опционально) — проверяет распространённые и сгенерированные имена методом DNS-запросов.
Результаты двух этапов объединяются, очищаются от дубликатов и возвращаются пользователю.
Пассивный сбор (OSINT)
Вместо того чтобы «стучаться» напрямую в инфраструктуру заказчика, система собирает уже проиндексированные данные из открытых источников. Это быстро, незаметно для цели и не создаёт лишней нагрузки.
Источники данных
На основе анализа логов воркеров в проекте используются только стабильно работающие источники:
Источник | Что даёт |
Сертификаты TLS/SSL, выпущенные для домена и его субдоменов. Каждый сертификат содержит список имён (SAN), среди которых часто встречаются непубличные субдомены. | |
RapidDNS | База пассивного DNS: исторические записи о том, какие имена разрешались в IP-адреса. |
HackerTarget | Публичный API для поиска хостов, связанных с доменом. |
Wayback Machine | Архив веб-страниц. Из миллионов сохранённых URL-адресов извлекаются все встречавшиеся субдомены. |
CertSpotter | Источник сертификатов прозрачности (Certificate Transparency). Дополняет crt.sh. |
DNSDumpster | Сервис для пассивного обнаружения хостов и DNS-записей. |
Chaos (ProjectDiscovery) | База субдоменов, собранная из множества публичных источников. |
Публичный сервис сканирования URL. Из результатов поиска по домену извлекаются связанные хосты. |
Ранее использовались дополнительные источники (VirusTotal, BufferOver, AlienVault OTX, ThreatCrowd, Anubis, SubdomainCenter), но они показали себя нестабильными — возвращали ошибки или пустые ответы, поэтому мы от них отказались.
Принцип работы
Каждый источник опрашивается параллельно (одновременно).
На выполнение всех запросов отводится не более 120 секунд.
Полученные данные нормализуются: удаляются протоколы (http://, https://), порты, пути, wildcard (*.), дубликаты.
Проверяется, что найденное имя действительно оканчивается на искомый домен.
Результат сохраняется во внутренний кэш на время работы сканирования, чтобы повторные запросы к тем же источникам не тратили время.
Активный перебор (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 и т.д.), которые проверяются в первую очередь.
Процесс перебора
Создаётся полный список кандидатов (словарь + пермутации).
Для каждого кандидата отправляется DNS-запрос типа A («какой IP у этого имени?»).
Проверка выполняется параллельно с настраиваемым уровнем конкурентности.
На выполнение brute-force отводится не более 5 минут.
Если имя успешно разрешается — оно попадает в результаты.
Все промежуточные результаты кэшируются: если один и тот же субдомен проверяется повторно в рамках сканирования, DNS-запрос не отправляется снова.
Аггрегация OSINT и DNS brute-force выглядит так:
Субдомены из пассивных источников и активного перебора собираются в единый пул.
Удаляются полные дубликаты.
Каждое имя проверяется на корректность: допустимы только буквы, цифры, точки и дефисы.
Дедупликация IP-адресов: если несколько субдоменов разрешаются в один и тот же IP, система создаёт задачу сканирования портов только один раз для этого IP.
Дедупликация портов: при сохранении результатов сканирования портов дубликаты исключаются на уровне обработки и базы данных (O
N CONFLICTпоscan_id + ip_address + port).Итоговый список передаётся дальше — к сканированию портов, SSL-сертификатов, WHOIS и другим модулям
Первоначально сервис создавался исключительно для внутреннего использования и должен был помогать готовиться к встречам с потенциальными заказчиками, но дальнейшая практика показала, что область его применения значительно шире.
Демонстрация, которая изменила восприятие инструмента
Сканирование чекером запустили прямо во время встречи с заказчиком. Ввели доменное имя, нажали кнопку и начали вместе смотреть на результаты.
Уже через несколько секунд стало понятно, что демонстрация получилась убедительной. Инструмент обнаружил открытый в интернет порт 27017 (MongoDB), а также несколько поддоменов, которые заказчик явно не планировал делать публичными. И всё это без доступа к инфраструктуре, только по имени домена.
Реакция оказалась показательной: сначала тревога, а потом искреннее «Подождите, а откуда вы это знаете?». Для нас это стало лучшей обратной связью. Когда инструмент находит реальные проблемы, о существовании которых заказчик не подозревал или давно откладывал их решение, значит, этот инструмент закрывает не выдуманный сценарий, а настоящую практическую задачу.
От вспомогательного сервиса к отдельному компоненту платформы
Следующим шагом стало развитие чекера в двух направлениях.
Первая — микросервис для сканирования сетевого периметра. Независимый компонент со своей логикой обнаружения: поддомены, открытые порты, IP-адреса, SSL-сертификаты, WHOIS. Его задача — быстро и максимально полно находить ресурсы без лишних действий со стороны пользователя.
Вторая — интеграция с ядром сервиса MULTISTATUS. Найденные ресурсы не просто отображаются в интерфейсе, они автоматически попадают в очередь на постановку на мониторинг. Пользователь выбирает, какие из них добавить — все или только часть. Затем API обрабатывает очередь и создаёт ресурсы в MULTISTATUS в нужном порядке, а шина данных обеспечивает надёжную передачу между сервисами без потерь.
В результате путь от обнаружения ресурса до его постановки на мониторинг сократился до одного клика.
Но одного чекера для удобной работы недостаточно. Найти ресурсы — лишь половина задачи. Для каждого добавленного объекта система автоматически создаёт базовые правила оповещений и разворачивает готовый дашборд с необходимыми виджетами. Пользователю не нужно настраивать мониторинг с нуля: сразу после добавления он видит актуальное состояние ресурса и начинает получать уведомления, если возникают проблемы,
Что дальше?
После выделения решения в отдельный микросервис стало понятнее направление дальнейшей эволюции.
Одним из перспективных сценариев является постоянный мониторинг внешнего периметра. Пользователь может определить список разрешённых IP-адресов и сервисов, а система будет отслеживать любые изменения: появление новых открытых портов, закрытие существующих сервисов или изменение конфигурации.
Следующий логичный этап — автоматизированное выявление известных уязвимостей на внешних ресурсах с использованием подходов, применяемых в ASV- и OWASP-практиках.
Параллельно развивается направление внутренних агентов мониторинга. Такой агент позволяет собирать данные о загрузке серверов, использовании памяти и состоянии приложений, объединяя внутренний и внешний контуры наблюдения в единой системе.
Ещё одна задача — автоматизация расследования инцидентов. Вместо простого уведомления о недоступности сервис сможет самостоятельно запускать дополнительные проверки и помогать локализовать источник проблемы.
Фактически развитие идёт от классического мониторинга доступности к платформе наблюдаемости, которая объединяет эксплуатационные и безопасностные сценарии.
Вместо эпилога
История этого инструмента началась с довольно простого запроса отдела продаж. Команде требовался способ быстрее понимать масштаб инфраструктуры потенциального заказчика и сокращать время до запуска пилотного проекта.
В результате появился сервис, который сначала использовался как внутренний инструмент подготовки к встречам, а затем оказался полезным для задач информационной безопасности и автоматизации мониторинга.
Как показала практика, иногда достаточно внимательно посмотреть на проблемы коллег, которые ежедневно взаимодействуют с заказчиками. Именно такие задачи нередко становятся источником наиболее неожиданных направлений развития продукта.
