Какие внешние сервисы чаще становятся точкой входа
Теневые активы редко появляются как результат большого архитектурного решения. Чаще это тестовый стенд, демоокружение для пилота, временно опубликованный API, облачная VM с открытым SSH или RDP, файловый портал для партнеров, забытый поддомен или административный интерфейс, который должен был быть доступен только изнутри, и другое. Для владельцев инфраструктуры это может быть «временная техническая деталь», для атакующего — такая же точка входа, как любой актив в продуктивной среде.
Однако опасен не сам факт наличия VPN, SSH, OWA, сервиса обмена файлами или административного интерфейса веб‑приложения. Такие сервисы часто нужны бизнесу для удаленной работы, сопровождения инфраструктуры, обмена файлами, поддержки клиентов и интеграций с партнерами. Риск возникает, когда к ним вовремя не применяют принятые в компании политики безопасности.
Поэтому для CISO важно оценивать каждый внешний сервис по двум вопросам: «что он дает атакующему?» и «зачем он нужен бизнесу на периметре?» Главное в проверке внешнего периметра — это не количество закрытых портов, а время между фактическим появлением нового сервиса и его обнаружением командой защиты.
Также, чтобы эффективно управлять внешней поверхностью атаки, CISO важно понимать:
- как на внешнем периметре появляются теневые активы и почему даже легитимный сервис может стать точкой входа для злоумышленника;
- какие категории сервисов представляют наибольший риск;
- как держать внешний периметр под контролем.
Внешний периметр меняется быстрее, чем его обычно успевают описывать в CMDB. У компании может появиться ресурс, который формально никому не принадлежит, но виден из интернета так же хорошо, как актив в продуктивной среде. Такие теневые активы редко становятся результатом одного крупного нарушения. Гораздо чаще они появляются в ходе обычной работы: после пилотных проектов, временных интеграций, миграций или процессов, которые не довели до конца.
Например, тестовый стенд продолжает отвечать из интернета после завершения пилота. Для интеграции с подрядчиком временно добавляют правила фаервола или сетевого доступа в облаке, а потом забывают удалить. В облаке разворачивают виртуальную машину с открытым SSH или RDP. Команда разработки публикует API, административный интерфейс или файловый сервис для проверки гипотезы, но не передает его в эксплуатацию и не встраивает в процессы кибербезопасности. Старый поддомен после миграции по‑прежнему ведет на рабочий бэкенд, стейджинг‑среду или легаси‑приложение.
В каждом из этих сценариев бизнес‑задача уже может быть решена, а опубликованный ресурс продолжает оставаться частью внешнего периметра и увеличивает поверхность атаки.
Даже если сегодня сервис настроен корректно, завтра ситуация может измениться. Например, свежая уязвимость способна повысить риск его компрометации. Так, CVE‑2025‑20352 в SNMP-подсистеме Cisco IOS и IOS XE позволяла атакующему с доступом к SNMP вызвать отказ в обслуживании, а при наличии дополнительных административных привилегий на IOS XE — выполнить произвольный код с правами root.
Из этого следует: недостаточно только отслеживать уязвимости — нужно контролировать само появление новых внешних точек доступа на периметре. Это позволит уменьшать поверхность атаки и не тратить время на срочный патчинг лишних систем.
Не все опубликованные сервисы одинаково опасны. Их можно условно разделить на три категории в зависимости от того, какие возможности они дают атакующему и к каким последствиям может привести их компрометация:
- Открывающие вход во внутреннюю сеть.
- Концентрирующие данные.
- Позволяющие управлять инфраструктурой.
К этой группе относятся VPN, RDP, VNC, SSH и панели удаленного администрирования. Сами по себе они не опасны: бизнесу нужен удаленный доступ для сотрудников и подрядчиков, а администраторам — инструменты для сопровождения инфраструктуры. Риск возникает, когда такие сервисы оказываются доступны из интернета без строгого ограничения источников, MFA, контроля сессий, назначенного владельца и SLA на критичные обновления.
Шлюзы VPN и SSL VPN — это фактически легитимная дверь во внутреннюю сеть. Атакующему не обязательно «ломать VPN» в широком смысле. Иногда достаточно украденной учетной записи, перехваченной сессии или уязвимости в самом шлюзе. После успешного входа злоумышленник может перейти к разведке инфраструктуры и поиску следующих целей.
Показательный пример — CVE‑2025‑20333, уязвимость в VPN‑веб‑сервере решений Cisco Secure Firewall ASA и FTD. Она могла позволить удаленному аутентифицированному атакующему выполнить код на устройстве и поставить под угрозу все пользовательские сессии. Своевременный патчинг и MFA могли снизить риски компаний, тогда как наличие неучтенных сервисов VPN на периметре увеличивало вероятность успешной атаки.
RDP и VNC создают еще более прямой путь к инфраструктуре: они открывают не шлюз, а конкретную рабочую станцию или сервер. Если такой сервис доступен из интернета, компрометация одной учетной записи может сразу дать интерактивный доступ к системе. После этого злоумышленник может выгрузить учетные данные и продолжить атаку, уже закрепившись на хосте.
| Сервис | Основной риск |
|---|---|
| VPN |
Штатный маршрут во внутреннюю сеть |
| RDP/VNC/SSH |
Интерактивный доступ к хосту |
| Панели удаленного администрирования |
Управление системами с повышенными привилегиями |
Сервисы с большим объемом данных опасны тем, что атакующему не нужно долго перемещаться по сети в поисках ценной информации. Успешная компрометация сразу ведет к утечке, шантажу, остановке бизнес‑процесса или регуляторным последствиям.
К этой категории активов относятся:
- Почтовые приложения. Они содержат переписку, внутренние обсуждения и договоренности, вложения, контакты и другие данные, отражающие бизнес‑процессы компании. В on‑prem‑версиях Microsoft Exchange риск повышается из‑за тесной связи почты с доменной инфраструктурой. Публичные атаки на MS Exchange показали, что такой сервер на периметре — это критичный актив, компрометация которого может привести не только к утечке данных, но и к дальнейшему развитию атаки внутри сети.
- Файлообменники. Seafile, MOVEit, FTP‑/SFTP‑серверы и похожие системы создавались для передачи важных документов, поэтому в них концентрируются договоры, персональные данные, финансовые отчеты, клиентские выгрузки и архивы.
- Базы данных, поисковые и кеширующие системы. MongoDB, Redis, Elasticsearch, PostgreSQL и MySQL редко должны быть доступны из интернета напрямую. На внешнем периметре они чаще появляются из‑за тестовых стендов, временных правил межсетевых экранов или забытых dev‑сред. Последствия компрометации обычно прямые — выгрузка данных. При этом утечка клиентской базы или пользовательских учетных сведений может привести к серьезному ущербу для бизнеса.
| Сервис | Основной риск |
|---|---|
| Почтовые сервисы (OWA, Roundcube) |
Доступ к почтовой переписке |
| Файлообменники |
Доступ к конфиденциальным файлам |
| Базы данных, поисковые и кеширующие системы |
Доступ к продуктивным данным |
Сервисы управления инфраструктурой опасны техническими возможностями, которые открываются при их компрометации. Через один такой внешний интерфейс можно менять сетевые политики, настройки маршрутизации и VPN, параметры контейнеров. Поэтому любой подобный сервис на внешнем периметре нужно рассматривать не как вспомогательный инструмент, а как потенциальную точку контроля над частью инфраструктуры.
Сетевые устройства особенно сложны для защиты. На межсетевой экран, балансировщик или маршрутизатор часто невозможно установить привычные средства защиты, а событий безопасности там меньше, чем в пользовательских системах. При этом изменение конфигурации может выглядеть как обычная работа администратора. В результате компрометация такого узла может дольше оставаться незаметной и привести к перехвату или перенаправлению трафика, отключению журналирования и обходу политик безопасности.
Похожий риск возникает в контуре разработки и эксплуатации, но уже на уровне цепочки поставки ПО. Открытые Kubernetes API, Docker API, административные панели Jenkins и GitLab могут дать доступ к цепочкам сборки, секретам, контейнерам и ключам доступа в облаке. В таком случае компрометация одного сервиса превращается из локального инцидента в риск выпуска вредоносного компонента от имени компании или захвата облачной инфраструктуры.
| Сервис | Основной риск |
|---|---|
| Административные интерфейсы маршрутизаторов и межсетевых экранов |
Может раскрывать топологию, версии ПО, интерфейсы и состояние устройств. При наличии write‑доступа позволяет менять отдельные параметры |
| Kubernetes API и Docker API |
Могут дать доступ к контейнерам, служебным учетным записям, учетным данным реестров образов, переменным окружения и секретам |
| Административные и CI/CD‑панели Jenkins, GitLab |
Позволяют управлять сборками, артефактами, ключами развертывания и секретами разработки |
Задача CISO — не запретить все внешние сервисы, а сделать их управляемыми. Каждый из них должен проходить понятный цикл: обнаружение → определение владельца → обоснование необходимости → ограничение или вывод с периметра.
Практический порядок действий:
- Быстро ответить на вопрос: «Что доступно извне прямо сейчас?» При любой необходимости команда должна за часы, а не за дни, понять, какие сервисы присутствуют на внешнем периметре.
- Убрать с периметра все сервисы без явного бизнес‑обоснования. Для VPN, RDP, SSH, OWA, MFT, DevOps‑панелей, баз данных и административных интерфейсов должны быть определены владелец, причина внешней доступности, ограничения доступа, требования к MFA, дата пересмотра и допустимый срок устранения риска.
- Приоритизировать риски по последствиям, а не только по критичности CVE. В первую очередь внимания требуют сервисы, которые дают доступ во внутреннюю сеть, к чувствительным данным или позволяют управлять инфраструктурой. Дополнительный приоритет получают уязвимости с доступным эксплоитом или подтвержденными случаями эксплуатации, о которых удалось узнать командам киберразведки, например BI.ZONE Threat Intelligence.
- Оценивать не число найденных сервисов, а уровень снижения риска. Метрика «найдено 146 сервисов» сама по себе мало что говорит. Важнее понимать, сколько из них создают реальную угрозу, какие подразделения отвечают за их устранение и где остаются наиболее опасные точки входа.
Пока компания не знает, какие сервисы опубликованы во внешнем периметре, она не может объективно оценивать поверхность атаки. Поэтому непрерывная инвентаризация становится такой же базовой практикой, как управление уязвимостями или контроль конфигураций.
Увидеть внешний периметр так, как его видит сторонний наблюдатель, позволяет BI.ZONE EASM. Решение помогает найти забытые сервисы, тестовые стенды, открытые административные панели, облачные ресурсы, интерфейсы удаленного доступа и другие активы, которые могли не попасть в CMDB, внутренние заявки или регулярную инвентаризацию.
На практике это выглядит так:
- Появляется новая уязвимость в VPN, почтовом сервере, сетевом устройстве, DevOps‑платформе или другом сервисе, который может быть доступен из интернета.
- Команда кибербезопасности уже имеет актуальную картину внешнего периметра: какие сервисы опубликованы наружу, на каких хостах они находятся и к каким активам относятся.
- Глубокая инвентаризация веб‑приложений помогает оценить потенциальное влияние уязвимости: определить используемые технологии — языки программирования, фреймворки, CMS, веб‑серверы и другие компоненты, которые могут быть затронуты.
- Ежедневная инвентаризация внешнего периметра и система уведомлений помогают не пропустить появление новых сервисов: тестовых стендов, открытых административных панелей, интерфейсов удаленного доступа, облачных ресурсов и других активов, которые могли быть опубликованы без согласования.
- Потенциально опасные сервисы помечаются и обрабатываются как уязвимости: отслеживается статус исправления и контролируется, что чувствительные активы больше не доступны из интернета.
Такой подход переводит управление внешним периметром из реактивного поиска ответа на вопрос «что у нас опубликовано наружу?» в управляемый процесс снижения поверхности атаки. Проведите пилотирование BI.ZONE EASM и получите карту публичных активов, список опасных экспозиций, приоритизацию по риску и рекомендации по устранению найденных уязвимостей.