Руководство пользователя

Список обозначений

Система - развернутое и работающее в сети заказчика решение "Vulns.io Enterprise VM".
Актив - компьютер, сервер, виртуальная машина, гипервизор или сетевое устройство, мониторинг которого ведется с помощью Системы.
Агент - программа, устанавливаемая на Актив, для обеспечения его сканирования в агентном режиме.
Учетная запись - реквизиты, используемые Системой для подключения к Активам, реестрам контейнеров и другим сетевым сервисам.
Кабинет - основной web-интерфейс системы для работы пользователей.
Лицензия - право на использование продукта на заданный срок с оговоренными ограничениями и функционалом.
Ключ лицензии - буквенно-цифровой код для идентификации активированной лицензии.
БДУ - база данных уязвимостей, на основе которой производится сканирование Активов.

Быстрый старт

Установка Системы

Для установки Системы вам понадобится:

инсталлер https://download.vulns.io/onpremise/install/vio-installer,
файл с действующей активированной Лицензией,
действующий ключ к облачному API Vulns.io,
сервер или виртуальная машина с любым linux-дистрибутивом с установленными:
- Docker 19.03.13+,
- Docker-compose V1 1.29.0+ или Docker-compose V2 2.8.0+,
доступ в Интернет.

При запуске инсталлер запросит некоторые параметры установки, скачает и запустит все необходимые контейнеры.

После завершения работы инсталлера в браузере станет доступна форма авторизации в Систему по доменному имени, указанному при установке, или ip-адресу сервера. Настроенное доменное имя можно посмотреть в файле /opt/vulns.io/onpremise/config/nginx/api.conf.

Используйте для входа email и пароль, которые вы указали при установке. Эта учетная запись также сохранена в файле /opt/vulns.io/onpremise/config/main/credentials.ini

Более подробная информация об установке Системы содержится в "Руководстве по установке":

программные и аппаратные требования к конфигурации сервера,
требования к объему файлового хранилища,
сетевые доступы в Интернет и внутри инфраструктуры,
настройка доменного имени и SSL-сертификатов,
ограничения сетевого доступа,
последующее обновление Системы и пр.

Загрузка БД уязвимостей

Дождитесь, пока закончится первоначальная загрузка базы данных уязвимостей - в Кабинете пропадет сообщение Идет загрузка данных БДУ. Дождитесь окончания процесса, иначе результаты сканирования будут недостоверными.

Добавление первого актива

На странице "Активы / Хосты" выберите меню "Добавить актив".

В зависимости от выбранной операционной системы скачайте и установите Агента.

После установки Агент выполняет первичную инвентаризацию и аудит уязвимостей, и Актив начинает отображаться на странице “Активы / Хосты” со статусом "Онлайн".

Результат первого сканирования

Результат первичного сканирования будет сразу доступен на детальной странице Актива.

Создание pdf-отчета

Для создания отчета нажмите кнопку "Создать отчёт" на детальной странице Актива:

выберите вид и тип отчёта,
выберите формат файла,
нажмите Создать задачу.

После завершения задачи отчет будет доступен для скачивания во вкладке "Артефакты" на странице запуска вашей задачи (раздел "Аудит / История задач").

Как работает сканирование

Агентный и безагентный подход

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

Агентный подход

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

Для агентного подхода необходим только сетевой доступ от актива к Системе. Нет необходимости хранить учетную запись актива.

Безагентный подход

Для проведения сканирования в безагентном режиме Система:

Выполняет сетевое подключение к активу с заранее заведенной и привязанной учетной записью.
Копирует на актив утилиту для выполнения сканирования.
Выполняет сканирование или другие необходимые действия (инвентаризация, обновление и пр.)
Выгружает результаты выполнения в Систему.
Удаляет утилиту и все временные файлы, созданные на активе.
Закрывает сетевое соединение.

Для безагентного сканирования linux-активов необходимы:

сетевой доступ от Системы к активу,
учетная запись с привилегиями sudo или находящаяся в группе root.

Сравнение подходов

	Агентный	Безагентный
Не требует настройки сетевого доступа к активу	Да	-
Не требует хранения учетной записи актива	Да	-
Не требует установки Агента	-	Да
Может сканировать сетевые устройства	-	Да
Поддерживает все действия на активе (аудит, инвентаризация, обновление и пр.)	Да	Да
Скорость сканирования	максимальная	средняя*

^* появляются дополнительные затраты времени на сетевое подключение, загрузку утилиты сканирования и очистку после завершения сканирования.

Если установлен Агент и одновременно привязана учетная запись

В этой ситуации Система сама выберет, какой подход использовать для сканирования:

если Агент находится на связи в статусе "Онлайн", то будет использоваться он,
если Агент находится в статусе "Офлайн" или "Не активирован", то будет использоваться привязанная к Активу учетная запись.

Как выполняется сканирование

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

Для проведения сканирования (аудита) уязвимостей на хосте собирается и отправляется в Систему:

информация об операционной системе: название дистрибутива, версия,
список установленного программного обеспечения с версиями,
список установленных обновлений (для некоторых ОС).

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

Формируется результат сканирования:

список уязвимого ПО,
список доступных обновлений,
список найденных уязвимостей,
список отсутствующих обновлений безопасности (для некоторых ОС),
фиксируется список проанализированного ПО,
фиксируется сопутствующая метаинформация: дата и время сканирования, CVSS-метрики, критичность уязвимостей по методике ФСТЭК (V) и прочее.

Инвентаризация хостов

Для проведения инвентаризации на хосте запускается ряд системных команд ОС, собирается и отправляется в Систему подробная информации о хосте:

сведения об операционной системе,
сведения о железе: CPU, память, диски,
информация о сетевых интерфейсах и маршрутах,
списки локальных групп и пользователей,
список установленного ПО с версиями,
список запущенных сервисов,
список обнаруженных docker-образов и запущенных контейнеров.

На стороне Системы для соответствующего актива формируется результат инвентаризации.

Сканирование образов контейнеров

На хосте

Сканирование образов контейнеров на хосте производится Агентом на данном хосте или с помощью безагентного подключения без запуска контейнеров.

О каждом обнаруженном docker-образе собирается и отправляется в Систему:

информация об операционной системе образа: название дистрибутива, версия,
список установленного в образе программного обеспечения с версиями,
размер образа, архитектура и идентификатор образа (sha256),
список слоев с информацией о каждом слое: дата создания, команда создания, размер, Layer ID.

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

Формируется результат сканирования образа:

список уязвимого ПО,
список доступных обновлений,
список найденных уязвимостей,
фиксируется список проанализированного ПО,
фиксируется сопутствующая метаинформация: дата и время сканирования, CVSS-метрики, критичность уязвимостей по методике ФСТЭК (V) и прочее.

В реестре

Для проведения сканирования образов контейнеров в реестрах:

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

Система может сканировать образы в реестрах контейнеров, поддерживающих Docker Registry HTTP API V2.

Сканирование производится задачей типа "Образы контейнеров" с указанием хоста или реестра (см. раздел "Задачи").

В пайплайнах CI/CD

Для проведения сканирования образов в пайплайнах CI/CD используются:

Специальный образ-компаньон, который содержит необходимый инструментарий для сканирования образов (образ-компаньон доступен для свободного скачивания из реестра hub.vulns.io).
Vulns.io Common API, доступный в Системе.

Common API также доступен в облаке Vulns.io по адресу https://api.vulns.io/v1/. При его использовании не требуется разворачивать Систему, но необходимо получить токен для доступа.

В процесс CI/CD необходимо добавить новый этап, в рамках которого определить задачу сканирования целевого образа: указать необходимые параметры задачи, данные о целевом образе, данные для авторизации в реестре, токен API.

В ходе задачи сканирования выполняется:

Скачивание образа-компаньона (из реестра hub.vulns.io или локального реестра организации) и запуск процедуры сканирования.
Скачивание целевого образа из указанного реестра контейнеров.
Анализ файлов целевого образа и сбор исходных данных для проведения аудита (определение дистрибутива и его версии, сбор установленных пакетов и их версий) без запуска целевого контейнера.
Отправка собранных данных в Vulns.io Common API для анализа уязвимостей.
Формирование отчета о найденных уязвимостях в виде артефакта задачи.

Подробное описание сканирования образов в пайплайнах CI/CD с примерами конфигураций см. в разделе "Образы контейнеров / Сканирование в CI/CD".

Скорость сканирования и сетевой трафик

Сканирование хостов

	Агентный	Безагентный
Аудит уязвимостей:
- время сканирования	1..3 сек	3..4 сек
- трафик к хосту	~ 1КБ	~12 МБ
- трафик от хоста	5..50 КБ *	5..50 КБ *
Инвентаризация:
- время сканирования	5..60 сек **	8..65 сек **
- трафик к хосту	~ 1КБ	~12 МБ
- трафик от хоста	50..100 КБ **	50..100 КБ **

^* зависит от количества установленного программного обеспечения и обновлений безопасности (KB),

^** зависит от конфигурации хоста.

Сканирование образов контейнеров

	Агентный	Безагентный
На хостах:
- время сканирования 1 образа	3..5 сек	5..7 сек
- трафик к хосту	~ 1КБ	~12 МБ
- трафик от хоста	5..50 КБ *	5..50 КБ *
В реестрах:
- время сканирования 1 образа		..**
- трафик к реестру		..**
- трафик от реестра		..**

^* зависит от количества установленного в образе программного обеспечения

^** зависит от размера образа.

Сетевые доступы

Внутри инфраструктуры

Источник	Назначение	Порт	Описание трафика
Рабочее место пользователя Системы	Система	80,443 / TCP	HTTP-трафик Кабинета
Актив с Агентом	Система	443 / TCP	Подключение Агентов к серверу Системы
Система	linux-активы без Агента	22 / TCP	Подключение к linux-активам
Система	windows-активы без Агента	135,137-139, 445, 5985, 5986 / TCP/UDP	Подключение к windows-активам
Система	сетевое оборудование *	22,23 / TCP, 162 / UDP	Подключение к сетевым устр-вам
Система	почтовый сервер	25 / TCP	Отправка сообщений на email
Система	реестры контейнеров	443 / TCP	Подключение к реестрам контейнеров для сканирования образов
Система	LDAPS-сервер	389 / TCP, 636 / TCP	Подключение к серверу LDAPS
Система	AD-сервер	3268 / TCP, 3269 / TCP	Подключение к контроллеру доменов

^* сетевые доступы будут зависеть от конкретного оборудования.

Агенты

Установка агентов

Требования к установке

Linux

Агент необходимо устанавливать от пользователя с правами root.
Дистрибутив должен использовать систему управления службами systemd.

Поддерживаются следующие дистрибутивы:

Alma Linux 8, 9
Alpine 3.2 - 3.17
Amazon Linux 1, 2, 2023
Arch Linux
Centos 5 - 8
Debian 3 - 12
Fedora Linux (21+)
Gentoo
Manjaro Linux
openSUSE, openSUSE Leap
Oracle 5 - 8
RedHat 5 - 9
Rocky 8, 9
SUSE (SLED, SLES)
Ubuntu 12.04 - 22.10
Virtuozzo 6,7
Virtuozzo Hybrid Server 7
Altlinux 8, 9, 10
Astra Linux 1.6, 1.7, 4,7, 2.12
Rosa Cobalt 7.3, 7.9
Rosa Enterprise Desktop 7.3, 7.9
RedOS 7.3
МСВ Сфера
ОСнова

Windows

Агент необходимо устанавливать от пользователя с правами локального Администратора.

Поддерживаются следующие версии Windows:

Windows 7 и выше (все десктопные и серверные версии).

Ручная установка

Linux

Установка Агента на linux-активе подразумевает запуск специального установочного bash-скрипта, сгенерированного Системой индивидуально для конкретного актива.

Для ручной установки выполните следующие шаги:

На странице "Активы / Хосты" выберите меню "Добавить актив" -> "linux".

Появится форма "Новый linux-актив создан!" с описанием шагов установки:

Форма добавления linux-актива

Нажмите на кнопку "Скачать", чтобы скачать установщик Агента, и поместите его в любую папку на активе.

Или запустите команду скачивания прямо на активе:

Пример:
curl -k -O https://<ip_адрес>/download/v1/agent-installer/
agent-<идентификатор_агента>-linux-installer.sh

Не используйте полученный установочный скрипт для массовой установки на нескольких активах! Для массового развертывания агентов воспользуйтесь инструкцией в разделе "Установка агентов / Автоматизированная установка".

Сделайте файл установщика исполняемым:

sudo chmod u+x agent-<идентификатор_агента>-linux-installer.sh

Запустите установку Агента командой:

sudo ./agent-<идентификатор_агента>-linux-installer.sh

Закройте форму "Новый linux-актив создан!" кнопкой "Сохранить актив".

Важно! Если на данном этапе закрыть форму кнопкой "Отменить" и подтвердить удаление актива, то ссылка на установочный скрипт перестанет работать, а установленный Агент не сможет подключиться к Системе.

Скрипт установки выполняет следующие действия:

Определяет битность ОС.
Подключается к Системе и скачивает нужные бинарные файлы Агента и апдейтера.
Создает директорию /opt/vulns.io/agent-linux/.
Создает файлы:
- config.ini - конфигурационный файл,
- agent_uninstall.sh - деинсталлятор агента,
- vulns.io-agent-linux.service и vulns.io-agent-updater-linux.service - файлы описания сервисов.
Запускает сервисы:
- vulns.io-agent-linux - Агента,
- vulns.io-agent-updater-linux - апдейтера (для автоматического обновления Агента).

После установки Агент выполняет первичную инвентаризацию и аудит уязвимостей, и Актив начинает отображаться на странице “Активы / Хосты” со статусом "Онлайн".

Windows

Для установки Агента на windows-активе необходимо использовать сгенерированный Системой индивидуальный для конкретного актива конфигурационный файл совместно с универсальным установщиком agent-windows-installer-x64-latest.msi.

Для ручной установки выполните следующие шаги:

На странице "Активы / Хосты" выберите меню "Добавить актив" -> "windows".

Появится форма "Новый windows-актив создан!" с описанием шагов установки:

Форма добавления windows-актива

Выберите разрядность операционной системы и нажмите на кнопку "Скачать установщик агента", чтобы скачать установщик Агента, и поместите его в любую папку на активе.
Нажмите на кнопку "Скачать конфигурацию агента", чтобы скачать конфигурационный файл Агента, и поместите его в папку с установщиком Агента.

Не используйте полученный конфигурационный файл для массовой установки на нескольких активах! Для массового развертывания агентов воспользуйтесь инструкцией в разделе "Установка агентов / Автоматизированная установка".

Запустите установщик Агента и пройдите все шаги установки.

Установщик выполняет следующие действия:

Создает рабочую директорию C:\Program Files (x86)\Vulns.io Windows Agent
Запускает службу Vulns.io Windows Agent

После установки Агент выполняет первичную инвентаризацию и аудит уязвимостей, и Актив начинает отображаться на странице “Активы / Хосты” со статусом "Онлайн".

Автоматизированная установка

Массовая автоматизированная установка Агентов на большое количество Активов возможна с использованием средств автоматизации и API Системы.

Linux

В качестве примера рассмотрим развертывание Агентов на linux-активах с помощью системы Ansible:

Формируется файл описания задания (playbook) для Ansible (см. пример ниже), который выполняет следующие действия:
- копирует на хосты специальный bash-скрипт для установки и запуска Агента,
- удаляет скрипт после успешной установки Агента.
Запускаемый на Активе bash-скрипт (скачать*) выполняет действия:
- используя API Системы, создает Актив и получает уникальный URL для скачивания установщика Агента,
- скачивает и запускает установщик Агента,
- проверяет корректность запуска службы Агента.

## Пример playbook-файла для Ansible
- name: "Prepare to remote hosts"
  hosts: *
  tasks:
   - name: Copy deploy script ./deploy-linux-agent.sh to remote host
     ansible.builtin.copy:
       src: "./deploy-linux-agent.sh"
       dest: "/tmp/deploy-linux-agent.sh"
       mode: '0775'
   - name: Run deploy script
     command:
       cmd: "/tmp/deploy-linux-agent.sh"
   - name: Remove deploy script from host
     file:
       path: "/tmp/deploy-linux-agent.sh"
       state: absent

^* в bash-скрипте (https://download.vulns.io/onpremise/scripts/deploy-linux-agent.sh) необходимо указать параметры:

* SERVER_IP - ip-адрес вашего сервера с установленной Системой,
* API_KEY - ключ API для доступа к вашей Системе (см. раздел "Создание API-токена" ниже).

После завершения задания Ansible в Системе появятся все Активы, на которых был успешно установлен Агент.

Windows

Существует 3 способа массовой установки Агентов на windows-активы:

с помощью специального powershell-скрипта deploy-windows-agent.ps1,
с помощью установщика Агента agent-windows-installer-x64-latest.msi,
с использованием групповой политики (Group Policy Object) и установщика Агента.

С помощью powershell-скрипта

Для массового развертывания Агентов на windows-активах необходимо использовать powershell-скрипт (скачать*), который выполняет следующие действия:

используя API Системы, создает Актив и получает уникальный URL для скачивания установщика Агента,
скачивает и запускает установщик Агента,
проверяет корректность запуска службы Агента.

^* в powershell-скрипте (https://download.vulns.io/onpremise/scripts/deploy-windows-agent.ps1) необходимо указать параметры:

* $SERVER_IP - ip-адрес вашего сервера с установленной Системой,
* $API_KEY - ключ API для доступа к вашей Системе (см. раздел "Создание API-токена").

Важно! Для корректного запуска скрипта, необходимо отключить проверку подписи скрипта:

для отключения проверки только для заданного скрипта: Powershell -executionpolicy remotesigned -file 'deploy-windows-agent.ps1'

для отключения проверки в текущем сеансе: set-executionpolicy RemoteSigned -Scope Process

для отключения проверки любых PS-скриптов из командной строки PowerShell выполнить команду: set-executionpolicy remotesigned

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

С помощью установщика Агента

Другой способ массового развертывания Агентов на windows-активах - с помощью установщика Агента agent-windows-installer-x64-latest.msi (версии 1.1.69+), который находится в папке /var/lib/docker/volumes/manage_agents-volume/_data хоста Системы.

Перед запуском установщика на активах необходимо подготовить конфигурационный файл с названием agent-windows-installer.conf (или agent-windows-installer.json) и положить его рядом с файлом установщика:

{
  "account_id": "{account_id}",
  "user_id": "{user_id}",
  "api_token": "{api_token}",
  "api_url": "{api_url}",
  "is_new_asset_create": "1",
  "is_ignore_ssl_error": "0"
}

где:

account_id - id организации, в которой создается актив (раздел "Пользователи / Организации"),
user_id - id пользователя, от которого добавляется актив (раздел "Пользователи"),
api_token - токен, для доступа к методам API (см. ниже),
api_url - URL Системы в виде https://<ip> или https://<domain>,
is_new_asset_create - флаг создания нового актива в системе,
is_ignore_ssl_error - флаг игнорирования SSL ошибок.

Установщик Агента (с созданным конфигурационным файлом) нужно однократно запустить на Активах с помощью групповых политик или любых средств автоматизации. После завершения установки в Системе появятся все Активы, на которых был успешно установлен Агент.

На всех активах запускается один и тот же установщик и конфигурационный файл.

Примеры запуска установщика:

## С созданием лог-файла установки

msiexec /quiet /i "agent-windows-installer-x64-latest.msi" /l*v "install.log"

## Без использования конфигурационного файла:

msiexec /quiet /i "agent-windows-installer-x64-latest.msi" /l*v "install.log" \
ACCOUNT_ID="{account_id}" USER_ID="{user_id}" API_TOKEN="{api_token}" \
API_URL="{api_url}" IS_NEW_ASSET_CREATE="1" IS_IGNORE_SSL_ERROR="0"

## Если необходимо использовать прокси:

msiexec /quiet /i "agent-windows-installer-x64-latest.msi" /l*v "install.log" \
PROXY_URL="{proxy_url}" PROXY_LOGIN="{proxy_login}" PROXY_PASSWORD="{proxy_password}"

С использованием групповой политики

Существует возможность массовой установки Агента на windows-активах через групповые политики (Group Policy Object, GPO) с помощью установщика Агента agent-windows-installer-x64-latest.msi, который находится в папке /var/lib/docker/volumes/manage_agents-volume/_data хоста Системы.

Для массового развертывания Агентов с использованием GPO необходимо использовать MSI-файл установщика версии 1.2.20+, а также подготовить MST-файл преобразования, позволяющий изменить стандартные настройки пакета MSI.

Для создания файла модификации MST для MSI пакетов можно использовать утилиту ORCA (https://learn.microsoft.com/ru-ru/windows/win32/msi/orca-exe):

Необходимо открыть agent-windows-installer-x64-latest.msi с помощью утилиты Orca.
В программе нужно создать New Transformation и задать следующие параметры MSI-пакета в разделе Property:
- IS_NEW_ASSET_CREATE: 1
- IS_IGNORE_SSL_ERROR: 1
- ACCOUNT_ID: {account_id}
- USER_ID: {user_id}
- API_TOKEN: {api_token}
- API_URL: {api_url}

где:

account_id - id организации, в которой создается актив (раздел "Пользователи / Организации"),
user_id - id пользователя, от которого добавляется актив (раздел "Пользователи"),
api_token - токен, для доступа к методам API (см. ниже),
api_url - URL Системы в виде https:// или https://,
is_new_asset_create - флаг создания нового актива в системе,
is_ignore_ssl_error - флаг игнорирования SSL ошибок.

Добавляемые параметры в утилите Orca

Затем необходимо выбрать Transform→GenerateTransform и сохранить изменения в файл с раширение MST. Данный файл необходимо положить в одну папку с установщиком при создании политики GPO и указать в качестве модификации во вкладке «Modification».

Создание API-токена

Для автоматизированной установки Агентов используется API Системы, поэтому необходимо предварительно сгенерировать API-токен в разделе "Система / Настройки / API-токены" со следующими ограничениями:

Организации - укажите организацию, в которую будут импортироваться активы,
API-методы - укажите следующие методы:
- /integration/v1/agents
- /integration/v1/agents/download/installer/url
- /integration/v1/assets

Обновление агентов

После установки на Актив Агент самостоятельно соединяется с Системой и переходит в режим ожидания команд от Системы.

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

В целом процедура обновления Агента состоит из следующих шагов:

Система автоматически по заданному расписанию получает новые бинарные файлы Агентов по каналу обновления agent/* (см. раздел "Обновление БД уязвимостей / Каналы обновлений")
Агент, получив от Системы команду на обновление (в рамках выполнения соответствующей задачи), скачивает с сервера Системы новую версию бинарного файла.
Агент самостоятельно выполняет обновление до новой версии.
(Опционально) В случае неудачного обновления Агент самостоятельно производит откат на предыдущую рабочую версию.

Таким образом, регламентные работы по обновлению Агентов на Активах производятся непосредственно из Кабинета Системы ручным или автоматическим способом без использования сторонних средств администрирования.

Текущую версию установленного на Активе Агента можно узнать на детальной странице Актива.

Ручное обновление

Для ручного обновления Агентов необходимо запустить задачу типа "Активы / Обновление агентов":

Перейти на страницу "Аудит / Задачи" -> кнопка "Создать задачу"
Выбрать:
- тип задачи: "Активы",
- время запуска: "Сейчас" или "В заданное время",
- список активов, на которых необходимо обновить Агентов,
- действие: "Обновление агента"
Нажать кнопку "Создать задачу"

Задача будет запущена сразу или в заданное время. Агентам будет отправлена команда на обновление, а результат обновления Агентов будет отражен на детальной странице запуска задачи.

Автоматическое обновление по расписанию

Для автоматического обновления Агентов по расписанию необходимо создать периодическую задачу типа "Активы / Обновление агентов" (см. "Ручное обновление") с временем запуска "По Cron'у", задав нужное расписание запуска в формате CRON.

Важно: настройка по Cron'у указывается в часовом поясе UTC+0.

Переустановка агентов

При необходимости произвести переустановку Агента выберите меню "Агент / Переустановить" на детальной странице Актива. В открывшейся форме будут доступны индивидуальные для данного Актива установочные файлы Агента.

Процедура установки описана в разделе "Установка агентов / Ручная установка."

Удаление агентов

Linux

Для удаления Агента на linux-активе необходимо запустить команду:

/opt/vulns.io/agent-linux/agent_uninstall.sh

Windows

Удаление Агента на windows-активе осуществляется стандартными инструментами удаления программ ОС Windows.

Статусы агентов

В процессе своего жизненного цикла Агент может находиться в следующих статусах:

Онлайн - агент установлен на Актив, установил соединение с Системой и ожидает от нее команд.
Офлайн - агент установлен на Актив (или был установлен, но сейчас удален), соединения с Системой нет, не может выполнять команды.
Не активирован - агент еще не установлен на Актив (или вообще не будет установлен, если используется безагентный аудит с учетной записью).

Статусы Агентов отображаются в карточках активов, в разделе "Активы / Хосты", в списках активов внутри карточек уязвимостей, образов контейнеров и других разделах Кабинета, где выводятся списки активов.

Безагентное сканирование

Linux

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись в группе sudo/wheel или пользователь root.

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования linux-актива, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
Учетная запись проверяется на наличие необходимых прав доступа на активе.
С сервера Системы в директорию /tmp/vulns.io_agent-linux (или $HOME/vulns.io_agent-linux) автоматически скачивается не требующая установки версия агента.
Агент запускается с параметрами, соответствующими выполняемой Задаче.
Агент формирует результат выполнения задания в виде машиночитаемых файлов отчетов.
Файлы отчетов загружаются на сервер Системы.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится удаление агента, файлов отчетов и логов с актива.
Производится отключение от актива и закрытие сетевого соединения.

Windows

Требования к сетевым доступам и учетной записи

сетевая доступность актива по портам: 135,137-139,445,5985,5986 TCP/UDP c сервера Системы,
работающая служба WinRM,
работающая служба SMB,
учетная запись в группе "Администраторы".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования windows-актива, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу WinRM.
Производится подключение к активу с помощью привязанной учетной записи.
Учетная запись проверяется на наличие прав администратора на активе.
Создается директория C:\vulns.io-agent и предоставляется к ней общий сетевой доступ.
С сервера Системы в директорию C:\vulns.io-agent скачивается не требующая установки версия агента.
Агент запускается с параметрами, соответствующими выполняемой Задаче.
Агент формирует результат выполнения задания в виде машиночитаемых файлов отчетов.
Файлы отчетов загружаются на сервер Системы.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится удаление агента, файлов отчетов и логов с актива.
Производится отключение от актива и закрытие сетевого соединения.

Настройка службы WinRM

Для успешного подключения Системы к windows-активам на активах необходимо выполнить следующие команды в PowerShell:

> winrm quickconfig
y

При авторизации с ипользованием basic и ntlm необходимо дополнительно выполнить следующие команды в PowerShell:

> winrm set winrm/config/service/Auth '@{AUTH_TYPE="true"}'
> winrm set winrm/config/service '@{AllowUnencrypted="true"}'

где AUTH_TYPE - тип аутентификации(basic или ntlm).

При авторизации с использованием kerberos необходимо выполнить следующие команды в PowerShell:

> winrm set winrm/config/service/Auth '@{Kerberos="true"}'

Если при изменении параметров WinRM появляется следущая ошибка:

Исключение брандмауэра WinRM не будет работать, поскольку одно из сетевых подключений, установленных для этого компьютера, является общим. Измените тип сетевого подключения, либо на доменное, либо на частное и повторите попытку.

то необходимо зайти «Параметры» → «Сеть и интернет» → «Свойства» и изменить Сетевой профиль с «Общедоступным» на «Частный».

Настройка уровня проверки подлинности Network Security: LAN Manager

На некоторых серверных версиях Windows может потребоваться настройка параметра "Уровень проверки подлинности Network Security: LAN Manager", который определяет, какой протокол проверки подлинности "запрос/ответ" используется для входа в сеть:

Запустите консоль "Локальная политика безопасности" (Win+r, открыть secpol.msc).
Выберите "Локальные политики / Параметры безопасности".
Откройти политику "Сетевая безопасность: уровень проверки подлинности LAN Manager".
Выберите "Отправлять только NTLMv2 ответ".
Сохраните выбранный вариант.

Подробнее в документации Microsoft: https://learn.microsoft.com/ru-ru/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

Cisco

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий:
- "15" (Cisco IOS, Cisco NX-OS,Cisco IOS-XE, Cisco ASA),
- "config" (Cisco FTD),
- "access admin" (Cisco FMC).

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Cisco, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

terminal length 0
terminal pager 0
show version
show ip interface brief
show interfaces
show ip route
show clock
show cdp neighbors
show file systems
show inventory
show vlan brief
expert
ifconfig
route -n
echo -e "isoDate=$(date +%Y-%m-%dT%H:%M:%S.%N%z)\ntimeZone=$(date +%Z)"
echo -e "uptime=$(awk '{print $1}' /proc/uptime)"
clish

Mikrotik

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с политикой "ssh,read".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Mikrotik, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

:put [/system identity print as-value]
:put [/system resource print as-value]
:put [/ip address print as-value]
:put [/ipv6 address print as-value]
/interface print detail
:put [/ip route print as-value]
:put [/ipv6 route print as-value]
/system clock print
/ip neighbor print
:put [/interface vlan print as-value]
:put [/system package print as-value]
/user group print terse
:put [/user print as-value]

Huawei

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий "15".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Huawei, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

screen-length 0 temporary
display version
display ip routing-table
display ip interface brief
display clock
display memory-usage
display vlan brief

Fortigate

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий "super_admin" (read/write разрешения на службы).

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Fortigate, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

get system status
get system interface
get firewall info routing-table all
get system global
get system perf status
show system console
config system console
set output standard
end

Juniper

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий "admin" или "all".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Juniper, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

show version
show interfaces terse
show interfaces
show route
show system uptime
show system memory
show system storage
show vlans

Eltex

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий "15".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Eltex, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

terminal datadump
show interfaces status
show ip interface
show ipv6 interfaces
show ip route
show date
show vlan
show security zone-pair
show security zone-pair configuration
show system
show version
show system id
show interfaces
show clock

Palo Alto Network

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий "superreader".

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Palo Alto Network, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

set cli pager off
show system info
show interface logical
show interface management
show interface hardware
show routing route
show clock more
show system disk-space
show system resources | match "Mem :"
show running security-policy

Aruba

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий 15 (administrators)

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства Aruba, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

show system
show interface
show ip route
show clock
show vlan
show access-list
show lldp neighbor-info

CheckPoint

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
учетная запись с уровнем привилегий 15 (admin user)
оболочка /bin/bash

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства CheckPoint, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

hostname
clish -c "show version all"
clish -c "show interfaces all"
dmiparse System Product
route
echo -e "isoDate=$(date +%Y-%m-%dT%H:%M:%S.%N%z)\ntimeZone=$(date +%Z)"
echo -e "uptime=$( '{awk print $1}' /proc/uptime)"
cat /proc/meminfo
df -Th
mgmt_cli show access-layers --root true --format json
mgmt_cli show access-rulebase name "{layer_name}" --root true --format json
mgmt_cli show access-rule layer {layer_name} name {acces-rule_name} --root true --format json
cpinfo -y all
mgmt_cli -f json -r true show gateways-and-servers details-level full limit 500 | jq '.objects[]|."network-security-blades",."management-blades" | keys[]'

VMWare ESXi

SSH

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 22 / TCP c сервера Системы,
работающий SSH-сервер на активе,
пользователь root

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства ESXI, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SSH.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые команды в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых команд

esxcli system hostname get
esxcli system version get
esxcli network ip interface list
esxcli network ip interface ipv4 get
esxcli network ip route ipv4 list
date
esxcli system stats uptime get
esxcli software vib list
esxcli hardware memory get
esxcli network ip connection list
vim-cmd hostsvc/hostsummary | grep -e cpuModel -e numCpuCores
esxcli system process list
ls -ltr /vmfs/devices/disks/
esxcli storage filesystem list
vim-cmd vmsvc/getallvms | awk '{print $1}'
vim-cmd vmsvc/get.summary

SNMP

Требования к сетевым доступам и учетной записи

сетевая доступность актива по порту 161 / UDP c сервера Системы,
работающий SNMP-сервер на активе,
Для SNMP версии v1 или v2c группа public. Для версии v3 имя пользователя

Как происходит подключение и сканирование

В процессе выполнения задачи безагентного сканирования устройства ESXi, выполняются следующие этапы:

Проверяется сетевая доступность актива по протоколу SNMP.
Производится подключение к активу с помощью привязанной учетной записи.
На актив посылаются необходимые OID в зависимости от задачи.
Производится преобразование результата команды в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом сканирования.
Производится отключение от актива и закрытие сетевого соединения.

Список выполняемых OID

1.3.6.1.4.1.6876.1
1.3.6.1.2.1.25.6.3.1.2
1.3.6.1.2.1.1.1.0
1.3.6.1.2.1.1.5.0
1.3.6.1.2.1.2
1.3.6.1.2.1.31
1.3.6.1.2.1.4.34.1
1.3.6.1.2.1.1.3.0
1.3.6.1.2.1.25.1.2.0
1.3.6.1.2.1.4.24.7
1.3.6.1.2.1.25.6.3.1
1.3.6.1.2.1.25.4.2.1
1.3.6.1.2.1.6.20.1.4.1.4
1.3.6.1.2.1.7.7.1.8.1.4
1.3.6.1.4.1.6876.2.1.1
1.3.6.1.2.1.25.2.3.1.5.6
1.3.6.1.2.1.25.3.3.1.2
1.3.6.1.2.1.25.3.2.1.3
1.3.6.1.2.1.25.3.6.1
1.3.6.1.2.1.25.3.7.1
1.3.6.1.2.1.25.3.7.1
1.3.6.1.2.1.25.3.8.1

Важно

В ESXi v6.7 существует вероятность возникновения ошибки, при которой в любой момент времени может быть недоступна служба SNMP.

Данная проблема описана на официальном сайте docs.vmware.com и может быть исправлена путем установки требуемых патчей.

Более подробная информация: https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-esxi-671-release-notes.html

Альтернативное решение можно найти в базе знаний Broadcom по ссылке: https://knowledge.broadcom.com/external/article/318006/snmp-service-crashes-and-generates-snmpd.html

Активы

Актив - компьютер, сервер, виртуальная машина, гипервизор или сетевое устройство, мониторинг которого ведется с помощью Системы.

Добавление актива

Добавить актив в Систему по сути означает предоставить Системе доступ к Активу: агентным способом с помощью установки агента или безагентным способом по сети с использованием учетной записи. Далее Система начинает собирать с Актива необходимую информацию для аудитов, инвентаризации и комплайнса, либо выполняет процедуры обновления ПО на Активе (по команде пользователя или в рамках запланированных задач).

Для добавления Актива выберите меню "Добавить актив" на странице "Активы / Хосты".

Установка Агента

Процедура установки Агента описана в разделе "Агенты / Установка агентов" настоящего руководства.

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

Привязку учетной записи можно выполнить двумя способами:

в момент создания учетной записи в соответствующей форме,
на детальной странице Актива при нажатии "Учетная запись / Добавить".

Назначение параметров Актива

В момент создания можно назначить ряд параметров Актива, влияющих на приоритизацию уязвимостей по методике ФСТЭК:

важность (критическая, высокая, средняя, низкая),
тип актива (сервер, рабочая станция, другой),
влияние на периметр (да, нет).

Импорт активов с помощью скрипта

Имеется возможность массового автоматизированного добавления Активов по списку ip-адресов с привязкой существующей в Системе (добавленной ранее) учетной записи для безагентного сканирования.

Для импорта активов используется специальный bash-скрипт импорта https://download.vulns.io/onpremise/scripts/deploy-agentless.sh (скачать скрипт импорта) и подготовленный CSV-файл со списком ip-адресов/типов актива/ID учетных записей скачать шаблон CSV.

Подготовка CSV-файла

Перед началом импорта Активов необходимо подготовить файл импорта:

Скачайте шаблон или самостоятельно создайте текстовый CSV-файл с разделителями ";" и первой строкой IP-адрес;Имя актива;Тип актива (linux/windows);ID-учетной записи (значения условны, строка не будет учитываться при импорте).
Для каждого импортируемого Актива добавьте строку с данными импорта, например:
- 192.168.100.15;deb1;linux;5661788c-c237-41b1-9e72-be35f3dac6d9
- 192.168.120.23;local_server;windows;d5f7ea48-7959-49f9-8c79-fab1f9f8d7ff

где:

первое значение: ip-адрес актива,
второе значение: имя актива,
третье значение: тип актива [linux|windows],
четвертое значение: идентификатор ранее созданной в разделе "Система / Учетные записи" учетной записи для конкретного Актива.

Пример CSV-файла:

IP-адрес;Тип актива (linux/windows);ID-учетной записи
192.168.100.15;deb1;linux;5661788c-c237-41b1-9e72-be35f3dac6d9
192.168.120.23;local_server;windows;d5f7ea48-7959-49f9-8c79-fab1f9f8d7ff

Создание API-токена

Скрипт импорта использует API Системы, поэтому перед запуском скрипта необходимо сгенерировать API-токен в разделе "Система / Настройки / API-токены" со следующими ограничениями:

Организации - укажите организацию, в которую будут импортироваться активы,
API-методы - укажите следующие методы:
- /integration/v1/credentials
- /integration/v1/vaults
- /integration/v1/accounts
- /integration/v1/agents/download/installer/url
- /integration/v1/assets

Настройка скрипта импорта

Перед запуском скрипта импорта необходимо указать в теле скрипта следующие параметры:

API_KEY - API-токен для доступа к API Системы (см. выше),
VULNS_SERVER_IP - ip-адрес сервера Системы,
DOUBLE - флаг "Допускать/не допускать дубликаты активов":
- Если DOUBLE=1: допускать дубликаты, не проверять наличие ранее созданных активов,
- Если DOUBLE=0: не допускать дубликаты, скрипт проверит наличие ранее созданного актива с таким же ip-адресом и если такой актив уже создан ранее, то пропустит его,
INPUT_FILENAME - имя исходного csv-файла импорта (по умолчанию deploy-agentless-template.csv),
OUTPUT_FILENAME - имя файла с результатом работы скрипта (по умолчанию deploy-agentless-result.csv),
ACCOUNT_ID - ID-организации в системе, куда будут импортированы активы (по умолчанию 0),
USER_ID - имя пользователя в системе, от имени которого будет добавлен актив (по умолчанию 0 - суперпользователь),
другие параметры по усмотрению.

Запуск скрипта импорта

Скрипт импорта можно запустить на любой linux-машине, имеющей доступ к серверу Системы по 443 порту.

Перед запуском скрипта убедитесь, что в системе установлен пакет jq. В большинстве Linux ОС он уже предустановлен, однако при необходимости может быть установлен с помощью стандартного менеджера пакетов (например, командой sudo apt install jq в Debian/Ubuntu).

Примеры запуска:

## Запуск без параметров

./deploy-agentless.sh

## Запуск с параметром: можно указать ID-учетной записи, которая будет привязана
## ко всем добавленным активам. При этом учетные записи, указанные в csv-файлe,
## будут проигнорированы

./deploy-agentless.sh 5661788c-c237-41b1-9e72-be35f3dac6d9

В результате выполнения скрипта импорта:

В Системе появятся новые Активы:
- указанных типов,
- с привязанными ip-адресами,
- с привязанными учетными записями.
В папке, где запускался скрипт, появится файл OUTPUT_FILENAME с результатом работы скрипта.

Импорт активов из контроллера домена AD/LDAP

Создание УЗ типа AD/LDAP

При подключении к серверу авторизации для импорта активов используется заведенная в Системе учетная запись AD/LDAP. Перед добавлением сервера авторизации необходимо заранее создать учетную запись типа AD/LDAP.

Создать и изменить учетную запись можно в разделе Кабинета "Активы / Учетные записи / Учетные записи". При создании УЗ необходимо указать её тип в зависимости от подключаемого сервера авторизации: LDAP/activedirectory.

Дополнительная информация о полях указана в разделе Учетные записи::Создание учетной записи::LDAP/activedirectory.

Добавление сервера авторизации

Для осуществления импорта активов из AD/LDAP, необходимо добавить нужный сервер в Систему.

Управление серверами авторизации осуществляется в разделе Кабинета "Система / Пользователи / Серверы авторизации".

При добавлении сервера авторизации необходимо указать:

тип сервера: ldap или activedirectory,
имя сервера,
URL в формате ldap://192.168.1.100,
Base DN в формате dc=vulns,dc=example,dc=com,
учетную запись (для возможности импорта активов),
описание сервера (опционально).

В версии Системы 1.24.0+ привязать УЗ к серверу авторизации можно только в момент создания сервера.

Создание задачи импорта/синхронизации активов

Задачу можно создать:

в разделе "Аудит / Задачи",
с любой страницы Кабинета с помощью верхней панели меню,
повторить ранее выполненную задачу из истории задач.

Чтобы провести импорт активов или синхронизацию по расписанию, создайте соответствующую задачу:

Задайте имя задачи.
Выберите тип задачи Импорт активов/Синхронизация.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Укажите политику импорта:
- Контроллер домена, добавленный ранее,
- Учетная запись SSH (опционально, будет привязана к добавленным linux-активам),
- Учетная запись WINRM (опционально, будет привязана к добавленным windows-активам).
Укажите AD/LDAP группы, которые будут импортированы:
- для каждой группы можно задать следующую сортировку активов в Системе:
  - создать новую группу,
  - добавить в уже существующую группу,
  - не добавлять в группу.
Выберите требования к проверке на дублирование.
Нажмите Создать задачу.

Как проводится импорт/синхронизация активов

В процессе выполнения задачи "Импорт активов/Синхронизация", выполняются следующие этапы:

Производится подключение к AD/LDAP серверу с привязанной учетной записью.
На сервер посылается запрос в зависимости от контекста ("показать список групп" или "поиск активов на сервере").
Производится преобразование результата запроса в машиночитаемый вид.
На сервере Системы формируется запись в БД с результатом.
Производится отключение от сервера и закрытие сетевого соединения.

Результаты импорта/синхронизации активов

В результате выполнения задачи Импорт активов/синхронизация в Систему будут добавлены активы согласно указанным параметрам задачи. Также сформируется информация о результатах и шагах выполнения задачи. С подробными результатами импорта активов/синхронизации можно ознакомиться на странице Результат импорта активов/синхронизации, перейти на которую можно нажатием на выполненное действие задачи в столбце ДЕЙСТВИЕ со страницы детальной информации о задаче. На странице будут отображены результаты импорта и примененные политики импорта.

Управление активом

В Кабинете доступны следующие операции с Активом:

аудит уязвимостей,
инвентаризация,
установка обновлений,
привязка к группе активов,
привязка учетной записи,
создание отчетов,
обновление Агента,
изменение параметров Актива:
- важность (критическая, высокая, средняя, низкая),
- тип актива (сервер, рабочая станция, другой),
- влияние на периметр (да, нет),
работа со списком активов,
приоритизация активов по методике ФСТЭК или CVSS Score,
тэгирование произвольными текстовыми цветными метками,
удаление.

Все операции с Активами фиксируются в журналах задач и действий пользователей (доступны в разделе "Система / Журналы" Кабинета).

Группы активов

Система позволяет объединять Активы в группы, а затем использовать группы при запуске Задач.

Для создания группы выберите меню "Добавить группу" на странице "Активы / Группы".

Для добавления Актива в Группу выберите меню "Группы" на детальной странице Актива.

Аудит уязвимостей

Создание задачи аудита

При добавлении Актива Система проведет первичный аудит уязвимостей Актива автоматически.

Чтобы провести ручное сканирование или сканировать Актив по расписанию, создайте соответствующую задачу (на детальной странице Актива или в разделе "Аудит / Задачи"):

Задайте имя задачи.
Выберите тип задачи Активы.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие:
- Аудит уязвимостей.
Включите необходимые параметры:
- Использовать списки исключений,
- Без пересканирования,
- Аудит найденных Docker-образов.
Выберите область применимости: Хосты / Реестры / Образы контейнеров / Сетевые устройства / Группы.
Нажмите Создать задачу.

Как проводится аудит

Для проведения сканирования (аудита) уязвимостей на активе собирается и отправляется в Систему:

информация об операционной системе: название дистрибутива, версия,
список установленного программного обеспечения с версиями,
список установленных обновлений (для некоторых ОС).

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

Формируется результат сканирования:

список уязвимого ПО,
список доступных обновлений,
список найденных уязвимостей,
список отсутствующих обновлений безопасности (для некоторых ОС),
фиксируется список проанализированного ПО,
фиксируется сопутствующая метаинформация: дата и время сканирования, CVSS-метрики, критичность уязвимостей по методике ФСТЭК (V) и прочее.

Запускаемые команды

Linux

dpkg-query
rpm
apk list
qlist

Windows

Для аудита уязвимостей windows-активов не производится запуск консольных команд. Используется прямой доступ к WMI API и Windows registry API.

Аудит без пересканирования

При необходимости можно провести аудит уязвимостей на основе собранной ранее информации об Активе - без сбора актуальной информации здесь и сейчас. Для этого необходимо включить соответствующий параметр задачи Без пересканирования.

В этом случае обращение к Активу не производится, актуальная информация об Активе не собирается, но аудит проводится значительно быстрее.

Важно: аудит уязвимостей в режиме "без пересканирования" может не соответствовать реальной картине уязвимостей на Активе, т.к. с момента сбора информации с Актива на нем могли произойти значительные изменения, например: установлено новое ПО, удалены важные обновления и пр.

Результаты аудита уязвимостей

Результат аудита Актива содержит:

список уязвимого ПО с текущими версиями и найденными уязвимостями,
список доступных обновлений для уязвимого ПО,
список найденных уязвимостей с информацией:
- ID бюллетеня,
- описание,
- Severity,
- CVSS Score,
- CVSS Vector,
- CWE,
- V (критичность уязвимости по методике ФСТЭК),
- EPSS Score,
- EPSS Percentile,
- о наличии эксплойтов,
- о присутствии в базе CISA KEV,
- дата публикации,
- список связанных URL для дополнительного анализа,
- список связанных бюллетеней,
список отсутствующих обновлений безопасности (для некоторых ОС: например, KB для windows-систем) со статусом проверки обновления в БДУ ФСТЭК,
полный список проанализированного ПО с версиями.

Часть уязвимостей и уязвимого ПО может быть скрыта, если для этих уязвимостей настроены списки исключений! В этом случае в интерфейсе Кабинета будет отображаться соответствующее предупреждение, а скрытые данные всегда можно отобразить, нажав ссылку Показать исключенные данные.

Инвентаризация

Создание задачи инвентаризации

При добавлении Актива Система проведет первичную инвентаризацию Актива автоматически.

Чтобы провести ручное сканирование или сканировать Актив по расписанию, создайте соответствующую задачу (на детальной странице Актива или в разделе "Аудит / Задачи"):

Задайте имя задачи.
Выберите тип задачи Активы.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие:
- Инвентаризация.
Выберите область применимости: Актив/Активы или группу активов.
Нажмите Создать задачу.

Как проводится инвентаризация

Для проведения инвентаризации на активе запускается ряд системных команд ОС, собирается и отправляется в Систему подробная информация об активе:

сведения об операционной системе,
сведения о железе: CPU, память, диски,
информация о сетевых интерфейсах и маршрутах,
списки локальных групп и пользователей,
список установленного ПО с версиями,
список запущенных сервисов,
список обнаруженных docker-образов и запущенных контейнеров.

На стороне Системы для соответствующего актива формируется результат инвентаризации.

Собираемая информация

Информация о системе

Сведения о системе:
- имя хоста,
- UUID,
- аптайм,
- локальное время,
- часовой пояс,
- unix-время на активе.
Информация об операционной системе:
- имя,
- версия,
- тип,
- архитектура,
- платформа,
- дата установки.
Смонтированные устройства (для linux-систем):
- путь монтирования,
- тип устройства,
- общий размер, использовано, доступно.
Таблица маршрутизации.
Список сетевых интерфейсов с названиями, ip- и mac-адресами.
Список локальных пользователей.
Список локальных групп пользователей.

Информация о железе

Информация о CPU:
- модель,
- сокет,
- производитель,
- тип,
- количество ядер,
- количество логических ядер,
- текущая частота,
- максимальная частота,
- разрядность.
Физические диски:
- модель,
- производитель,
- серийный номер,
- идентификатор в системе,
- тип,
- объем,
- количество разделов,
- метка,
- подробная информация о разделах на диске.
Оперативная память:
- доступный объем памяти,
- свободный объем памяти,
- буферы,
- кэши,
- swap,
- физические модули памяти:
  - объем,
  - форм-фактор,
  - тип памяти,
  - номер банка,
  - производитель,
  - part number,
  - серийный номер,
  - разрядность,
  - скорость.

Программное обеспечение

Список установленного ПО:
- название,
- версия,
- занимаемый размер на диске,
- издатель,
- ссылка на сайт вендора,
- дата установки,
- место установки.

Запущенные службы

Список запущенных сервисов:
- имя,
- описание,
- статус,
- состояние,
- тип запуска,
- PID,
- путь к файлу описания.

Docker-контейнеры и образы

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

Запускаемые команды

Linux

dmidecode
hostname
arch
stat /etc/machine-id
awk /proc/uptime
ls
getconf LONG_BIT
ip
ip route
fdisk
udevadm info
fsck
df
systemctl list-units
systemctl show
which docker
docker images
docker inspect
dpkg-query
rpm
apk list
qlist

Windows

Для инвентаризации windows-активов не производится запуск консольных команд. Используется прямой доступ к WMI API и Windows registry API.

Контроль изменений

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

Для отображения изменений нажмите соответствующую иконку рядом с датой аудита или инвентаризации на карточке Актива. В открывшемся модальном окне отобразятся изменения между двумя последними сканированиями.

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

Установка обновлений

Linux

Система позволяет устанавливать обновления пакетов на Linux-активы: выборочно или для всех пакетов сразу.

Создание задачи обновления

Полное обновление всех пакетов

Чтобы провести полное обновление всех пакетов Актива, создайте соответствующую задачу (на детальной странице Актива или в разделе "Аудит / Задачи"):

Задайте имя задачи.
Выберите тип задачи Активы.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие:
- Обновление пакетов.
Выберите условие перезагрузки Актива:
- Нет - перезагрузка не будет выполняться,
- При необходимости - перезагрузка выполниться, если это потребуется для завершения установки отдельных пакетов,
- В любом случае - перезагрузка выполниться в любом случае.
Выберите область применимости Актив/Активы или группу активов.
Нажмите Создать задачу.

Выборочное обновление пакетов

Чтобы провести выборочное обновление пакетов Актива:

Перейдите на карточку Актива.
На вкладке "Уязвимости / Уязвимые пакеты" выберите пакеты, которые необходимо обновить.
Нажмите появившуюся кнопку Обновить выбранные пакеты
В появившейся форме добавления Задачи:
- задайте имя задачи,
- выберите время запуска,
- нажмите Создать задачу

Важно: выборочно можно обновить только те уязвимые пакеты, которые имеют новую версию с исправлением уязвимости.

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

Для проведения обновления на активе:

Запускается команда стандартного менеджера пакетов ОС.
Анализируется ответ выполненной команды.
Формируется результат выполнения задачи.
Вывод команды и сформированный результат отправляются в Систему.

Важно:

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

установка пакетов производится из репозиториев, настроенных на активе,

для установки агентным способом на Linux-активе необходима версия Агента 1.4.0+.

Запускаемые команды

Linux

dpkg-query
yum —version
yum update -y
zypper —version
zypper refresh
zypper update -y
urpmi —version
urpmi —auto package_name
urpmi —auto-update
apt-get —version
apt-get update
apt-get install -y package_name
apt-get upgrade -y

Результаты обновления

Результат обновления Актива содержит:

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

Windows

Система позволяет устанавливать обновления безопасности KB на Windows-активы.

Создание задачи обновления

Установка всех доступных KB

Чтобы провести установку всех доступных для Актива KB, создайте соответствующую задачу (на детальной странице Актива или в разделе "Аудит / Задачи"):

Задайте имя задачи.
Выберите тип задачи Активы.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие:
- Установка KB.
Выберите источник установки:
- По умолчанию - настроенный на Активе по умолчанию,
- Глобальный центр обновлений - общие сервера обновлений от компании Microsoft,
- Локальный WSUS - локальный сервер обновлений, настроенный на Активе.
Укажите необходимость перегружать Актив после установки обновлений:
- Нет - перезагрузка не будет выполняться,
- При необходимости - перезагрузка выполнится, если это потребуется для завершения установки отдельных KB,
- В любом случае - перезагрузка выполнится в любом случае.
Выберите Актив/Активы или группу активов.
Нажмите Создать задачу.

Выборочная установка KB

Чтобы провести выборочную установку KB на Актив:

Перейдите на карточку Актива.
На вкладке "Уязвимости / Отсутствующие KB" выберите обновления, которые необходимо установить.
Нажмите появившуюся кнопку Установить выбранные KB.
В появившейся форме добавления Задачи:
- задайте имя задачи,
- выберите время запуска,
- выберите источник установки,
- укажите необходимость перезагрузки,
- нажмите Создать задачу

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

Для проведения установки KB на активе:

С помощью запроса к Windows Update Agent API формируется список KB, доступных для установки на данном Активе.
Формируется список KB для скачивания (с учетом условий задачи).
Производится скачивание KB.
Производится установка KB.
Формируется результат выполнения задачи.
Результат отправляется в Систему.

Важно: для установки агентным способом на Windows-активе необходима версия Агента 1.2.0+.

Статус проверки обновлений из БДУ ФСТЭК

В карточках Windows-активов во вкладке "Уязвимости / Отсутствующие KB" отображаются результаты тестирования указанных обновлений KB по данным БДУ ФСТЭК России.

Статусы ФСТЭК для обновлений могут принимать следующие значения:

"В ходе тестирования обновления недекларированные возможности не выявлены",
"Обновление может быть установлено при определенных ограничениях",
"Обновление является небезопасным и устанавливать его не рекомендуется",
"Нет информации об обновлении от ФСТЭК".

Данная информация может быть использована при принятии решения об установке того или иного обновления.

Результаты установки

Результат установки KB на Актив содержит:

список установленных/не установленных/не найденных/удаленных KB,
логи выполнения задачи на Активе.

Образы контейнеров

Как образ появляется в системе

Образы контейнеров (как отдельная сущность) попадают в Систему при выполнении задач сканирования типа "Образы контейнеров", применяемых для хостов с образами, либо реестров образов.

После этого они становятся доступны в разделе "Активы / Образы". У каждого образа есть детальная страница с результатом аудита уязвимостей, описанием слоев и некоторой вспомогательной информацией об образе.

Управление образом

В Кабинете доступны следующие операции с образом контейнера:

запуск задачи «аудит уязвимостей»,
удаление образа из Системы.

Реестры образов

Добавление реестра

Для добавления реестра выберите меню "Добавить реестр" на странице "Активы / Образы".

В форме добавления реестра укажите:

произвольное имя для реестра,
URL реестра,
заранее созданную учетную запись типа container_registry,
произвольное описание для реестра,
при необходимости ограничить сканирование конкретными репозиториями добавьте имена этих репозиториев и маску для тэгов.

По умолчанию будут сканироваться все репозитории данного реестра. Если необходимо ограничить область сканирования конкретными репозиториями - укажите их, нажав 'Добавить репозиторий'

После добавления реестра необходимо запустить Задачу типа Образы контейнеров для первичного сканирования данного реестра.

На детальной странице реестра отображаются все просканированные репозитории и история Задач этого реестра.

Управление реестром

В Кабинете доступны следующие операции с реестрами образов контейнеров:

аудит уязвимостей образов в реестре,
редактирование настроек реестра,
добавление/изменение учетной записи для реестра,
удаление реестра,
получение вебхука для запуска сканирования реестра.

Вебхуки

Для каждого реестра контейнеров, добавленного в Систему, создается уникальный вебхук, обращение к которому запускает задачу сканирования на уязвимости образов данного реестра. Это позволяет извне управлять сканированием образов в реестре, например, сразу после сборки и загрузки нового образа в данный реестр.

Как получить URL вебхука:

Откройте детальную страницу реестра контейнеров.
Нажмите кнопку Вебхуки.
Скопируйте указанный URL, нажав кнопку Скопировать.

Для запуска вебхука:

Создайте API-токен с доступом к методу /integration/v1/webhooks/container-registries.
Выполните GET запрос к указанному URL с токеном в http-заголовке x-api-key.

Примеры использования:

curl -H "x-api-key: <API_KEY>"\
https://<HOSTNAME>/integration/v1/webhooks/container-registries/<REGISTRY_ID>

wget --header "x-api-key: <API_KEY>"\
https://<HOSTNAME>/integration/v1/webhooks/container-registries/<REGISTRY_ID>

Аудит уязвимостей

Создание задачи аудита

Чтобы провести ручное сканирование или сканировать образы по расписанию, создайте соответствующую задачу (в разделе "Аудит / Задачи"):

Задайте имя задачи.
Выберите тип задачи Активы.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие:
- Аудит уязвимостей.
Включите параметр:
- Аудит найденных Docker-образов
Выберите хосты с образами или реестры образов.
Нажмите Создать задачу.

Как проводится аудит

Сканирование образов контейнеров на хосте производится Агентом на данном хосте или с помощью безагентного подключения без запуска контейнеров.

О каждом обнаруженном docker-образе собирается и отправляется в Систему:

информация об операционной системе образа: название дистрибутива, версия,
список установленного в образе программного обеспечения с версиями,
размер образа, архитектура и идентификатор образа (sha256),
список слоев с информацией о каждом слое: дата создания, команда создания, размер, Layer ID.

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

Формируется результат сканирования образа:

список уязвимого ПО,
список доступных обновлений,
список найденных уязвимостей,
фиксируется список проанализированного ПО,
фиксируется сопутствующая метаинформация: дата и время сканирования, CVSS-метрики, критичность уязвимостей по методике ФСТЭК (V) и прочее.

Для проведения сканирования образов контейнеров в реестрах:

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

Система может сканировать образы в реестрах контейнеров, поддерживающих Docker Registry HTTP API V2.

Сканирование производится задачей типа "Образы контейнеров" с указанием хоста или реестра (см. раздел "Задачи").

Результаты аудита уязвимостей

Результат аудита образа содержит:

список уязвимого ПО с текущими версиями и найденными уязвимостями,
список доступных обновлений для уязвимого ПО,
список найденных уязвимостей с информацией:
- ID бюллетеня,
- описание,
- Severity,
- CVSS Score,
- CVSS Vector,
- CWE,
- V (критичность уязвимости по методике ФСТЭК),
- EPSS Score,
- EPSS Percentile,
- о наличии эксплойтов,
- о присутствии в базе CISA KEV,
- дата публикации,
- список связанных URL для дополнительного анализа,
- список связанных бюллетеней,
полный список проанализированного ПО с версиями,
список слоев с информацией о каждом слое: дата создания, команда создания, размер, Layer ID.

Часть уязвимостей и уязвимого ПО может быть скрыта, если для этих уязвимостей настроены списки исключений! В этом случае в интерфейсе Кабинета будет отображаться соответствующее предупреждение, а скрытые данные всегда можно отобразить, нажав ссылку Показать исключенные данные.

Сканирование в CI/CD

Сканирование образов контейнеров в CI/CD производится с помощью специального образа-компаньона и Vulns.io Common API, доступного в Системе.

Подробное описание процесса сканирования см. в разделе "Как работает сканирование / Сканирование образов контейнеров / В пайплайнах CI/CD"

GitLab

Требования к окружению

Для встраивания этапа сканирования целевого образа в пайплайн, необходимо выполнение следующих условий:

CI/CD пайплайн должен включать этап (stage) «test», в котором будет производиться сканирование,
в этапе «test» должен быть использован шаблон задачи сканирования образа (см. ниже),
Gitlab Runner должен быть настроен с параметром executor = "docker", работать на Linux/amd64-системе, и иметь установленный Docker версии 18.09.03 (или позднее).

Целевой образ после сборки может быть помещен в реестр контейнеров текущего проекта или в сторонний реестр контейнеров (в этом случае в настройках этапа "test" необходимо указать данные для авторизации в стороннем реестре).

Шаблон задачи сканирования

Для сканирования образа в CI/CD, необходимо добавить в файл .gitlab-ci.yml проекта сборки целевого образа следующий шаблон:

variables:
  CS_ANALYZER_IMAGE: hub.vulns.io/public/images-scanner:latest
  CS_SCHEMA_MODEL: 15
  SECURE_LOG_LEVEL: 'info'

  CI_REGISTRY: https://<url>
  CI_AUTH_TYPE: <basic|bearer>
  CI_AUTH_URL: <auth server url>
  CS_REGISTRY_USER: <username>
  CS_REGISTRY_PASSWORD: <password|token>
  CS_IMAGE: <full name of the image to be scanned>

  CI_API_URL: <url of cloud API or On-Premise server>
  CI_API_KEY: <API key>

  CI_ADD_LINKS: <true|false>
  CI_IS_HUB_DOCKER: <true|false>

container_scanning:
  stage: test
  image: "$CS_ANALYZER_IMAGE"
  artifacts:
    reports:
      container_scanning: gl-container-scanning-report.json
    paths:
      - ./audit_report.html
      - ./audit_result.json
      - ./gl-container-scanning-report.json
  script:
    - image_scan
  rules:
    - if: '$CI_PIPELINE_SOURCE == "web"'
    when: on_success
  allow_failure: false

Описание переменных

Параметр	Описание
CS_ANALYZER_IMAGE	Полное имя образа-сканера
CS_SCHEMA_MODEL	Версия спецификации, на основе которой генерируется отчет, интегрируемый в Gitlab
SECURE_LOG_LEVEL	Уровень логирования
CI_REGISTRY	Базовый URL реестра, в котором находится целевой образ
CI_IS_HUB_DOCKER	(необязательный параметр) При указании будет использоваться протокол hub.docker.com
CI_AUTH_TYPE	Тип авторизации: basic (логин/пароль) или bearer (по токену)
CI_AUTH_URL	URL сервера авторизации (требуется в случае bearer-авторизации)
CS_REGISTRY_USER	Логин для авторизации в реестре с целевым образом
CS_REGISTRY_PASSWORD	Пароль для авторизации в реестре с целевым образом
CS_IMAGE	Полное имя целевого образа, НЕ ВКЛЮЧАЯ URL реестр, только наименование образа и тэг (например, `group/project/image:latest`)
CI_API_URL	URL для используемого Vulns.io Common API (Система или облако)
CI_API_KEY	Токен для используемого Vulns.io Common API
CI_ADD_LINKS	При включении параметра в отчет об уязвимостях будут добавлены ссылки на бюллетени безопасности

Результаты аудита уязвимостей

В зависимости от тарифного плана, используемого в вашей установке GitLab, возможны следующие варианты отображения результатов аудита уязвимостей контейнеров:

	Free	Premium	Ultimate
HTML и JSON-отчет в артифактах задачи CI/CD	да	да	да
Во вкладке "Security" пайплайна	-	-	да
В Security-дашборде проекта	-	-	да
В разделе "Vulnerability Report" проекта	-	-	да

Для найденных уязвимостей собирается и отображается информация:

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

Информация об уязвимости в CI/CD GitLab

Jenkins

Требования к окружению

Для встраивания этапа сканирования целевого образа в пайплайн, необходимо выполнение следующих условий:

в CI/CD пайплайн добавляется этап (stage) "containerScan", в котором определяется задача сканирования в соответствии с шаблоном (см. ниже),
на машине с Jenkins должен быть установлен Docker версии 18.09.03 (или позднее),
в Jenkins необходимо установить следующие плагины:
- Docker API Plugin (v3.3.1-79 или позднее),
- Docker Commons Plugin (v439 или позднее),
- Docker Pipeline (v563 или позднее),
- Docker plugin (v1.4 или позднее),
- docker-build-step (v2.9 или позднее),
целевой образ после сборки может быть помещен в реестр контейнеров текущего проекта или в сторонний реестр контейнеров (в этом случае в настройках этапа "test" необходимо указать данные для авторизации в стороннем реестре).

Шаблон задачи сканирования

Для сканирования образа в CI/CD, необходимо добавить в Groovy-скрипт пайплайна сборки целевого образа следующий шаблон:

pipeline {
    environment {
        SECURE_LOG_LEVEL = 'info'
        CI_REGISTRY = 'https://<url>'
        CI_AUTH_TYPE = '<basic|bearer>'
        CI_AUTH_URL = '<auth server url>'
        CS_REGISTRY_USER = '<username>'
        CS_REGISTRY_PASSWORD = '<password|token>'
        CS_IMAGE = '<name of the image to be scanned>'
        CI_API_URL = '<url of cloud API or On-Premise server>'
        CI_API_KEY = '<API key>'
        CI_ADD_LINKS = '<true|false>'
        CI_IS_HUB_DOCKER = '<true|false>'
    }

    agent {
        docker {
            image "public/images-scanner:latest"
            registryUrl "https://hub.vulns.io"
            args '-u root:root'
        }
    }

    /* Preliminary stages (building, testing etc.) */

    stages {
        stage('containerScan') {
            steps {
                sh '/image_scan'
                sh 'cp /audit_result.json .'
                sh 'cp /audit_report.html .'
                sh 'cp /gl-container-scanning-report.json .'
            }
        }
    }

    post {
        always {
            archiveArtifacts artifacts: 'audit_result.json,
            gl-containerscanning-report.json, audit_report.html'
        }
    }
}

Описание переменных

Параметр	Описание
SECURE_LOG_LEVEL	Уровень логирования
CI_REGISTRY	Базовый URL реестра, в котором находится целевой образ
CI_IS_HUB_DOCKER	(необязательный параметр) При указании будет использоваться протокол hub.docker.com
CI_AUTH_TYPE	Тип авторизации: basic (логин/пароль) или bearer (по токену)
CI_AUTH_URL	URL сервера авторизации (требуется в случае bearer-авторизации)
CS_REGISTRY_USER	Логин для авторизации в реестре с целевым образом
CS_REGISTRY_PASSWORD	Пароль для авторизации в реестре с целевым образом
CS_IMAGE	Полное имя целевого образа, НЕ ВКЛЮЧАЯ URL реестр, только наименование образа и тэг (например, `group/project/image:latest`)
CI_API_URL	URL для используемого Vulns.io Common API (Система или облако)
CI_API_KEY	Токен для используемого Vulns.io Common API
CI_ADD_LINKS	При включении параметра в отчет об уязвимостях будут добавлены ссылки на бюллетени безопасности

Результаты аудита уязвимостей

Результаты аудита уязвимостей просканированного образа сохраняются в HTML и JSON-отчетах в артифактах задачи CI/CD.

Информация об уязвимости в CI/CD Jenkins

Учетные записи

Типы учетных записей

Система поддерживает следующие типы учетных записей:

ssh - для безагентного сканирования linux-активов и сетевых устройств,
winrm - для безагентного сканирования windows-активов,
container_registry - для сканирования образов контейнеров в реестрах,
hashicorp_vault_userpass - для подключения внешнего хранилища типа HashiCorp Vault (имя/пароль),
hashicorp_vault_token - для подключения внешнего хранилища типа HashiCorp Vault (токен),
snmp - для безагентного сканирования гипервизоров,
ldap - для импорта активов из контроллера домена LDAP,
activedirectory - для импортаЫ активов из контроллера домена Active Directory.

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

Создание учетной записи

Для добавления учетной записи выберите пункт меню “Создать учетную запись” на странице “Учетные записи”.

Общие поля для всех типов учетных записей:

хранилище учетных записей,
имя учетной записи,
описание.

SSH

Можно указать 2 типа реквизитов:

логин + пароль,
имя + ключ ssh (с парольной фразой при необходимости).

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

Важно! Для безагентного сканирования linux-активов необходима учетная запись с привилегиями sudo или находящаяся в группе root.

Использование ssh-rsa SHA1 ключей считается устаревшей практикой. Если используются такие ключи, то возможны ошибки подключения: "All configured authentication methods failed". Решением со стороны "хоста-актива" является добавление строки PubkeyAcceptedKeyTypes=+ssh-rsa в файл /etc/ssh/sshd_config и последующий рестарт SSH сервера командой systemctl restart sshd

Использование существующих SSH ключей

Содержимое публичного ключа должно быть в authorized_keys файле (root/.ssh/authorized_keys или /home/<USER>/.ssh/authorized_keys) на "хосте-активе".
Полное значение приватного ключа потребуется при создании SSH учетной записи через веб-интерфейс Системы.

Генерация SSH ключей

На любом Linux хосте сгенерировать приватный и публичный ключи следующей командой: ssh-keygen -t ed25519 -f ./key -C vulns.io_onpremise.
Содержимое файла публичного ключа ./key.pub полностью скопировать на "хост-актив" в authorized_keys файл (root/.ssh/authorized_keys или /home/<USER>/.ssh/authorized_keys). Это можно сделать вручную, либо выполнить команду ssh-copy-id -i ./key.pub <USER>@<IP_ADDRESS>.
Полное содержимое файла приватного ключа ./key потребуется при создании SSH учетной записи через веб-интерфейс Системы.

WinRM

Для создания учетной записи типа "WinRM" необходимо указать:

метод аутентификации:
basic,
ntlm
kerberos,
имя пользователя и пароль,
список хостов, к которым будет привязана данная учетная запись.

Важно! При создании учетной записи winrm с методом авторизации ntlm необходимо указать пользователя в формате FQDN, например user@domain.example. Для kerberos имя пользователя должно быть не в fqdn формате и не в формате DOMAIN\username. Например, если пользователь user@domain.example, то нужно указать user.

Для метода kerberos допонительно нужно указать:

IP адрес центра распределения ключей,
область, в которой расположен центр распределения ключа (должна соответствовать имени домена),

Container_registry

Укажите имя пользователя и пароль.

SNMP

Для создания учетной записи типа "SNMP" необходимо указать:

версию SNMP:
v1,
v2c,
v3;

Для версий v1 и v2c необходимо указать: * группу SNMP, * список хостов, к которым будет привязана данная учетная запись;

Для версии v3 необходимо указать: * имя пользователя, * протокол аутентификации: - md5, - sha, - sha224, - sha256, - sha384, - sha512; * уровень аутентификации: - noAuthNoPriv, - authNoPriv, - authPriv; * протокол конфиденциальности: - des, - aes, - aes256r; * ключ аутентификации; * ключ конфиденциальности; * список хостов, к которым будет привязана данная учетная запись.

LDAP

Для создания учетной записи типа "ldap" необходимо указать:

UID (Отображаемое имя ldap);
distinguished name (например, cn=Test User,cn=User,dc=example,dc=company, dc=com);
пароль;
список серверов, к которым будет привязана данная учетная запись.

activedirectory

Для создания учетной записи типа "activedirectory" необходимо указать:

имя пользователя и пароль;
список серверов, к которым будет привязана данная учетная запись.

hashicorp_vault_userpass

Укажите имя пользователя и пароль.

hashicorp_vault_token

Укажите имя пользователя и пароль.

Проверка учетной записи

После сохранения учетной записи можно проверить подключение к любому ip-адресу, используя эту запись.

Для этого в форме редактирования учетной записи в блоке "Проверить учётную запись" укажите ip-адрес и нажмите кнопку Проверить.

Управление учетной записью

В Кабинете доступны следующие операции с учетными записями:

редактирование,
удаление,
проверка подключения.

Все операции с учетными записями фиксируются в журналах действий пользователей (доступны в разделе “Система / Журналы” Кабинета).

Хранилище учетных записей

Для хранения учетных записей в Системе используется специальное защищенное хранилище HashiCorp Vault, которое обеспечивает безопасный и надежный способ хранения паролей, ssh-ключей и любых других реквизитов доступа.

Все данные в хранилище хранятся в зашифрованном виде и не могут быть извлечены обращением к методам REST API.

Подключение внешнего хранилища

Система позволяет подключить и использовать внешнее хранилище типа HashiCorp Vault.

Для этого необходимо:

Создать в Системе учетную запись типа hashicorp_vault_userpass или hashicorp_vault_token для подключения к внешнему хранилищу.
Создать хранилище учетных записей, указав:
организацию, к которой будет привязано хранилище,
имя хранилища (для внутреннего использования),
тип hashcorp_vault,
адрес, по которому доступно хранилище,
secret engine path,
созданную ранее учетную запись,
описание.

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

Важно: внешние хранилища могут создавать пользователи с ролями super_admin и account_admin.

Списки исключений

Списки исключений - механизм Системы, позволяющий скрыть из результатов аудита указанные уязвимости. Как правило, это относится к уязвимостям, которые по мнению пользователя Системы:

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

Особенности функционирования списков исключений в Системе:

возможно создание и использование множества списков исключений,
каждый список исключений содержит список бюллетеней и область применимости этого списка,
область применимости может быть ограничена:
- списком конкретных активов (хостами, образами, сетевыми устройствами),
- списком групп активов,
- списком типов активов.
список исключений можно редактировать, менять статус его активности,
в Задачах аудита уязвимостей можно явно отключить использование списков исключений,
списки исключений не учитываются при аудите через методы Common API,
списки исключений не учитываются при аудите docker-образов с помощью образа-компаньона в пайплайнах CI/CD (см. раздел "Образы контейнеров / Сканирование в CI/CD").

Влияние на результаты аудита уязвимостей

Работая со списками исключений необходимо учитывать следующее:

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

Создание списка исключений

Список исключений можно создать:

в разделе "Аудит / Списки исключений",
в карточке уязвимости,
в карточке Актива, выбрав любые из найденных уязвимостей на этом Активе,
в разделе "Обзор защищенности / Уязвимости", выбрав любые из найденных уязвимостей в инфраструктуре,
в разделе "Система / БДУ", выбрав любые уязвимости из справочника.

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

При создании необходимо указать:

Организацию, к которой будет привязан список исключений,
его название,
статус активности,
описание,
список бюллетеней,
область применимости.

Для того, чтобы список исключений применялся на всю инфраструктуру (все активы), необходимо в области применимости списка выбрать "Типы активов / Все типы активов".

Управление списком исключений

Для любого списка исключений доступны следующие операции:

редактирование,
деактивация / активация,
удаление.

Добавление KB в список исключений

В список исключений также можно добавить KB для Windows-активов.

Это относится к тем KB, которые по мнению пользователя Системы:

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

Список исключений для KB можно создать:

в карточке Актива, выбрав любые из отображенных отсутствующих на этом Активе KB.

При создании необходимо указать:

Организацию, к которой будет привязан список исключений,
его название,
статус активности,
описание,
список бюллетеней,
область применимости.

Задачи

Задачи - ассинхронный механизм выполнения всех основных функций Системы: действий с Активами, генерации отчетов, работы с накопленными данными, выполнения системных и других операций.

Механизм задач позволяет:

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

Для каждого запуска задачи фиксируется информация:

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

Создание задач

Задачу можно создать:

в разделе "Аудит / Задачи",
на детальной странице Актива,
со страницы запуска другой задачи.

В форме создания задачи:

Задайте имя задачи.
Выберите тип задачи.
Выберите время запуска:
- сейчас,
- в заданное время,
- по CRON'у.
Выберите действие.
Укажите дополнительные параметры, если необходимо.
Выберите область применимости: Активы / группу Активов / реестр контейнеров.
Нажмите Создать задачу.

Типы задач

Данная версия Системы поддерживает следующие типы задач:

Активы - для выполнения любых действий, связанных с Активами-хостам,
Отчеты - для генерации отчетов,
Импорт активов/Синхронизация - для импорта/синхронизации активов из LDAP/AD.

Общие параметры запуска

Время запуска

Задача может запускаться:

непосредственно в момент создания,
один раз в заданное время,
периодически в заданное время.

Для запуска в заданное время необходимо указать дату и время запуска.

Для запуска по расписанию необходимо указать периодичность в формате CRON вручную или с помощью встроенного CRON-калькулятора.

Важно: настройка по Cron'у указывается в часовом поясе UTC+0.

Выбор области применимости

Кроме задач типа Импорт активов/Синхронизация.

Область применимости задачи - набор активов/реестров, с каждым из которых будут произведены указанные в задаче действия.

Можно выбрать конкретные Хосты / Реестры контейнеров/ Образы контейнеров / Сетевые устройства / Группы Хостов.

Дополнительные параметры

В задаче могут быть доступны дополнительные параметры.

Для задач типа Отчеты можно указать:

тип отчета и формат генерируемого файла,
список email-адресов, куда будет отправлен сгенерированный отчет.

Для задач типа Активы с действием Аудит уязвимостей можно явно указать:

использовать ли списки исключений,
нужно ли провести аудит без пересканирования,
нужно ли провести аудит найденных образов контейнеров (на хостах или в реестрах).

Для задач типа Активы с действием Обновление пакетов можно явно указать:

нужно ли выполнить перезагрузку Актива после установки обновлений.

Для задач типа Активы с действием Установка KB можно явно указать:

источник установки,
нужно ли выполнить перезагрузку Актива после установки обновлений.

Для задач типа Импорт активов/Синхронизация можно указать:

политики импорта
контроллер домена,
учетные записи SSH и WINRM, которые будут добавлены к новым активам в соответствии с их типом;
группы для импорта с возможность создания новой группы в Системе/добавления в существующую группу,
проверку на дублирование импортируемых активов.

Параметры запуска для Активов

Действия

Действие определяет работу, которая будет выполнена в процессе запуска задачи.

Доступные в задаче действия зависят от типа задачи:

Аудит уязвимостей
Инвентаризация
Обновление агента
Обновление пакетов
Установка KB

К каждому типу активов можно применить определенный набор действий:

Действие	Хост	СУ	Образ	Реестр	Группа
Аудит	+	+	+		+
- использовать СИ	+	+	+		+
- без пересканирования	+	+	+		+
- аудит docker-образов	+			+	+
Инвентаризация	+	+			+
Обновление агента	+				+
Обновление пакетов	+				+
Установка KB	+				+

Результаты запуска

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

Если результатом выполнения действия является набор данных, то он будет доступен на отдельной странице по ссылке из вкладки "Результаты" страницы запуска задачи.

Для каждого результата указаны:

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

Статусы задач

Задача может находиться в следующих статусах:

Ожидание - периодическая задача не выполняется, ожидает запуска,
Выполняется - задача запущена и выполняется,
Выполнено - задача завершена и действия для всех активов успешно выполнены,
Не выполнено - задача завершена, но часть действий для некоторых активов не выполнены из-за ошибки,
Таймаут- задача завершена, но часть действий для некоторых активов не выполнены по таймауту*.

^* действие может завершиться по таймауту, если, например, не был получен ответ от Агента, установленного на Активе (компьютер выключен).

Артефакты

Если в результате выполнения задачи были созданы файлы (например, сгенерированы отчеты), то они будут доступны для скачивания во вкладке "Артефакты" страницы запуска задачи.

Для каждого файла указаны:

тип,
время создания,
размер,
ссылка на скачивания.

Журнал выполнения

Журнал выполнения задачи - подробный лог событий, происходящих при выполнении задачи Системой. Объем фиксируемых событий зависит от заданного уровня логирования: от минимального error до максимального debug.

Для каждого события фиксируется:

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

История выполнения

Каждый результат запуска любой задачи фиксируется и попадает в архив. Результаты выполнения задач доступны в разделе Кабинета "Аудит / История" и во вкладке "История задач" на детальной странице каждого Актива.

Дашборды

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

Дашборд уязвимостей

Дашборд по результатам сканирования уязвимостей содержит виджеты:

Топ-10 уязвимых активов,
Топ-10 уязвимостей по количеству активов,
Топ-10 уязвимостей по оценке V ФСТЭК,
Диаграмма CVSS Score,
Давность аудита,
Количество активов по типу,
Количество активов по типу проводимого аудита,
Общее количество уязвимостей,
Топ-10 уязвимого ПО,
Диаграмма статусов агентов,

Дашборд инвентаризации

Дашборд по результатам инвентаризации активов содержит виджеты:

Топ-10 версий Linux,
Топ-10 версий Windows,
Активы по ОС,
Всего активов,
Диаграмма статусов агентов,
Диаграмма давности инвентаризации,
Диаграмма типа аудита.

Отчеты

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

Типы отчетов

Текущая версия Системы поддерживает следующие типы отчетов:

Инвентаризация актива - в отчете отображается вся собранная на активе инвентаризационная информация.
Аудит уязвимости активов - в отчете отображаются все найденные на активе уязвимости.
Отчет о наличии указанных уязвимостей - в отчете отображается информация о наличии указанных уязвимостей в инфраструктуре или на конкретных активах, с расшифровкой результата проверки.
Топ-N уязвимостей (по количеству активов) - в отчете отображаются Топ-N уязвимостей в инфраструктуре или на конкретных активах.
Топ-N активов (по количеству уязвимостей) - в отчете отображаются Топ-N активов (по количеству уязвимостей) в инфраструктуре или на конкретных активах,
Дифференциальный отчет об уязвимостях - в отчете отображается динамика уязвимостей на активе за указанный период (закрытые, новые, изменение метрик).

Виды отчетов

Консолидированный отчет - содержит информацию о группе активов, имеет суммирующие таблицы, диаграммы и пр.
Индивидуальный отчет - содержит информацию только об одном активе.

Форматы отчетов

Данная версия Системы поддерживает генерацию отчетов в форматах:

PDF,
HTML.

Создание отчетов

Отчеты генерируются с помощью задач специального типа Отчеты (см. раздел Справки "Задачи / Создание задач").

В настройках задачи появляются дополнительные параметры:

выбор вида отчета,
выбор типа отчета,
выбор формата отчета.

Генерация по расписанию

Как и любая другая задача, генерация отчетов может выполняться по заданному расписанию (см. раздел Справки "Задачи / Параметры запуска / Время запуска").

Отправка на email

Для отправки сгенерированных отчетов на email необходимо указать их при создании Задачи типа Отчеты.

Есть 2 способа указать адреса:

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

Хранилище отчетов

Сгенерированные файлы отчетов хранятся в папке:

/opt/vulns.io/onpremise/data/artifacts/

База данных уязвимостей (контент)

Просмотр БДУ

Статистика

В разделе "Система / БДУ" доступны к просмотру и поиску все загруженные в Систему бюллетени уязвимостей.

Отображается статистическая информация по базе:

общее количество уязвимостей в БДУ,
количество каналов обновлений,
количество источников,
количество добавленных бюллетеней за сутки/неделю,
дата последнего обновления БДУ,
диаграмма количества бюллетеней по типу: CVE / Advisory / ФСТЭК / KB,
помесячное количество добавленных бюллетеней за послений год.

Поиск по базе уязвимостей

Можно найти любой бюллетень по его идентификатору, например: KB5006699, CVE-2023-43089, BDU:2020-05337, RHSA-2023:7370. А также отфильтровать список по дате добавления бюллетеня.

Как обновляется БДУ

Каналы обновлений

Канал обновления - условное понятие для определения потока обновлений различных разделов БД уязвимостей или Системы.

Каналы обновлений бывают:

системные - включены в поставку Системы, не зависят от Лицензии и не могут быть отключены пользователем,
лицензионные - подхватываются Системой из Лицензии, могут быть отключены пользователем.

Системные

Канал agent/* - бинарные файлы Агентов для различных операционных систем и разрядностей.
Канал service/* - метаданные базы уязвимостей, вспомогательные данные для проведения аудита уязвимостей.
Канал bulletins - база бюллетеней безопасности.

Лицензионные

Канал linux/* - уязвимости для всех поддерживаемых Vulns.io linux-дистрибутивов,
Канал windows/* - уязвимости для всех поддерживаемых Vulns.io версий ОС Windows и ПО для Windows.

Обновление по расписанию

Все активные каналы обновляются автоматически в соответствии с настроенным расписанием (см. документацию "Руководство администратора" раздел "Конфигурирование / Параметры конфигурационного файла").

Ручное обновление

Чтобы принудительно запустить обновление БД уязвимостей, необходимо перезапустить сервис data-updater командой:

/opt/vulns.io/onpremise/cli/vio-cli restart data-updater

Список сканируемого ПО и устройств

Операционные системы

Linux-дистрибутивы

Alma Linux 8, 9
Alpine 3.2 - 3.17
Amazon Linux 1, 2, 2023
Arch Linux
Centos 5 - 8
Debian 3 - 12
Fedora Linux (21+)
Gentoo
Manjaro Linux
openSUSE, openSUSE Leap
Oracle 5 - 8
RedHat 5 - 9
Rocky 8, 9
SUSE (SLED, SLES)
Ubuntu 12.04 - 22.10
Virtuozzo 6,7
Virtuozzo Hybrid Server 7
Altlinux 8, 9, 10
Astra Linux 1.6, 1.7, 4,7, 2.12
Rosa Cobalt 7.3, 7.9
Rosa Enterprise Desktop 7.3, 7.9
RedOS 7.3
МСВ Сфера
ОСнова

Версии Windows

Все текущие десктопные и серверные версии Windows

Программное обеспечение

Linux

Все пакеты из официальных репозиториев поддерживаемых linux-дистрибутивов

Windows

Полный список сканируемого ПО Windows содержится в отдельном документе "Список поддерживаемых операционных систем и программного обеспечения"

Сетевые устройства

Тип устройства / Вендор	Инвентаризация	Аудит уязвимостей
Маршрутизаторы
Cisco IOS	да	да
Cisco IOS-XE	да	да
Cisco NX-OS	да	да
Huawei (NetEngine)	да	да
Juniper (JunOS)	да	да
Fortinet (FortiOS)	да	да
MikroTik (RouterOS)	да	да
Eltex	да	да
Aruba	да	да
Межсетевые экраны
Cisco ASA	да	да
Cisco FTD	да	да
Cisco FMC	да	да
Huawei	да
Juniper (JunOS)	да	да
Fortinet (FortiOS)	да	да
Palo Alto (PAN-OS)	да	да
CheckPoint (Gaia OS)	да	да
Коммутаторы
Huawei (CloudEngine)	да	да
Eltex	да	да
Гипервизоры
VMWare ESXi	да	да

Профиль пользователя

Редактирование профиля

Для редактирования профиля пользователя наведите курсор на свое имя в статусной строке Кабинета и выберите пункт "Профиль".

В зависимости от текущей роли пользователя для редактирования доступны поля:

Организация,
Роль,
Статус,
Имя пользователя,
Логин,
E-mail,
Пароль.

Также в форме редактирования профиля отображаются:

ID пользователя,
ID организации, к которой принадлежит пользователь.

Двухфакторная авторизация

Любой пользователь Системы может настроить себе двухфакторную авторизацию (2FA). Рекомендуется сделать это для усиления защиты доступа к данным.

После включения 2FA для входа в Систему потребуются:

данные учетной записи пользователя (логин и пароль),
уникальный код, который генерируется специальным приложением для одноразовых паролей (Google Authenticator, Яндекс.Ключ и подобные).

Двухфакторная авторизация включается в профиле пользователя:

Откройте форму редактирование профиля.
Переведите переключатель "Двухфакторная аутентификация (2fa)" в положение "Включено".
Просканируйте отображенный QR-код приложением для одноразовых паролей.
Введите в форму сгенерированный код из приложения.
Сохраните предложенные резервные коды (с помощью этих одноразовых кодов можно будет войти в аккаунт в случае, если будет невозможно получить код через приложение).
Нажмие кнопку Подтверждаю, что коды сохранены.

Следующий вход в Кабинет Системы потребует ввода одноразового пароля из приложения.

Отключение двухфакторной авторизации также производится в профиле пользователя:

Откройте форму редактирование профиля.
Переведите переключатель "Двухфакторная аутентификация (2fa)" в положение "Выключено".