Боков Фёдор, Security Vision
«Хочу видеть всю картину, но не готов дать вам ключи от всех дверей» – так звучит одно из самых частых и противоречивых пожеланий заказчика, который купил продукт по управлению активами, но не хочет предоставлять какие-либо данные для подключения к целевым хостам, сетевым устройствам и другим ИТ-активам. Чем в таком случае вендор может помочь? Управлением активов в режиме Blackbox.
Обнаружение активов
Всё начинается с простого вопроса: что вообще есть у заказчика в сети? Когда нет доступа к внутренней документации или конфигурациям, приходится искать активы вслепую. Первый и главный метод – сетевое сканирование. В данном случае нам поможет самописный или любой Opensource сканер, например, nmap или masscan. После сканирования сети мы понимаем, какие IP адреса у нас имеются в инфраструктуре и какие именно порты открыты для дальнейшего взаимодействия с ними. Факт наличия открытого порта уже ценная находка. Он сигнализирует о том, что на хосте запущен какой-то сервис, готовый к взаимодействию.
Идентификация
Идентификация — это один из самых богатых по вариативности процессов в управлении активами. Когда список открытых портов готов, начинается настоящая детективная работа: нужно понять, что именно за ними скрывается. Для этого используется всё, что может рассказать о себе активный сервис. Каждый актив, отвечая на внешние запросы, невольно оставляет множество улик. Задача идентификации – собрать и проанализировать эти улики. К ним относятся технические баннеры, содержимое заголовков HTTP, заголовки страниц (title), иконки сайтов (favicon), структура HTML-кода и даже уникальные паттерны поведения (фингерпринты). Ключом к правильному сбору информации служат сами открытые порты. Опираясь на их стандартное назначение, мы выбираем корректный метод взаимодействия – какой протокол использовать и на какие вопросы спрашивать службу, чтобы получить от неё максимально информативный ответ.
Возьмём классический пример. Обнаружив открытый 22-й порт, мы с высокой долей вероятности предполагаем работу SSH-сервера. Устанавливаем подключение и первым делом получаем от системы баннер – служебное приветственное сообщение. В нём может содержаться ключевая строка, например: OpenSSH_8.9p1 Ubuntu-3ubuntu0.13.
Её анализ сразу даёт нам несколько фактов. Во-первых, можно сделать вывод об использовании OpenSSH сервера. Во-вторых, прямо указана операционная система – Ubuntu. Но на этом можно не останавливаться. Сверив конкретную версию пакета (8.9p1 Ubuntu-3ubuntu0.13) с репозиториями дистрибутива, мы уточняем, что это сборка, характерная для Ubuntu 22.04 LTS (Jammy Jellyfish). Таким образом, из баннера мы извлекаем не только тип службы, но и точную версию операционной системы.
Другой наглядный пример — это анализ веб-интерфейса, доступного на стандартном порту 443. При обращении к такому сервису система передаёт не только содержимое страницы, но и служебные HTTP-заголовки. В некоторых случаях они являются исчерпывающим ответом. Например, если в ответах мы видим заголовок http-title: GAiA, а среди метаданных – значение Server: CPWS, этого уже достаточно для точного вывода. Комбинация этих признаков однозначно указывает на сетевое устройство под управлением операционной системы Checkpoint Gaia. Так, даже без доступа к внутренней конфигурации, мы можем точно классифицировать актив и понять его роль в инфраструктуре.
Получение ПО
Пройдено два ключевых этапа: сетевое сканирование для обнаружения активов и первичная идентификация, однако в условиях blackbox на этом останавливаться нельзя. Поскольку инвентаризацию провести невозможно, единственный способ составить полную (насколько это возможно) картину – максимально подробно проанализировать каждый обнаруженный открытый порт на предмет информации. По сути, провести методичный опрос всех доступных интерфейсов.
Например, обнаружив на хосте открытые порты 443/HTTPS и 1433/MsSQL, мы применяем к каждому из них целевые методы сбора данных. К порту 443 обращаемся как к веб-сервису: анализируем не только баннер подключения, но и получаем HTML страницу, изучаем все HTTP заголовки ответа и JavaScript код. Это позволяет выявить веб-фреймворк, интерпретатор, CMS или конкретное веб-приложение, функционирующее на порту. Чтобы идентифицировать сервис на порту 1433, мы используем два основных метода: пробуем подключиться к нему как к базе данных через соответствующий клиент и/или анализируем его реакцию на веб-запросы. Это даёт понять, имеем ли мы дело с СУБД, веб-интерфейсом или иной службой.
В нашем случае, проанализировав с портов всю имеющуюся информацию, а именно баннера 1433 порта: Microsoft SQL Server 2017 14.00.1000 и HTML страницу на 443 порту:
https://www.example.ru/ [200 OK] Bitrix-Site-Manager, Cookies[PHPSESSID], Country[RUSSIAN FEDERATION][RU], Email[example@email.com], Frame, HTML5, HTTPServer[nginx/1.28.0], HttpOnly[PHPSESSID], IP[192.168.156.166], JQuery, Open-Graph-Protocol[website], PHP[8.2.29], Script[text/javascript], Title[Example], UncommonHeaders[x-powered-cms,content-security-policy,x-ammina-module], X-Frame-Options[SAMEORIGIN], X-Powered-By[PHP/8.2.29], nginx[1.28.0],
можем сделать выводы о следующих функционирующих приложения:
-
Microsoft SQL Server 2017 версии 14.00.1000,
-
Веб-сервер nginx версии 1.28.0,
-
Интерпретатор PHP версии 8.2.29.
Этот список, включающий названия, типы и, что самое важное, точные версии ПО, и становится основой для финального и самого важного этапа – целенаправленного поиска уязвимостей в этом конкретном программном стеке.
Собрав сведения о прикладном программном обеспечении, мы углубляем анализ. Следующим логичным шагом становится исследование самой операционной системы — базовой платформы, на которой работают все обнаруженные службы. Этот этап позволяет восстановить ключевые параметры окружения, что критически важно для оценки рисков, даже не подключаясь к системе напрямую.
Ряд значений параметров системы может быть выявлен косвенным образом. Например, архитектура и разрядность системы (x64, ARM) зачастую определяются на основе доступных списков пакетов в репозиториях (для Linux-систем) или через специфические ответы некоторых сервисов, предназначенных для определённых платформ.
Чтобы понять роль актива, нужно узнать его сетевое имя. При подключении по определённым протоколам (RDP, SMB) система часто сообщает свой hostname или FQDN, а также принадлежность к домену (Active Directory). Эта простая информация может указывать, является ли хост рядовым сервером или важным элементом, например, контроллером домена.
Временные параметры могут показаться второстепенными, но они также информативны. Анализ временных меток в заголовках HTTP или отклонение системного времени, полученного через некоторые протоколы, позволяет судить о проблемах синхронизации с NTP сервером.
MVP-практика
Управление активами без внутреннего доступа требует особого подхода, основанного на непрерывном цикле наблюдений. Поскольку использование инвентаризации невозможно, это компенсируется тремя взаимосвязанными процессами, работающими как автоматизированный конвейер безопасности.
Первым процессом выступает постоянный поиск нового. Основа подхода – регулярное и частое сканирование внешнего и внутреннего периметров. Мы не можем получить полноценную карту сети через сетевые устройства, но можем составить предварительный макет расположения активов. Автоматизированные инструменты обходят все известные домены компании и диапазоны её IP-адресов, фиксируя любые изменения: новый субдомен, ранее невидимый сервер или неожиданно открытый порт на существующем хосте. Цель – обнаружить такие изменения в течение короткого времени.
Пример карты сети, построенной с использованием модуля Security Vision Assets Management
Второй ключевой процесс – установление системы постоянного мониторинга для всех уже выявленных активов. Обнаружение и первичная идентификация являются лишь начальной точкой, после которой каждый хост переходит в режим регулярного наблюдения. Для этого запускается цикл периодического перепрофилирования, выполняемого по заданному расписанию. Важно не просто фиксировать исходное состояние системы, а последовательно отслеживать любые отклонения от этой базовой линии: изменения версий установленного программного обеспечения, модификации конфигураций служб, появление новых открытых портов и сетевых сервисов. Такой подход позволяет чётко детектировать и классифицировать происходящие события, разделяя плановые обновления от несанкционированных изменений.
Завершающим процессом являются непрерывная аналитика. Собранные данные автоматически систематизируются. Каждому активу присваивается роли, основанные на причастности к той или иной категории, а также устанавливается уровень критичности, исходя из критериев актива. Это позволяет перейти от простого списка проблем к чёткому плану действий: что устранять в первую очередь, за чем следить с пристальным вниманием.
Blackbox – не волшебная таблетка. Это базовый, но абсолютно необходимый уровень работы. Он не заменит полноценную инвентаризацию, но даст вам конкретный список проблем, которые нужно закрыть в первую очередь, позволив перейти от абстрактных угроз к конкретному списку дыр в вашей инфраструктуре: открытых портов, устаревших версий, небезопасных конфигураций. Это взгляд на свою инфраструктуру глазами того, кто хочет в неё попасть без спроса. И этот взгляд часто оказывается самым полезным.
