ЯНВАРЬ. Инвентаризация внешнего периметра: как найти забытые сервисы раньше атакующего

Самая опасная система часто не та, которую никто не защищает, а та, про которую никто не помнит. Старый VPN, тестовый веб-сервис, временный сервер подрядчика, забытый NAT, панель администрирования на нестандартном порту — всё это продолжает существовать после того, как проект закрыт, сотрудник уволен, а документация перестала обновляться. Для атакующего такой актив ничем не отличается от основного: если он доступен из интернета, его можно обнаружить, просканировать и попытаться использовать.

 

Почему начинать нужно не со сканера уязвимостей

Сканер уязвимостей отвечает на вопрос, что известно о конкретном найденном узле. Но сначала нужно ответить на более простой вопрос: какие публичные узлы у компании вообще есть. Инвентаризация должна объединять DNS, публичные IP, NAT, VPN, облачные адреса, внешние панели, почтовые шлюзы, API, временные среды и сервисы подрядчиков. Полезный результат — не список IP, а реестр, где у каждого актива есть владелец, назначение, версия, дата последнего изменения и понятный жизненный цикл.

 

Что проверить за 30 минут

Возьмите не всю компанию, а один внешний диапазон или один домен. Сопоставьте DNS-записи и публичные IP с правилами NAT, облачными адресами и известными внешними сервисами. Для каждого найденного сервиса зафиксируйте владельца и версию. Отдельно отметьте системы в EOL/EOS и все узлы, по которым владелец не определяется за несколько минут. Такие записи и есть главный результат проверки: они показывают не техническую уязвимость, а разрыв ответственности.

 

Проверка пройдена, если

У каждого публичного сервиса есть понятный владелец, назначение, актуальная версия и статус поддержки. Для EOL/EOS есть план вывода, изоляции или замены. Нет публичных узлов, которые невозможно связать с бизнес-задачей и ответственным. Реестр проверяется не раз в год перед аудитом, а после существенных изменений инфраструктуры.

  

Что показали расследования

В отчёте Cisco Talos Incident Response за Q2 2026 уязвимая, непропатченная или неподдерживаемая внешняя инфраструктура была одной из наиболее частых слабостей (31%). Talos рекомендует приоритизировать патчинг или вывод из эксплуатации EOL и внешне доступных систем, ограничивать плоскость управления и удалённый доступ, а также поддерживать процесс, который быстро выявляет публичные активы и их состояние.

 

Типичная ошибка

Считать CMDB или сетевую схему источником истины. Они полезны, но реальный периметр формируется из того, что действительно доступно снаружи. Поэтому реестр нужно периодически сверять с DNS, IPAM, облаком, правилами публикации и фактической внешней видимостью.

 

Как это связано с решениями Смарт-Софт

Traffic Inspector Next Generation (TING) может стать одним из элементов архитектуры периметра и источником сетевой информации о том, какие сервисы действительно доступны извне. Но сам по себе он не заменяет процесс инвентаризации. Публичный сервис должен быть известен, управляем и поддерживаться — это принцип, который работает независимо от выбранного решения вендора.

 

Что сделать сегодня

• Сверить один внешний домен или диапазон с DNS, NAT и облачными адресами.
• Назначить владельца каждому неизвестному сервису.
• Отдельно пометить EOL/EOS и сервисы без плана замены.

 

Источники

• Cisco Talos Incident Response. IR Trends Q2 2026: Phishing and weaponized remote management tools drive attack chains. 28.07.2026.
• Smart-Soft. Traffic Inspector Next Generation — официальная документация и описание архитектурных вариантов.

 

Последняя техническая проверка: 14.10.2026.