Сканер уязвимостей Tenable и Nessus

Обнаружение активов с помощью Nessus: первый шаг по оценке киберрисков

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

Полная инвентаризация информационных активов всегда была первым условием для эффективного управления уязвимостями. Поверхность атаки постоянно растет и усложняется, поэтому возможность находить все ресурсы в сети сегодня важнее, чем когда-либо. Необходимо уметь выявлять не только обычные ИТ-ресурсы, но и ресурсы, связанные с операционными технологиями (ОТ) и «теневым ИТ». Любые ресурсы, которые остаются вне поля вашего зрения, представляют собой дополнительный риск.

Настройки инвентаризации в Tenable Nessus

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

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

  1. повышения глубины детализации ресурсов и обнаружения «слепых зон»;
  2. базового управления уязвимостями, которое в основном полагается на такие данные как установленное ПО или его версии;
  3. риск-ориентированного управления уязвимостями, которое осуществляет точный расчет метрик киберрисков для Tenable Lumin.

Информация, полученная в результате инвентаризации ресурсов, напрямую влияет на метрики Lumin, например, на рейтинг критичности актива (Asset Criticality Rating, ACR), т. к. он рассчитывается на основе данных о типе устройства и его функциях. Другая метрика, оценка риска актива (Asset Exposure Score, AES), основана на информации базового управления уязвимостями, а значит, и на информации об инвентаризации.

Обнаружение активов с помощью сканера Nessus

Обнаружение активов в сканерах Nessus выполняется с помощью множества плагинов. В то время как большая часть плагинов (более 95%) отвечает за выявление уязвимостей, в процессе обнаружения ресурсов используются специализированные плагины (многие из них имеют пометку INFO), которые извлекают точную информацию о хосте. Стоит заметить, что сканеры Nessus в основном используются для ИТ-пространства, в том числе для теневых ИТ. Для сканирования ресурсов АСУ ТП применяются другие продукты Tenable, например, Tenable.ot.

Процесс обнаружения ресурсов логически структурирован и проходит в четыре этапа, которые показаны на рисунке 1: сканирование портов, обнаружение сервисов и протоколов, определение ПО и снятие отпечатка ОС.

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

Этапы и результаты работы процесса выявления активов Nessus
Рисунок 1: Этапы и результаты работы процесса выявления активов Nessus

Четыре этапа обнаружения ресурсов:

  1. Сканирование портов. Сканер Nessus разными способами пингует узел, находит открытые порты и определяет, нужно ли продолжать сканирование.
  2. Обнаружение сервисов и протоколов. Nessus отправляет тестовые запросы на открытые порты в поисках сервисов, которые их слушают, и известных протоколов.
  3. Определение ПО. Главная цель — составить список различных приложений, их версий и патчей, которые есть на узле.
  4. Наконец, на основе всей информации, полученной на предыдущих этапах, Nessus пытается определить тип ОС и ее версию на удаленном узле.

В следующих разделах будут описаны определенные этапы, а также задействованные на них плагины и их основные группы.

Сканирование портов 

Сканирование в Nessus начинается с проверки, доступен ли хост онлайн. Если хост онлайн, то составляется список обнаруженных на нем открытых портов. Чтобы определить, принадлежит ли данное имя или IP-адрес активному хосту, первым при сканировании обычно запускается плагин Ping Remote Host (10180), но его можно отключить. Если этот плагин не получает ответа от хоста, то хост считается неактивным, и процесс сканирования прекращается. Если же хост активен, то Nessus попытается просканировать его порты с помощью различных плагинов из группы для сканирования портов. Это можно сделать как удаленно, так и локально (если доступна учетная запись). Обнаружение открытых портов — крайне важный этап в работе любого сетевого сканера, т. к. это обеспечивает последующее обнаружение сервисов и отправление на них тестовых запросов, а также дальнейшую коммуникацию с удаленным узлом.

Перед тем, как продолжить сканирование, Nessus проверяет, может ли узел оказаться «хрупким» ресурсом, например, принтером или устройством АСУ ТП. Большое количество и разнообразие запросов, посылаемых к таким ресурсам при активном сканировании, может негативно сказаться на их работе. По этой причине в сканер по умолчанию встроена функция, которая позволяет уберечь хрупкие ресурсы. Плагины для прекращения сканирования, например, 22481 и 11933, остановят процесс при обнаружении подобного ресурса.

Этап сканирования портов в Nessus
Рисунок 2: этап сканирования портов в Nessus

Обнаружение сервисов и протоколов 

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

Плагины этой группы (главным образом, плагин 22964) отправляют тестовые запросы на открытые порты и анализируют их ответы, чтобы определить, какие сервисы запущены на удаленном узле. Информация об известных и неизвестных сервисах (например, баннер сервиса, версия сервиса или SSL-инкапсуляция) сохраняется для использования плагинами на следующих этапах обнаружения.

Затем, на основе данных о выявленных сервисах, сканер отправляет тестовые запросы к конкретным протоколам и их версиям, например, к протоколам HTTP (1058210107), SSL / TLS (21643), SSH (10267), Telnet (10280), SMB (1039410150), SNMP (40448), SMTP (10263) и многим другим. Нужно отметить два особых случая: часть тестовых запросов к протоколам SMB и SSH отправляется сразу же после пингования узла, т. к. оба эти протокола могут быть использованы для сканирований с использованием учетных данных, в том числе для локального сканирования портов.

Этап обнаружения сервисов в Nessus
Рисунок 3: этап обнаружения сервисов в Nessus

Определение ПО

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

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

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

Локальные проверки

При сканировании с использованием учетной записи Nessus запускает несколько плагинов для поддерживаемых ОС (Unix-подобных или Windows). Эти плагины можно назвать «локальными перечислителями» (local enumerators), они предназначены для получения информации об основных характеристиках системы, в том числе об установленных патчах и ПО (плагины 138559799383991), а также о процессах и сервисах (11048370329). На следующих этапах другие плагины могут собрать эту информацию, чтобы использовать ее при определенных видах обнаружения или других проверках. Разберем пару примеров, чтобы лучше понять этот процесс: один для Windows, другой для Unix-подобной ОС.

Для начала рассмотрим случай типичного локального детекта клиента Zoom в системе Windows (плагин 118801). Данный плагин проверяет информацию из реестра Windows, полученную от плагина 13855. В зависимости от полученных данных будут проведены дополнительные проверки реестра и файловой системы, чтобы найти информацию о версии приложения и проверить расположение установочного файла.

Локальный плагин Nessus для обнаружения клиента Zoom в Windows и плагины, от которых он зависит
Рисунок 4: локальный плагин Nessus для обнаружения клиента Zoom в Windows и плагины, от которых он зависит

Теперь рассмотрим случай локального обнаружения Java-приложения в системе Unix (64815). Процесс этого обнаружения немного сложнее, потому что Java может присутствовать в системе по-разному. Этот плагин производит комбинацию проверок, основываясь на информации файловой системы, данных диспетчера пакетов и запущенных процессах.

Локальный плагин Nessus для обнаружения Java-приложения в системе Unix и плагины, от которых он зависит
Рисунок 5: локальный плагин Nessus для обнаружения Java-приложения в системе Unix и плагины, от которых он зависит

Удаленные проверки

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

Обнаружение на основе HTTP, скорее всего, преобладает среди других видов удаленных обнаружений в Nessus, потому что веб-серверы, веб-приложения и HTTP-соединения есть практически везде. На рисунке 6 показан пример обнаружения веб-сервера Apache на основе HTTP (плагин 48204). Здесь изображен поток информации от плагинов обнаружения сервисов и протоколов (например, 10582), а также процесс того, как дополнительные плагины агрегируют данные об HTTP-серверах в целом (1010719689) и о веб-сервере Apache в частности (111465). 

Удаленный плагин Nessus для обнаружения HTTP-сервера Apache и плагины, от которых он зависит
Рисунок 6: удаленный плагин Nessus для обнаружения HTTP-сервера Apache и плагины, от которых он зависит

Комбинированные проверки

Наконец, при комбинированном обнаружении информация собирается и из локальных, и из удаленных источников. Например, плагин для обнаружения операционной системы Cisco IOS (47864) собирает информацию от удаленных плагинов для обнаружения протокола SNMP (1080010969) и от «локальных перечислителей» (12634). Обратите внимание, что большинство видов комбинированных обнаружений не объединены в один плагин, а представлены в отдельных локальных и удаленных плагинах обнаружения, например, сервера Weblogic (716427164373913), Apache HTTP Server (48204141262141394) и др. 

Этап сбора информации о платформе и ПО в сканерах Nessus
Рисунок 7: этап сбора информации о платформе и ПО в сканерах Nessus

Определение типа ОС 

Определение типа ОС — последний шаг в процессе инвентаризации ресурсов, когда сканер анализирует информацию, полученную на всех предыдущих этапах, и делает наиболее точное предположение об ОС узла. На рисунке 8 показано, что плагин для определения ОС (11936) полагается на множество других плагинов и различных протоколов. Каждый из этих плагинов может сделать собственное предположение, которое имеет соответствующую степень достоверности. Степень достоверности определяется в каждом отдельном случае и во многом зависит от конкретного протокола и задействованных отпечатков.

В таблице ниже можно увидеть конкретный пример с использованием четырех методов считывания отпечатка ОС. Плагин для определения типа ОС выберет метод с наивысшей степенью достоверности (в этом случае это локальное обнаружение протокола SMB), и предположение на основе этого метода будет объявлено как распознанная ОС.  

МетодПредположениеСтепень достоверности
HTTPMicrosoft Windows70
SMB (удаленное обнаружение)Windows 6.370
MSRPCMicrosoft Windows Server 2012 R2 Standard99
SMB (локальное обнаружение)Microsoft Windows Server 2012 R2 Standard100
Источник: Tenable

Следует заметить, что только часть методов считывания отпечатка может сделать предположение о типе ОС. Например, предположение HTTP-плагина об ОС (плагин 25247) может быть сделано только тогда, когда мы обнаружим этот протокол на удаленном хосте, получим баннер и сопоставим с известным отпечатком ОС в плагинах Nessus. Кроме того, некоторые методы позволят извлечь более подробную информацию, чем другие: плагин для вероятностного определения отпечатка (132935), возможно, сделает предположение об основной версии дистрибутива Linux, в то время как локальный плагин для определения отпечатка Linux (25335) сможет точно определить конкретный дистрибутив, его версию и сборку.

Этап определения типа ОС в сканерах Nessus
Рисунок 8: этап определения типа ОС в сканерах Nessus

Заключение

Возможности сканера уязвимостей Nessus для инвентаризации ресурсов — это фундамент как для традиционного, так и для риск-ориентированного управления уязвимостями. Эти функции полезны сами по себе в качестве средства инвентаризации активов в сети и обнаружения слепых зон. Для этого компания Tenable ежегодно выпускает сотни плагинов для обнаружения ресурсов на новом программном и аппаратном обеспечении, чтобы клиенты Tenable могли точно выявлять свои киберриски.

Об авторе

Тайгер Оптикс является специализированным дистрибьютором решений по кибербезопасности. Компания основана в 2010 году в Российской Федерации и имеет представительства в Казахстане, Беларуси, Азербайджане и Узбекистане.

Мы помогаем партнерам и заказчикам повышать защищенность на всем протяжении корпоративной ИТ-инфраструктуры – от гибридного ЦОДа до конечных точек – рабочих станций и мобильных устройств.

Веб-сайт: https://www.tiger-optics.ru/