Skip to content

Руководство администратора

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

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

Архитектура решения

Архитектурно Vulns.io Enterprise VM является on-premise решением на физическом или виртуальном сервере, работающим в сети и на мощностях заказчика:

Система в сети заказчика

Компоненты системы

Описание компонентов Системы в соответствие элементам, указанным на схеме взаимодействия.

Сервисы, работающие в Системе:

  • mongodb - Main DB - хранение информации об активах, результатах сканирования, БДУ и пр.,
  • redisdb - Cache DB - очередь задач,
  • worker-main - Workers - выполнение задач аудита и инвентаризации активов в Системе,
  • worker-images-scanner - Workers - выполнение задач аудита и инвентаризации docker-образов (на хостах и в docker registry),
  • worker-reports - Workers - генерация отчетов,
  • worker-software-manager - Workers - обновление Windows-ПО,
  • logrotate - Workers - менеджер лог-файлов всех компонентов системы,
  • data-updater - Updater - запрос обновлений БДУ с Vulns.io Cloud и обновление локальной БДУ,
  • nginx - Reverse proxy - поддержка SSL, ограничение сетевого доступа,
  • centrifugo - Websocket server - поддержка двусторонней связи с Агентами,
  • cli - vio-cli - утилита командной строки, хранение исполняемого файла vio-cli и docker-сompose, используется при установке системы и обновлении на новую версию,
  • vault - Vault - хранилище учетных записей,
  • vault-init - Vault - инициализация хранилища в системе (подключение к vault),
  • frontend - Не указан как явный компонент - хранилище статистических файлов веб-интерфейса Системы,
  • api-server - Не указан как явный компонент - менеджер API-запросов, создает задачи для соответствующих воркеров на основе входящих запросов.

Представление активов заказчика в качестве компонентов Системы:

  • Asset with Agent - целевой актив с установленным агентом (физический/виртуальный хост)
    • vulns.io_agent - Agent - выполнение всех соответствующих типов задач на linux-активах/windows-активах,
  • Asset without Agent - целевой актив без агента (хост, сетевое устройство).

Web-сервисы, работающие на стороне вендора Vulns.io:

  • облачное API - для получения списка файлов обновлений,
  • сервер обновлений - для скачивания файлов обновлений БД уязвимостей,
  • сервер лицензирования - для проверки лицензии Системы,
  • реестр docker-контейнеров - для получения обновлений docker-контейнеров.

Схема взаимодействия компонентов Системы

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

  • физический сервер или виртуальная машина с поддержкой AVX-инструкций,
  • любой linux-дистрибутив, поддерживающий:
    • Docker 19.03.13+,
    • Docker Compose V1 1.29.0+ или Docker Compose V2 2.8.0+,
  • доступ в Интернет.

Конфигурация сервера

Количество активов Количество ядер Объем памяти Тип хранилища
до 100 6 24 ГБ HDD
100 - 500 8 32 ГБ HDD
500 - 2000 12 48 ГБ SSD
2000 - 5000 16 64 ГБ SSD
5000 - 10000 32 128 ГБ SSD
10000+ * * *

* Для инфраструктур с количеством активов 10000+ разворачивание системы рекомендуется производить на нескольких серверах с оркестрацией контейнеров Docker Swarm или Kubernetes (для получении рекомендаций и помощи обратитесь в техподдержку).

Разворачивание системы в Kubernetes позволяет организовать автоматическое масштабирование ключевых компонентов системы для ускорения сканирования больших инфраструктур.

Конфигурация хранилища

Ниже приведены примеры ориентировочных объемов хранилища для разных вариантов частоты сканирования (каждого актива тремя типами задач) и глубины хранения:

  • Вариант 1 - ежедневное сканирование, хранение истории 30 дней.
  • Вариант 2 - ежедневное сканирование, хранение истории 180 дней.
  • Вариант 3 - еженедельное сканирование, хранение истории 1 год.
  • Вариант 4 - еженедельное сканирование, хранение истории 3 года.
Количество активов Вариант 1 Вариант 2 Вариант 3 Вариант 4
до 100 36 ГБ 40 ГБ 37 ГБ 40 ГБ
100 - 500 40 ГБ 60 ГБ 42 ГБ 55 ГБ
500 - 2000 55 ГБ 130 ГБ 65 ГБ 120 ГБ
2000 - 5000 75 ГБ 270 ГБ 105 ГБ 240 ГБ
5000 - 10000 112 ГБ 500 ГБ 170 ГБ 440 ГБ

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

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

В интернет

Для установки и дальнейшего обновления решения серверу Системы требуется ряд сетевых доступов в сеть Интернет:

Доменное имя Порт Тип ресурса Предназначение
api.vulns.io 443 API Получение списка файлов обновлений
data.vulns.io 443 Сервер обновлений Получение файлов обновлений БДУ
hub.vulns.io
cr.yandex
storage.yandexcloud.net
443 Реестр
docker-контейнеров
Получение обновлений docker-контейнеров

Опционально может потребоваться доступ к следующим сайтам для установки Docker и Docker-compose:

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

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

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

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

С привилегиями sudo (или root)

Рекомендуется выполнять установку и обновление под пользователем root или пользователем с привилегиями sudo (возможностью выполнять действия с правами администратора).

В этом случае у пользователя будут все необходимые права для:

  • запуска docker-контейнеров,
  • записи в папку /opt,
  • создании символической ссылки в /usr/local/bin/vio-cli.

Без привилегий sudo

Если у пользователя нет административных прав, то необходимо выполнение следующих условий:

  • у пользователя есть права на запись в папку /opt,
  • пользователь находится в группе docker (см. документацию Docker),
  • после установки необходимо выполнить команду:
sudo ln -s /opt/vulns.io/onpremise/cli/vio-cli /usr/local/bin/vio-cli

Защищенное взаимодействие

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

Запросы Системы к web-сервисам, работающим на стороне вендора:

  • к API сервера обновлений, серверу лицензирования:
    • уникальный для конкретного экземпляра Системы ключ API для аутентификации,
    • шифрование по протоколу SSL,
  • при скачивании файлов с сервера обновлений:
    • уникальный временный подписанный URL с временем жизни не более 2 часов для аутентификации,
    • шифрование по протоколу SSL,
  • при доступе к реестру docker-контейнеров:
    • уникальная временная учетная запись с временем жизни не более 24 часов для аутентификации,
    • шифрование по протоколу SSL.

Запросы Системы к Активам при безагентном сканировании:

  • linux-активы и сетевые устройства:
    • логин/пароль или сертификаты для аутентификации,
    • шифрование по протоколу SSH,
  • windows-активы:
    • логин/пароль или сертификаты для аутентификации,
    • шифрование по протоколу SSL.

Запросы Агентов к Системе:

  • Агенты для linux- и windows-активов:
    • уникальный для каждого Агента ключ API для аутентификации,
    • шифрование по протоколу SSL.

Взаимодействие сервисов, работающих в Системе, между собой:

  • уникальные для конкретного экземпляра Системы учетные записи сервисов, генерируемые в процессе установки Системы.

Пользователи

Организация - обособленная сущность для объединения группы пользователей и активов. Пользователи Организации могут работать только с Активами своей организации.

Такой подход позволяет сегментировать Активы в компаниях со сложной структурой:

  • Организация 1
    • Пользователь 1
    • Пользователь 2
  • Организация 2
    • Пользователь 3
    • Пользователь 4
  • Организация 3...

Управление организациями и пользователями

Добавление, редактирование и удаление пользователей и организаций осуществляется в разделе Кабинета "Система / Пользователи".

Статусы и типы пользователей

Статусы:

  • Активен - может авторизовываться и работать в Кабинете.

  • Не активен - не может авторизовываться в Кабинете.

Типы:

  • Системный - пользователь, который создается при установке Системы. Данный пользователь не может быть удалён.

  • Пользовательский - пользователи, созданные администраторами Системы.

  • Active Directory - пользователи каталога AD, которые могут авторизоваться в Кабинете Системы.

  • LDAP - пользователи каталога LDAP, которые могут авторизоваться в Кабинете Системы.

Роли пользователей

  • Суперадминистратор (super_admin) - полные права на работу с данными всех организаций, создание организаций, управление любыми пользователями, конфигурирование и обновление системы.

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

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

  • Пользователь организации (только чтение) (reader) - имеет доступ только в рамках своей организации: просмотр состояния инфраструктуры, создание задач (аудит, инвентаризация, генерация отчетов)

Подробное описание прав доступа каждой из ролей указано в ПРИЛОЖЕНИИ 1. "Ролевая модель: матрица прав доступа".

Серверы авторизации

Для того, чтобы пользователи каталога AD/LDAP могли авторизоваться в Кабинете и работать в Системе, необходимо предварительно создать соответствующий сервер авторизации. Затем указать этот сервер при создании пользователя Системы.

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

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

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

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

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

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

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

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

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

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

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

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

Журналирование действий

Любые действия пользователей Системы, связанные с созданием/удалением сущностей, внесением изменений в существующие сущности, а также события, связанные с авторизацией в Системе, сменой пароля и прочие, сохраняются в журнал "Действия пользователей", который доступен в разделе "Система / Журналы".

Для каждого события сохраняются:

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

Конфигурирование

Конфигурационный файл config.ini

Основной конфигурационный файл Системы: /opt/vulns.io/onpremise/config/main/config.ini

Пример содержимого:

[cloud.api]
url = https://api.vulns.io/onprem/v1
key = 1234567890987654321234567890

[docker.registry]
type = primary

[api]
use_cache = true
debug_mode = false
agent_access_token_expiration = 259200
access_token_expiration = 300
user_password_max_age = 90
user_max_unsuccessful_login_attempts = 4
user_used_passwords_max_number = 3

[log]
level = info

[data-updater.scheduler]
cron = 0 * * * *
cron_type = cron

[data-updater.subscriptions]
channels = linux/*, bulletins, windows/*

[data-updater.other]
mongodb_bulkwrite_size = 10000

[smtp.sender]
name = Test name
email = mail@client.com

[smtp.transport.auth]
user = example@yandex.ru
password = 123123

[smtp.transport.smtp]
host = smtp.yandex.ru
port = 25
secure = true

#[smtp.transport]
#service = Yandex
Параметры конфигурационного файла
Параметр Описание
[cloud.api]
url URL облачного API Vulns.io
key Ключ API Vulns.io
[cloud.api.proxy]
protocol Протокол прокси для запросов к облачному API Vulns.io
host Hostname/IP прокси для запросов к облачному API Vulns.io
port Номер порта прокси для запросов к облачному API Vulns.io
[cloud.api.proxy.auth]
username Пользователь прокси для запросов к облачному API Vulns.io
password Пароль пользователя прокси для запросов
к облачному API Vulns.io
[docker.registry]
type Реестр контейнеров для обновления системы: primary
[api]
use_cache Использовать кэш при аудите уязвимостей
(ускоряет процесс аудита)
debug_mode Режим DEBUG аудита уязвимостей (в логах появится
расширенная информация о метриках процесса аудита)
agent_access_token_expiration Время жизни токена доступа Агентов
access_token_expiration Время жизни токена доступа в Кабинете
user_password_max_age Время жизни пользовательских паролей в днях
(после истечения потребуется смена)
user_max_unsuccessful_login_attempts Количество попыток ввода пользовательского пароля
до показа капчи
user_used_passwords_max_number Количество хранимых ранее использованных пользователем
паролей для проверки их уникальности
jwt_secret JWT-ключ
ssh_timeout Таймаут SSH-сокета (с)
ssh_ready_timeout Таймаут завершения SSH handshake (при подключении) (с)
ssh_connection_retry_delay Период ожидания между попытками подключения (с)
winrm_timeout Таймаут при подключении по WinRM (с)
pdf_render_timeout Таймаут рендеринга PDF (с)
api_key_salt Соль API ключа
user_task_timeout Таймаут выполения задачи пользователя (мс)
agent_queue_job_timeout Таймаут ожидания задачи агента в очереди (мс)
task_sentinel_cron Период проверки статусов пользовательских задач
[log]
level Уровень системного логирования (для логов в
/opt/vulns.io/onpremise/logs/*): info|verbose|debug
[log.file]
enabled Включена/отключена запись в файл (true/false)
level Уровень логирования сообщений в файл: info|verbose|debug
[log.db]
enabled Флаг включения логирования сообщений приложения
в БД (true/false)
[log.db.system]
level Уровень логирования системных сообщений приложения
в БД: info|verbose|debug
[log.db.task]
level Уровень логирования задач приложения
в БД: info|verbose|debug
[log.db.user]
level Уровень логирования действий пользователей приложения
в БД: info|verbose|debug
[data-updater.scheduler]
cron Расписание проверки каналов обновлений (в формате CRON)
cron_type Тип механизма периодической проверки: cron
[data-updater.subscriptions]
channels Каналы обновления
[data-updater.other]
mongodb_bulkwrite_size Обновлять данные в БД пачками по
disable_mongodb_index_creation Флаг отключения создания индексов в MongoDb
для обновления данных (true/false)
disable_agent_channel Флаг отключения канала обновления агентов (true/false)
[smtp.sender]
name Имя отправителя в исходящих письмах
email Email отправителя в исходящих письмах
[smtp.transport.auth]
user Имя пользователя для подключению к SMTP-серверу
password Пароль пользователя для подключению к SMTP-серверу
[smtp.transport.smtp]
host Hostname или ip-адрес SMTP-сервера
port Порт SMTP-сервера
secure SSL (true/false)
[smtp.transport] [Альтернативно настройкам smtp.transport.smtp]
service Сервис почтовой службы (например: "Yandex", "Mail.ru", "Gmail")
см. полный список
[http.client]
request_logging Включает логирование запросов
response_logging Включает логирование ответов
request_timeout Таймаут запроса к почтовому серверу
tls_reject_unauthorized Разрешить/запретить отклонять неавторизованные запросы
(true/false)
[mongodb]
mongodb_ip Адрес подключения к MongoDB
mongodb_port Порт подключения к MongoDB
mongodb_auth_database Имя базы данных аутентификации MongoDB
mongodb_user Имя пользователя Mongodb
mongodb_password Пароль для подключения к Mongodb
[redis]
redis_password Пароль для подключения к Redis
redis_ip Адрес подключения к Redis
redis_port Порт подключения к Redis
[centrifugo.api]
protocol Протокол Centrifugo API
host Адрес подключения к хосту Centrifugo API
port Порт подключения к хосту Centrifugo API
apiKey API-ключ подключения к Centrifugo

После изменения параметров в конфигурационном файле необходимо перезапустить Систему командой:

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

Доменное имя

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

  1. Откройте конфигурационный файл: /opt/vulns.io/onpremise/config/nginx/api.conf
  2. Укажите новое доменное имя в директиве server_name
  3. Перезапустите сервис Nginx командой:
/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Важно: если Система настроена на использование SSL-соединения, необходимо перевыпустить сертификат на новое доменное имя!

SSL-сертификаты

Установка сертификата от Certificate Authority

Используемый для SSL-соединения сертификат должен храниться в каталоге /opt/vulns.io/onpremise/config/ssl/.

  1. Подготовьте SSL-сертификат и секретный ключ в формате PEM.
  2. Назовите их api.crt и api.key и поместите в каталог /opt/vulns.io/onpremise/config/ssl/.
  3. Раскомментируйте или добавьте в конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf настройки SSL:
listen 443 ssl;

if ($scheme = http) { return 307 https://$host$request_uri; }
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /opt/vulns.io/onpremise/config/ssl/api.crt;
ssl_certificate_key /opt/vulns.io/onpremise/config/ssl/api.key;

Перезапустите Nginx командой:

/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Откройте в браузере адрес Кабинета и проверьте правильность настройки сертификата.

Установка самоподписанного сертификата

Используемый для SSL-соединения сертификат должен храниться в каталоге /opt/vulns.io/onpremise/config/ssl/.

Выполните команду генерации сертификата (параметр '-days' определяет срок действия сертификата):

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout /opt/vulns.io/onpremise/config/ssl/api.key \
-out /opt/vulns.io/onpremise/config/ssl/api.crt

В процессе выполнения команды введите запрашиваемую информацию, в том числе доменное имя сервиса (например, vulns.company.local).

В каталоге /opt/vulns.io/onpremise/config/ssl/ появятся файлы сертификата и секретного ключа: api.crt и api.key.

Раскомментируйте или добавьте в конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf настройки SSL:

listen 443 ssl;

if ($scheme = http) { return 307 https://$host$request_uri; }
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /opt/vulns.io/onpremise/config/ssl/api.crt;
ssl_certificate_key /opt/vulns.io/onpremise/config/ssl/api.key;

Перезапустите Nginx командой:

/opt/vulns.io/onpremise/cli/vio-cli restart nginx

Откройте в браузере адрес Кабинета и проверьте правильность настройки сертификата.

Ограничение доступа по IP-адресам

По умолчанию доступ к Системе и API Системы открыт для любых сетевых адресов.

Для того, чтобы ограничить/открыть доступ на сетевом уровне, выполните следующие шаги:

  1. Откройте конфигурационный файл /opt/vulns.io/onpremise/config/nginx/api.conf
  2. С помощью директив allow и deny определите необходимые доступы.
  3. Перезапустите Nginx командой /opt/vulns.io/onpremise/cli/vio-cli restart nginx

Примеры:

allow 192.168.30.88; ## разрешает доступ с ip-адреса
deny 192.168.42.0/24; ## запрещает доступ из сети 192.168.42.0/255.255.255.0
deny all; ## запрещает доступ

Проксирование HTTP/HTTPS запросов

Проксирование запросов к реестру образов Docker

В процессе установки / обновления продукта происходят запросы к реестру образов Docker.

Документация по настройке прокси Docker

Проксирование запросов к облачному API Vulns.io

В процессе работы продукта происходят регулярные запросы к облачному API Vulns.io

Чтобы настроить прокси нужно добавить в главный конфигурацинный файл /opt/vulns.io/onpremise/config/main/config.ini следующие секции:


[cloud.api.proxy]
protocol = https
host = 127.0.0.1
port=9000

[cloud.api.proxy.auth]
username = foo
password = bar

Сохранить изменения конфигурационного файла и перерестартовать сервисы worker-main и data-updater:

vio-cli restart worker-main data-updater

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

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

  • по списку организаций,
  • по списку активов или групп активов (в т.ч. сетевых устройств или docker-образов),
  • по списку конкретных методов API,
  • по списку ip-адресов, с которых будет вызываться API Системы.

Управление токенами доступно в разделе "Настройки / API-токены".

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

  • название,
  • описание,
  • список ограничений.

Важно: API-токен нельзя изменить! При необходимости удалите токен и создайте новый.

Токен необходимо передавать в 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>

Логирование

Компоненты Системы пишут логи в своих папках в /opt/vulns.io/onpremise/logs:

  • /opt/vulns.io/onpremise/logs/cli - логи утилиты командной строки vio-cli,
  • /opt/vulns.io/onpremise/logs/data-updater - логи системы обновления БД уязвимостей,
  • /opt/vulns.io/onpremise/logs/nginx - логи реверс-прокси сервера Nginx,
  • /opt/vulns.io/onpremise/logs/worker-main - логи воркеров.

Уровень логирования можно изменить в конфигурационном файле /opt/vulns.io/onpremise/config/main/config.ini (см. раздел "Конфигурирование").

Ротация и срок хранения логов

Ротация лог-файлов происходит каждые сутки автоматически, хранятся последние 10 файлов.

Обновление БД уязвимостей

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

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

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

  • системные - включены в поставку Системы, не зависят от Лицензии и не могут быть отключены пользователем,
  • лицензионные - подхватываются Системой из Лицензии, могут быть отключены пользователем.
Системные
  • Канал agent/* - бинарные файлы Агентов для различных операционных систем и разрядностей.
  • Канал service/* - метаданные базы уязвимостей, вспомогательные данные для проведения аудита уязвимостей.
  • Канал bulletins - база бюллетеней безопасности.
Лицензионные
  • Канал linux/* - уязвимости для всех поддерживаемых Vulns.io linux-дистрибутивов,
  • Канал windows/* - уязвимости для всех поддерживаемых Vulns.io версий ОС Windows и ПО для Windows.

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

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

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

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

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

Контроль целостности обновлений

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

Загрузка файлов обновлений БДУ и бинарных файлов Агентов осуществляется по защищенному каналу связи с использованием протокола SSL.

Обновление установленных агентов

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

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

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

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

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

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

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

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

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

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

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

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

Лицензирование

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

Лицензия "Vulns.io Enterprise VM" определяет:

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

Лицензия является именной, имеет уникальный Ключ и поставляется в активированном виде в специальном файле license.txt, наличие которого является обязательным для установки и эксплуатации Системы.

Вместе с файлом лицензии заказчик получает ключ к облачному API Vulns.io, посредством которого Система получает обновления. Действие ключа API синхронизировано со сроком действия лицензии.

Лимит активов

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

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

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

Подробнее о каналах обновлений смотри в разделе "Обновление БД уязвимостей / Каналы обновлений"

Срок лицензии

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

Продление лицензии

Для продления лицензии необходимо:

  1. Получить новый файл лицензии license.txt.
  2. Заменить им существующий файл /opt/vulns.io/onpremise/config/main/license.txt
  3. Перезапустить сервисы командой:
/opt/vulns.io/onpremise/cli/vio-cli restart data-updater worker-main

Апгрейд лицензии

Процедура апгрейда Лицензии полностью повторяет процедуру продления (см. выше).

Защита файла лицензии

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

Производительность

Скорость сканирования инфраструктуры Системой в целом зависит от следующих факторов:

  • производительности базы данных (сервис mongodb),
  • количества сервисов worker-main (воркеров), обрабатывающих задачи сканирования,
  • количества других параллельно выполняемых задач: генерации отчетов, обновления БД и прочих.

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

  • Вертикальное масштабирование:

    • увеличение количества ядер CPU сервера и количества воркеров worker-main,
    • использование высокоскоростных NVMe накопителей.
  • Горизонтальное масштабирование:

    • запуск Системы на нескольких серверах с помощью оркестрации Docker Swarm или Kubernetes.

Один сервер: увеличение количества воркеров

В случае, если Система запущена на единственном сервере, рекомендуется определить количество воркеров worker-main по следующей схеме:

  • по одному ядру выделить на сервисы: mongodb, redisdb, nginx, centrifugo, data-updater,
  • одно ядро выделить на работу операционной системы,
  • остальные ядра выделить на сервисы worker-main.

Для того, чтобы изменить количество запускаемых сервисов worker-main, необходимо:

  1. В файле /opt/vulns.io/onpremise/config/manage/docker-compose.yml изменить параметр services.worker-main.deploy.replicas (по умолчанию: 4).
  2. Пересоздать сервисы worker-main командой:
/opt/vulns.io/onpremise/cli/vio-cli recreate worker-main

Запуск в режиме Docker Swarm или в Kubernetes

Для получении рекомендаций и помощи по развертыванию Системы в режиме Docker Swarm или в инфраструктуре Kubernetes обратитесь в техподдержку компании "Фродекс": support@frodex.ru

Регламентные работы

Обновление системы

Обновление Системы осуществляется с помощью команды:

/opt/vulns.io/onpremise/cli/vio-cli update

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

Контроль целостности обновлений Системы

Осуществляется встроенный контроль целостности docker-образов Системы. При скачивании каждого образа проверяется идентификатор образа (sha256 хеш), который сравнивается с полученным в процессе сеанса установки/обновлений. Это обеспечивает неизменность и безопасность получаемых обновлений.

Данная проверка осуществляется при установке/обновлении Системы штатными средствами Системы: инсталлера vio-installer или утилитой командной строки vio-cli update

Загрузка обновлений Системы осуществляется по защищенному каналу связи с использованием протокола SSL.

Мониторинг дискового пространства

Основные каталоги дискового хранилища, которые необходимо мониторить:

  • /opt/vulns.io/onpremise/data/mongodb/ - основная база данных Системы (активы, результаты сканирования, уязвимости и пр.), растет по мере добавления Активов и выполнения задач по их сканированию,
  • /opt/vulns.io/onpremise/data/artifacts/ - хранилище сгенерированных файлов отчетов, растет по мере выполнения задач генерации отчетов,
  • /opt/vulns.io/onpremise/logs/ - хранилище логов сервисов Системы, ротируется согласно внутренним настройкам (см. раздел "Логирование"),
  • /var/lib/docker/volumes/manage_agents-volume/ - хранилище бинарных файлов Агентов для разных операционных систем и разрядностей, растет по мере скачивания Системой новых версий Агентов с сервера обновлений Vulns.io.

Интерфейс командной строки (vio-cli)

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

Расположение утилиты: /opt/vulns.io/onpremise/cli/vio-cli

Общий синтаксис выполнения команд:

vio-cli [options] [COMMAND] [SUBCOMMAND]

Параметры утилиты:

Параметр Назначение параметра
-V, --version Выводит текущую версию утилиты
-h, --help Выводит описание команд утилиты

status

Отображает статус состояния сервисов Системы:

vio-cli status

Пример вывода для нормально функционирующей Системы:

✔ Getting status from services ...
    Name                  Command               State                     Ports
-----------------------------------------------------------------------------------
centrifugo     centrifugo -c config.json        Up       0.0.0.0:8000->8000/tcp
cli            node /cli-entrypoint.bundl ...   Exit 0
data-updater   docker-entrypoint.sh /app/ ...   Up
frontend       /entrypoint.sh                   Exit 0
manage_api_1   /app/api                         Up       0.0.0.0:49169->3000/tcp
manage_api_2   /app/api                         Up       0.0.0.0:49170->3000/tcp
mongodb        docker-entrypoint.sh mongod      Up       0.0.0.0:27017->27017/tcp
nginx          /docker-entrypoint.sh ngin ...   Up       0.0.0.0:443->443/tcp
redisdb        docker-entrypoint.sh redis ...   Up       0.0.0.0:6379->6379/tcp

Важно: Статус "Exit 0" у сервисов cli, frontend и vault-init является нормальным состоянием для этих сервисов.

Возможные статусы сервисов:

  • Restarting - сервис в процессе перезапуска,
  • Up - сервис запущен и успешно работает,
  • Paused - сервис остановлен,
  • Exit (code) - сервис был запущен, а затем завершен с указанным кодом

update [services...]

Обновляет Систему полностью или только указанные сервисы:

vio-cli update

Важно: процесс обновления вызывает остановку всех сервисов Системы, в том числе прерывает работу Кабинета и API.

enter <service>

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

vio-cli enter mongodb

start [services...]

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

vio-cli start

stop [services...]

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

vio-cli stop

restart [services...]

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

vio-cli restart nginx

recreate [services...]

Пересоздает все или выбранные контейнеры сервисов Системы (hard restart, данные не уничтожаются):

vio-cli recreate nginx

remove [services...]

Останавливает работу всех или выбранных сервисов Системы и удаляет соответствующие контейнеры (данные не уничтожаются):

vio-cli remove nginx

stats mongodb

Отображает размера частей БД, составляющих архивные данные, логи и итоговый размер:

vio-cli stats mongodb

clear logs [--type, --date]

Удаляет данные логов из БД:

  • запуск без параметров удаляет данные логов задач старше 24 часов,
  • --type указывает, какой тип логов необходимо удалить (по умолчанию task):
    • task - логи, созданные при выполнения задач,
    • system - прочие логи, созданные Системой,
  • --date указывает момент времени, до которого необходимо удалить логи.
vio-cli clear logs —date 2024-01-01T00:00:00Z —type task

backup <mongodb | configs | all>

Создает бэкап основной БД и/или конфигурационных файлов.

mongodb

Процесс бэкапа происходит без полной остановки контейнера mongodb. Возможна потеря некоторых "свежих" данных.

С помощью встроенной команды mongodump создается бэкап основной БД MongoDB (без индексов, БДУ и системной Auth БД). Бэкап будет записан в архив backup_YYYY-MM-DD.tar.gz в папке/opt/vulns.io/onpremise/. Дополнительно создается файл бэкапа MongoDB backup_onprem_YYYY-MM-DD.gzip в папке /opt/vulns.io/onpremise/backup/mongodb/.

vio-cli backup mongodb

configs

Архивируется и сжимается директория /opt/vulns.io/onpremise/config и лежащие в ней файлы. Бэкап будет записан в архив backup_YYYY-MM-DD.tar.gz в папке/opt/vulns.io/onpremise/. Дополнительно создается файл бэкапа конфигурации configs_YYYY-MM-DD.tar.gz в папке /opt/vulns.io/onpremise/backup/configs/.

vio-cli backup configs

all

Запускается процесс бэкапа всех выше перечисленных данных с последующим созданием общего архива backup_YYYY-MM-DD.tar.gz и папки /opt/vulns.io/onpremise/backup/ с заархивированными данными configs/ и mongodb/.

vio-cli backup all

backup restore <file_path>

Восстанавливает бэкап из переданного файла. Для восстановления также потребуется созданная при бэкапе папка /opt/vulns.io/onpremise/backup с хранящимися в ней данными.

Аргумент file_path может быть общим бэкапом (backup_*.tar.gz), бэкапом основной БД (backup_onprem_*.gzip) или бэкапом конфигурационных файлов (configs_*.tar.gz).

vio-cli backup restore ./backup_2024-08-08.tar.gz

Важные примечания:

  1. Процесс восстановления любого вида бэкапа полностью останавливает все сервисы продукта Vulns.io Enterprise VM.
  2. Если в архиве найдется бэкап основной БД, то бэкап полностью перезапишет текущую основую БД.
  3. Если в архиве найдется бэкап конфигурационных файлов, то бэкап полностю перезапишет текущую директорию /opt/vulns.io/onpremise/config, но сохранит текущие учетные записи и пароли (credentials) текущих сервисов, текущую лицензию.
  4. После выполнения восстановления данных и проверки Системы можно выполнить удаление архива /opt/vulns.io/onpremise/backup_YYYY-MM-DD.tar.gz и папки /opt/vulns.io/onpremise/backup

ПРИЛОЖЕНИЕ 1. Ролевая модель: матрица прав доступа

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

  • разрешительные действия пользователей с ролью "Суперадминистратор" (super_admin) применимы к любой сущности любой организации,
  • разрешительные действия пользователей с ролями "Администратор организации" (account_admin), "Пользователь организации" (user) и "Пользователь организации (чтение)" (reader) применимы только к сущностям организации, членами которой они являются.

Матрица прав доступа

Сущность и
действие
Супер
администратор
(super_admin)
Администратор
организации
(account_admin)
Пользователь
организации
(user)
Пользователь
организации
(reader)
Организации
создание + - - -
просмотр + + + +
изменение + + - -
удаление + + - -
просмотр списка + - - -
Пользователи
создание + + - -
просмотр + + +1 +1
изменение + + +1 +1
удаление/деактивация + + - -
изменение пароля + + +1 +1
просмотр списка + + - -
Активы
создание + + + -
просмотр + + + +
изменение + + + -
удаление + + +2 -
просмотр списка + + + +
просмотр истории
аудитов
+ + + +
просмотр истории
инвентаризаций
+ + + +
Группы активов
создание + + + -
просмотр + + + +
изменение + + + -
удаление + + +2 -
просмотр списка + + + +
Результат аудита
просмотр + + + +
удаление + + - -
просмотр списка + + + +
просмотр изменений + + + +
Результат
инвентаризации
просмотр + + + +
удаление + + - -
просмотр списка + + + +
просмотр изменений + + + +
Артефакт в задаче
просмотр + + + +
удаление + + - -
просмотр списка + + + +
Задача
создание + + +3 +4
просмотр + + + +
изменение + + +2 -
удаление + + +2 -
просмотр списка + + + +
Результат задачи
просмотр + + + +
удаление + + +2 -
просмотр списка + + + +
Результат
действия в задаче
просмотр + + + +
удаление + + +2 -
просмотр списка + + + +
Учетная запись
создание + + + -
просмотр + + + +
изменение + + +2 -
удаление + + +2 -
просмотр списка + + + -
проверка + + + -
Хранилище
учетных записей
создание + + - -
просмотр + + + -
удаление + + - -
просмотр списка + + + -
Реестр образов
создание + + + -
просмотр + + + +
изменение + + +2 -
удаление + + +2 -
просмотр списка + + + +
API-токен
создание + + - -
просмотр + + - -
изменение + + - -
удаление + + - -
просмотр списка + + - -
Сервер авторизации
создание + + - -
просмотр + + - -
изменение + + - -
удаление + + - -
просмотр списка + + - -
Список исключений
создание + + + -
просмотр + + + +
изменение + + +2 -
удаление + + +2 -
просмотр списка + + + +
Теги
создание + + + -
просмотр + + + +
изменение + + + -
удаление + + + -
просмотр списка + + + +
Статус системы
просмотр + + + +
Файлы обновлений
загрузка + + + -
разрешение на
установку
+ + + -
Статус обновлений
просмотр + + + +
Конфигурация системы
просмотр + - - -
изменение + - - -
перезагрузка + - - -
  • 1 - действие разрешается только с данными самого пользователя.
  • 2 - действие разрешается только с сущностями, созданными самим пользователем.
  • 3 - кроме задач на обновление Агентов на Активах.
  • 4 - кроме задач на обновление Агентов на Активах и установки обновлений на Активы.