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

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

Подготовка ОС перед установкой и Требования

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.4/ru-RU/231034.htm 

Актуальные для развёртывания системы пакеты KUMA запросите у сотрудника Лаборатории Касперского.

Наборы правил корреляции и их описание доступно по ссылке - https://support.kaspersky.com/help/KUMA/3.4/ru-RU/SOC_correlation_rules_description.zip 

Порядок обновления с предыдущих версий KUMA - https://support.kaspersky.com/help/KUMA/3.4/ru-RU/222156.htm 

Карта доступов для KUMA https://support.kaspersky.com/help/KUMA/3.2/ru-RU/217770.htm
Дополнение: Между шардами кластера хранилища необходимо также открывать порт 9000, несмотря на то, что это не указано в таблице документации

Подготовка целевой машины

Дистрибутивы

Oracle Linux 9.4: https://yum.oracle.com/ISOS/OracleLinux/OL9/u4/x86_64/OracleLinux-R9-U4-x86_64-dvd.iso

Ubuntu LTS 22.04 (система работает наиболее производительно): https://releases.ubuntu.com/jammy/ (cкачайте iso ...live-server-amd64.iso)

Astra Linux SE 1.7.5: Приобретается отдельно. Сайт производителя: https://astralinux.ru/

Разбивка диска

Общие требования

Процессор

Набор инструкций SSE4.2 (для работы ClickHouse)

Инструкция AVX (для KUMA 3.2 для MongoDB)

Имя хоста

В качестве имени хоста ОБЯЗАТЕЛЬНО использовать FQDN (полное доменное имя, в котором есть хотя бы 1 точка), например, kuma-1.mydomain.local.

hostnamectl set-hostname kuma-1.mydomain.local

При установке / обновлении на версию 3.2.х имя хоста НЕ должно начинаться с цифры

Имя хоста можно задать во время установки (зависит от инсталятора ОС), либо после.

Настоятельно не рекомендуется изменять FQDN машин после установки KUMA, особенно на сервере с компонентом Core! Это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами KUMA. Для восстановления работоспособности потребуется перевыпуск сертификатов всех сервисов, а также изменение их конфигурации!

Зарегистрируйте целевые машины в DNS-зоне вашей организации. Для пилотных инсталляций, как альтернативу, можно использовать файл hosts. Для этого на каждой целевой машине укажите в файле hosts имена всех машин и их ip-адреса (включая адрес машины, на которой происходит настройка).

Синхронизация времени

Настройте временную зону и синхронизацию системного времени с NTP-сервером на всех серверах KUMA. Это можно сделать во время установки ОС.

Пример команды для настройки NTP 
sudo apt install chrony
sudo systemctl enable --now chronyd
sudo timedatectl | grep 'System clock synchronized'

Если доступ в Интернет отсутствует, то после установки chrony отредактируйте файл /etc/chrony.conf, заменив в нем 2.pool.ntp.org на адрес NTP сервера вашей организации.

Либо:

timedatectl set-timezone Europe/Moscow
echo -e "[Time]\nServers=2.pool.ntp.org 1.pool.ntp.org" >>  /etc/systemd/timesyncd.conf
timedatectl set-ntp true
timedatectl status
Прочее

Задайте пароль пользователю root. Это можно сделать во время установки ОС.

Не создавайте на целевых машинах пользователя kuma! Он создается автоматически при установке продукта и наличие в системе пользователя с таким же именем может сделать вход в систему невозможным (придумайте другое имя).

Отключите SELinux на тех ОС, для которых это применимо (Oracle, Ubuntu).

Отключение SELinux

1. Выполните команду:

sudo setenforce 0

2. Откройте на редактирование файл /etc/selinux/config и установите в нем параметру SELINUX= значение disabled

3. Сохраните внесенные изменения и перезагрузите машину

sudo reboot

На серверах хранилищ включите использование ipv6. Если установка All-in-one, на целевой машине также требуется включить использование ipv6. Для проверки, что ipv6 включен, можно использовать команду:

ping ::1

Для включения ipv6 воспользуйтесь инструкцией из статьи.

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

Требования к установке на различных ОС приведены в официальной документации: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/231034.htm 

Oracle Linux

Основные пакеты:

sudo yum install -y python3.6 python3-netaddr

Только для Oracle 9.x:

sudo yum install -y compat-openssl11

Только для сервера Ядра (как правило, не требуются, если сервер установлен с GUI):

sudo yum install -y nss gtk2 atk libnss3.so libatk-1.0.so.0 libxkbcommon libdrm at-spi2-atk mesa-libgbm alsa-lib cups-libs libXcomposite libXdamage libXrandr
Astra Linux

Основные пакеты:

sudo apt install -y python3 python3-apt curl libcurl4 python3-netaddr python3-cffi-backend

Перед установкой KUMA рекомендуется проверить наличие в ОС сервиса ufw (обычно устанавливается по умолчанию, но встречаются инсталляции, в которых сервис отсутствует):
systemctl status ufw
Если сервис отсутствует, выполнить установку (рекомендуемый вариант).
Нерекомендуемый вариант: в файле инвентаря изменить значение параметра no_firewall_actions c false на true

Только для сервера Ядра (как правило, не требуются, если сервер установлен с GUI):

sudo apt install -y libgtk2.0.0 libnss3 libatk-adaptor libatk1.0-0 libdrm-common libgbm1 libxkbcommon0 libasound2

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

sudo pdpl-user -i 63 <имя пользователя>
Ubuntu

Основные пакеты:

sudo apt install python3-apt curl libcurl4 acl

Для установки openssl 1.1.1 необходимо скачать пакет libssl1.1_1.1.1f-1ubuntu2_amd64.deb и установить его:

sudo dpkg -i libssl1.1_1.1.1f-1ubuntu2_amd64.deb

Только для сервера Ядра (как правило, не требуются, если сервер установлен с GUI):

sudo apt install libatk1.0-0 libgtk2.0-0 libatk-bridge2.0-0 libcups2 libxcomposite-dev libxdamage1 libxrandr2 libgbm-dev libxkbcommon-x11-0 libpangocairo-1.0-0 libasound2

Требования для Хранилища и Keeper

Процессор

ClickHouse работает более эффективно в конфигурациях с большим количеством ядер, но с более низкой тактовой частотой, чем в конфигурациях с меньшим количеством ядер и более высокой тактовой частотой. Например, 16 ядер с 2600 MHz предпочтительнее, чем 8 ядер с 3600 MHz.

ОЗУ

Необходимый объём RAM зависит от Сложности запросов и Объёма данных, обрабатываемых в запросах.

В идеальном случае: Количество Гб ОЗУ примерно равно количеству ТБ хранилища.

Диск

Отключайте файл подкачки (swap) в продуктовых средах.

Настоятельно рекомендуется использовать SSD (обычно ~ > 15k EPS) или HDD-рейд (SAS 10-15k RPM) в зависимости от нагрузки (до 15-25k EPS) и профиля использования системы, если не предполагается выполнение агрегационных SQL-запросов с большой глубиной.

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

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

Файловая система ext4 — самый надежный вариант. XFS тоже работает хорошо. Большинство других файловых систем также должны работать нормально. FAT-32 и exFAT не поддерживаются из-за отсутствия жестких ссылок. Работа на NFS, тоже не лучшая идея.

Размер блока 64 КБ достаточен для большинства конфигураций RAID. Средний размер записи на сервере Clickhouse составляет примерно 1 МБ (1024 КБ), поэтому рекомендуемый размер страйпа (stripe) также составляет 1 МБ.

При необходимости размер блока можно оптимизировать, установив его равным 1 МБ, разделенному на количество дисков без четности в RAID-массиве, так что каждая запись распараллеливается на всех доступных дисках без четности. Никогда не устанавливайте размер блока слишком маленьким или слишком большим.

Keeper более критичен к диску и требует от 1000 IOPS, в зависимости от нагрузки, идеально использовать тип носителя NVMe

Сеть

Keeper рекомендуется устанавливать на отдельные сервера, отдельно от ClickHouse (при возможности, обычно это ~ > 50k EPS), т.к. Keeper менее производителен при установке на одном узле с ClickHouse. Процессор и ОЗУ - по сайзингу.

Требования для Core / Collector / Correlator

Требования к процессору (для KUMA от версии 3.2 для работы MongoDB требуется наличие инструкций процессора AVX) и ОЗУ по сайзингу, диски можно использовать любые HDD от 7,5k RPM от 0,5 ТБ.

Любое новое обогащение или агрегация на коллекторе это ~+ 100-200 Мб к ОЗУ (учитывайте это при расчете)

Объем диска на ядре зависит от количества создавемых алертов, рекомендуется от 1 ТБ

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

Требования к процессору и ОЗУ по сайзингу.

Диск

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

По возможности используйте диски SSD, в крайнем случе подойдет HDD RAID 10 (SAS 10-15k RPM); 

Сеть

Обновление/Установка KUMA

Обновление/Установка KUMA

Обновление/Установка KUMA версии до 2.0.Х (инсталляция «все в одном»)

  1. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой инструкции.

  2. Распакуйте архив: 
    tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz

  3. Перейдите в распакованную папку:  
    cd kuma-ansible-installer
  4. Выполните команду копирования шаблона:  
    cp single.inventory.yml.template single.inventory.yml
  5. Для автоподстановки имени хоста в конфигурацию, используйте команду ниже:  
    sed -i "s/kuma.example.com/$(hostname -f)/g" single.inventory.yml
    Либо подставьте ранее использованный файл при обновлении. В случае ручной правки файла старайтесь не добавлять лишних пробелов. Если деморесурсы НЕ нужно разворачивать укажите в файле single.inventory.yml в строке (значение false) deploy_example_services: false. 

  6. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key

  7. Входим в ОС из-под суперпользователя (root):  
    sudo -i
  8. Запустить установку:  
    ./install.sh single.inventory.yml
  9. Должно все завершиться скриншотом ниже, ошибки отсутствуют (failed=0):image.png

  10. Зайдите на веб интерфейс ядра KUMA по адресу ядра - https://<FQDN_CORE or IP_CORE>:7220 Учетные данные для входа по умолчанию: admin / mustB3Ch@ng3d!
  11. Зайдите на веб интерфейс, проверьте статус Storage. Для этого перейдите во вкладку: Ресурсы - Активные сервисы. Если статус Storage отличается от зеленого (получить актуальный статус можно нажав кнопу обновить), то выполните нижеследующие команды.

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

Обновление/Установка KUMA

Обновление/Установка KUMA версии до 2.0.Х (распределенная инсталляция)

  1. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.

  2. Распакуйте архив (операции выполняются на ядре системы KUMA):  
    tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
  3. Перейдите в распакованную папку:  
    cd kuma-ansible-installer
  4. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key:  
    cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
  5. Выполните команду копирования шаблона (либо подставьте ранее использованный файл при обновлении):  
    cp distributed.inventory.yml.template distributed.inventory.yml
  6. Добавьте публичный ключ SSH на все удаленные хосты в том числе и для хоста с которого происходит развертывание:

    1. На ВСЕХ хостах в конфигурации сервиса SSH должна быть включена опция удаленного входа от суперпользователя!

    2. На хосте с которого происходит развертывание сгенерируйте ключ командой (без указания пароля и доп. параметров):  
      ssh-keygen -t rsa
    3. Добавьте ключ по ssh на удаленные хосты и на сам хост развертывания:  
      ssh-copy-id login@remote_host_fqdn

  7. Отредактируйте файл инвентаря с командой:  
    nano distributed.inventory.yml

В случае ручной правки файла старайтесь не добавлять лишних пробелов.

Количество keeper (ZooKeeper) должно быть нечетным (минимум 3). Если, например, хранилища два, то в файле инвентаря укажите в storage: hosts: <полное_доменное_имя_машины>: (этом может быть core, collector) с его IP адресом и значением keeper, по аналогии с другими записями. Например, если используется два хранилища, то конфигурация storage будет выглядеть следующим образом:

image.png

Для развертывания отдельного одного хранилища без кластера используйте следующие настройки в distributed.inventory.yml:

image.png

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

Генерация содержимого файла /etc/hosts
Если целевые машины НЕ зарегистрированы в DNS-зоне вашей организации, то присвойте параметру generate_etc_hosts значение true и для каждой машины в инвентаре, замените значения параметра ip 0.0.0.0 на актуальные IP-адреса.

Список целевых машин
В файле определены 4 группы, именованные аналогично ключевым компонентам KUMA: core, collector, correlator, storage. Помещая целевую машину в одну из групп, вы инструктируете инсталлятор установить на нее соответствующий компонент KUMA. В каждой группе замените строки с суффиксом *.example.com на актуальные имена хостов целевых машин.

Про устройство кластера хранилища можно почитать тут.

Если хранилище одно, то оставьте параметры shard + replica + keeper, как у kuma-storage-1.example.com

Перед началом установки инсталлятор KUMA выполнит валидацию инвентаря и укажет на ошибки, если таковые были допущены.

8. Входим в ОС из-под суперпользователя (root): 

sudo -i

9. Запустите процесс инсталляции: 

./install.sh distributed.inventory.yml

10. Выполните настройку storage на использование двух хранилищ. В точках назначения нужно добавить URL второго хранилища, (если используются отдельные keeper, то их не нужно указывать в точках назначения) пример ниже:

image.png

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

Обновление/Установка KUMA

Обновление/Установка KUMA версии от 2.1.Х

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/KUMA/2.1/ru-RU/217904.htm

Убедитесь, что все пункты из статьи подготовки в системе соблюдены

При установке / обновлении на версию 3.2.х если имя хоста НЕ должно начинаться с цифры

1. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.

2. Распакуйте архив (операции выполняются на ядре системы KUMA): 

tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz

3. Перейдите в распакованную папку: 

cd kuma-ansible-installer

4. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: 

cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key

5. ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды 

hostname -f

6. ВАЖНО! Хостнейм при команде hostname -f должен содержать хотя бы одну точку, пример: kuma.local

7. Выполните команду копирования шаблона (либо подставьте ранее использованный файл single или distributed при обновлении, в случае первичной установки смотрите пример заполенения тут): 

В случае ручной правки файла старайтесь не добавлять лишних пробелов.

Значения переменных инвентаря (*inventory.yml)
Установка все в одном (single) (AiO)

Выполните команду копирования шаблона: 

cp single.inventory.yml.template single.inventory.yml

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

sed -i "s/kuma.example.com/$(hostname -f)/g" single.inventory.yml
Распределенная установка (distributed) 
cp distributed.inventory.yml.template distributed.inventory.yml

Про устройство кластера хранилища можно почитать тут.

Особенности разворачивания кластера хранилища тут.

8. На серверах хранилищ, где используется роль Keeper, включите использование ipv6. ВАЖНО! С сервера хранилища до ядра должен быть доступен 7220 порт.

Пункты ТОЛЬКО при обновлении с версии 2.0 на версию 2.1.0

Измените конфигурацию сервиса хранилища /usr/lib/systemd/system/kuma-storage-<ID хранилища>.service пропишите: 

TimeoutSec=57600
systemctl daemon-reload

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

/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma 
db.users.updateMany({"accessMatrix":null},{$set: {"accessMatrix":{ "GET /resources" : false, "POST /resources/export" : false, "GET /services" : false, "POST /dictionaries/update" : false, "GET /assets" : false, "GET /dictionaries" : false, "POST /assets/import" : false, "POST /resources/upload" : false, "GET /users/whoami" : false, "GET /alerts" : false, "POST /events" : false, "GET /resources/download/:id" : false, "POST /alerts/close" : false, "GET /events/clusters" : false, "POST /resources/import" : false, "GET /activeLists" : false, "GET /tenants" : false, "POST /assets/delete" : false, "POST /resources/toc" : false, "POST /activeLists/import" : false}}}) 
systemctl restart kuma-core

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

./install.sh ./inventory.yml -e "accept_eula=yes default_admin_password=yes"

Если в KUMA была настроена интеграция с Active Directory и были заданы группы ролей пользователя, сразу после обновления программы необходимо выполнить на машине с Ядром KUMA запрос в монго. В противном случае параметры групп ролей пользователей могут быть потеряны:

/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma
var tenantID = db.tenants.findOne({ main: true })._id;
db.settings.insert({_id: "f371fa1b-948e-45d2-a47c-86ddd67029ee", tenantID: tenantID, disabled: true, roleGroups: [], kind: 'adfs'}); 

9. Входим в ОС из-под суперпользователя (root), если это не было сделано ранее: 

sudo -i

10. Запустите установку (при установке все в одном используйте single.inventory.yml): 

./install.sh distributed.inventory.yml

11. При наличии ошибки в конце установки TASK [Start not orphaned KUMA storage services] считаем установку успешной. Эта ошибка связана с таймаутом запуска ClickHouse, время старта процесса занимает ~10 минут. Убедитесь, что служба clickhouse потребляет ресурсы командой top.

12. Зайдите на веб интерфейс ядра KUMA по адресу ядра - https://<FQDN_CORE or IP_CORE>:7220 Учетные данные для входа по умолчанию: admin / mustB3Ch@ng3d!

В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить ./uninstall.sh <ваш_инвентарь.yml>

Обновление/Установка KUMA

Установка KUMA с отказоустойчивым ядром

Отказоустойчивость KUMA обеспечивается путем внедрения ядра KUMA в кластер Kubernetes, развернутый установщиком KUMA. В качестве распределённого блочного хранилища для кластера используется Longhorn. Схема:

image.png

Схема работы в случае отказа оного из воркеров ядра

image.png

Через ~ 5 минут

image.png

Через ~ 1-2 минуты

image.png

Для установки KUMA в отказоустойчивом исполнении используется установщик kuma-ansible-installer-ha-2.1. X.tar.gz. Конфигурация кластера Kubernetes задается в файле инвентаря k0s.inventory.yml. Требования к устройствам для установки KUMA в Kubernetes - https://support.kaspersky.com/help/KUMA/3.0.2/ru-RU/217889.htm 

Порты доступа для кластера ядра
Трафик KUMA core в отказоустойчивой конфигурации (трафик, в котором и источником и получателем выступают внешние сервисы KUMA здесь не рассматривается)
В таблице указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться
       
Источник Назначение Порт назначения Тип
Внешние сервисы KUMA Балансировщик нагрузки 7209 tcp
Внешние сервисы KUMA Балансировщик нагрузки 7210 tcp
Внешние сервисы KUMA Балансировщик нагрузки 7220 tcp
Внешние сервисы KUMA Балансировщик нагрузки 7222 tcp
Внешние сервисы KUMA Балансировщик нагрузки 7223 tcp
       
Рабочий узел Балансировщик нагрузки 6443 tcp
Рабочий узел Балансировщик нагрузки 8132 tcp
Управляющий узел Балансировщик нагрузки 6443 tcp
Управляющий узел Балансировщик нагрузки 8132 tcp
Управляющий узел Балансировщик нагрузки 9443 tcp
Рабочий узел Внешние сервисы KUMA в зависимости от настроек при создании сервиса tcp
Балансировщик нагрузки Рабочий узел 7209 tcp
Балансировщик нагрузки Рабочий узел 7210 tcp
Балансировщик нагрузки Рабочий узел 7220 tcp
Балансировщик нагрузки Рабочий узел 7222 tcp
Балансировщик нагрузки Рабочий узел 7223 tcp
Внешние сервисы KUMA Рабочий узел 7209 tcp
Внешние сервисы KUMA Рабочий узел 7210 tcp
Внешние сервисы KUMA Рабочий узел 7220 tcp
Внешние сервисы KUMA Рабочий узел 7222 tcp
Внешние сервисы KUMA Рабочий узел 7223 tcp
Рабочий узел Рабочий узел 179 tcp
Рабочий узел Рабочий узел 9500 tcp
Рабочий узел Рабочий узел 10250 tcp
Рабочий узел Рабочий узел 51820 udp
Рабочий узел Рабочий узел 51821 udp
Управляющий узел Рабочий узел 10250 tcp
Балансировщик нагрузки Управляющий узел 6443 tcp
Балансировщик нагрузки Управляющий узел 8132 tcp
Балансировщик нагрузки Управляющий узел 9443 tcp
Рабочий узел Управляющий узел 6443 tcp
Рабочий узел Управляющий узел 8132 tcp
Рабочий узел Управляющий узел 10250 tcp
Управляющий узел Управляющий узел 2380 tcp
Управляющий узел Управляющий узел 6443 tcp
Управляющий узел Управляющий узел 9443 tcp
Управляющий узел Управляющий узел 10250 tcp
Консоль управления кластером (CLI) Балансировщик нагрузки 6443 tcp
Консоль управления кластером (CLI) Управляющий узел 6443 tcp

Минимально кластер должен включать:

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

Для реализации отказоустойчивости необходим выделенный контроллер кластера  и минимум 2 рабочих узла. Если контроллер кластера содержит рабочую нагрузку и под (pod) с Core размещается на нем, то его отключение приведет к полной потере доступа к Core.

На всех компонентах ядра должно быть единое время, настройте на всех машинах NTP

На контроллерах кластера должен быть уникальный machine-id, это значит, что не рекомендуется клонирование машин с этой ролью, либо необходимо изменить ID на машинах до установки. Внимание! Допустимость данной операции должен определять администратор хоста с учётом возможного использования machine-id другими сервисами! rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure && reboot

  1. В нашем случае мы будем использовать установку All-In-One хост kuma-1.local, один узел контроллера (хост kuma-2.local) и два рабочих узла (хост kuma-3.local и kuma-4.local), пример файла инвентаря: https://box.kaspersky.com/f/bf06497b5b004dc3b1e5/  Другие примеры инвентарей: https://box.kaspersky.com/d/b397490dc08048acb671/  

  2. При установке с нуля kuma_core игнорируется, его заполнение нужно только для переноса ранее установленной коры без HA в кластер Kubernetes
    Т.е. kuma_core должен быть равен одному из kuma_worker, если у нас уже есть кума и мы тащим ее в кубер. 

  3. В распределенной установке kuma в секции инвентаря kuma_core нужно указать хост, который есть в роли worker (один из двух)
  4. ВАЖНО! Для успешной установки должны быть соблюдены следующие требования:
    • все машины кластера должны быть добавлены в /etc/hosts;
    • установлены пакеты в соответствии с: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/244399.htm;
    • На Astra Linux  на машине балансировщика нужно установить в дополнение пакету nginx еще один пакет libnginx-mod-stream
    • в /var/lib/ должно быть не менее 32GB свободного места;
  5. Значение переменных в инвентаре ansible:
    • low_resources – использовать минимальные ресурсы для разворачивания? Отсутсвует по умолчанию. (Достаточно ресурсов: 2 CPU 4 RAM, НО при этом создается том хранения 4 Гб, без этого параметра том создается 512 Гб)
    • для части инвентаря kuma_k0s и переменных ansible_host важно указывать IP адреса
    • kuma_managed_lb: false - если используется собственный (балансировщик организации, не KUMA) балансировщик, при этом указать FQDN этого балансировщика (для корректного формирования сертификата коры)
    • no_firewall_actions: false - инсталлятор будет пытаться открыть необходимые порты на МЭ данного хоста
    • Остальные значения переменных: https://support.kaspersky.ru/help/KUMA/3.4/ru-RU/244406.htm 
  6. Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой инструкции.
  7. Распакуйте архив (операции выполняются на ядре системы KUMA): tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
  8. Перейдите в распакованную папку: cd kuma-ansible-installer
  9. Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key: cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
  10. Выполните команду копирования шаблона (пример заполненного файла в п. 0): cp k0s.inventory.yml.template k0s.inventory.yml
  11. ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды hostname -f
  12. ВАЖНО! Хостнейм при команде hostname -f должен содержать хотя бы одну точку, пример: kuma.local
  13. Входим в ОС из-под суперпользователя (root), если это не было сделано ранее: sudo -i
  14. Запустите установку: ./install.sh k0s.inventory.yml
  15. Зайдите на веб интерфейс ядра KUMA по одному из адресов рабочих узлов или балансировщика, например, в нашем случае это - https://192.168.0.153:7220 Учетные данные для входа по умолчанию: admin / mustB3Ch@ng3d!
  16. Для начального администрирования кластера воспользуйтесь командами этого раздела.

В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить uninstall.sh и перезагрузить все узлы кластера. Если uninstall выполнить нельзя (идет миграция существующей установки в кластер), то перед повторной попыткой установки нужно вручную выполнить команду sudo k0s reset (если долгий reset, то rm -rf /var/lib/k0s/containerd, затем k0s reset -d) на всех узлах кластера и перезагрузить их

Перестроение между воркерами в кластере Kubernetes происходит с таймаутом ~ 5 мин

Отказоустойчивость балансировщиков, см. тут

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

Видео установки в конфигурации AiO-1LB-1CP-2W тут

Обновление/Установка KUMA

Установка KUMA на ОС с установленным антивирусом

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

/opt/kaspersky/kuma/*

Более гранулярный доступ описан в этой статье - https://support.kaspersky.ru/kuma/3.2/230384 

Обновление/Установка KUMA

Подготовка Astra Linux 1.7.х (с картинками)

Пак автомной установки KUMA (офлайн пакеты для Astra) — ссылка на mail.ru тк объем большой

Начало установки. 

Выбор языка и режим «Графическая установка». 

На скриншотах ниже показан пошаговый процесс установки с комментариями.

image.png

image.png

image.png

Установщик Astra Linux позволяет ввести только короткое имя компьютера (short host name). Задать FQDN имя компьютера (long host name) возможно после установки ОС. Подробнее см. Примечание 1.

image.png

image.png

image.png

image.png

Разметка дисков выполняется на усмотрение администратора ОС. Учитывайте пожалуйста пункты из подготовки ОС.
Для целей демонстрационной установки выбран метод «Авто – использовать весь диск».

image.png

image.png

image.png

image.png

image.png

image.png

image.png

image.png

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

image.png

image.png

Выбор уровня защищенности согласно документации для используемого приложения. Для целей демонстрационной установки выбран уровень “Орел”.

image.png

image.png

image.png

image.png

image.png

image.png

image.png

Примечание 1

Сразу после установки ОС в минимальной конфигурации нет сети. И имя компьютера установлено в short host name.

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

Пакет NetworkManager:

Пакет ifupdown с настройками конфигурационного файла /etc/network/interfaces

https://wiki.astralinux.ru/pages/viewpage.action?pageId=3277370 
Во избежание конфликтов со службой networking служба NetworkManager  НЕ РАБОТАЕТ с сетевыми интерфейсами, перечисленными в файле /etc/network/interfaces или в файлах в каталоге /etc/networking/interfaces.d/. По умолчанию в файле /etc/network/interfaces присутствует только интерфейс локальной петли (loopback).

Использование NetworkManager

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

sudo apt install network-manager

По умолчанию используется репозиторий установочного диска Astra Linux, который является активным в конфигурационном файле /etc/apt/sources.list. Публичные репозитории закомментированы.

image.png

Чтобы приступить к настройке сетевых параметров в псевдографике выполните команду: nmtui

image.png

Здесь вы можете изменить имя узла на FQDN, настроить сетевой интерфейс, проверить параметры ipv4 и ipv6.

Использование конфигурационного файла interfaces. (сложнее)

Если не требуется специальная настройка и параметры сети будут получены по DHCP. Открыть на редактирование:

sudo nano /etc/network/interfaces

Добавить в файл комментарий, начинающийся с # (по желанию) и параметры 

# The eth0 network interface
auto eth0
iface eth0 inet dhcp

Перезапустите службу сети: sudo /etc/init.d/networking restart
Проверьте параметры сетевого интерфейса: sudo ifconfig

Задайте имя компьютера в FQDN:

hostname -f
hostnamectl
hostnamectl set-hostname app-server-01.example.com

image.png

Пропишите IP адрес и FQDN в файле /etc/hosts

nano /etc/hosts

Текстовый файл hosts:

127.0.0.1       localhost
192.168.1.1     app-server-01.example.com
# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

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

Установка компонентов KUMA на отдельную машину

Установка компонентов KUMA на отдельную машину

Установка коллектора/коррелятора

Для установки дополнительного коллектора/коррелятора необходимо подготовить машину установив на нее поддерживаемую ОС и создав разделы в системе аналогично разделу «Подготовка» этой инструкции, а также другие компоненты KUMA должны быть доступны по сети от этой машины.

С машины должен происходить резолв хостнеймов ядра и других компонентов, в случае отсутствия DNS пропишите IP в /etc/hosts. Доступы необходимы согласно этой схеме.

  1. Скопировать исполняемый файл kuma с любого из установленных компонентов KUMA (либо пакета установки /kuma-ansible-installer/roles/kuma/files/kuma), создайте идентичную структуру папок:
    • /opt/kaspersky/kuma/kuma

  2. Создайте пользователя и группу kuma на новой машине:  
    useradd -Mrs /usr/bin/false kuma
  3. Создайте структуру папок /opt/kaspersky/kuma/ на новой машине, добавьте папки correlator и collector.

  4. Поменяйте владельца и группу исполняемого файла и всех подпапок и принимаете соглашение
    chmod +x /opt/kaspersky/kuma/kuma
touch /opt/kaspersky/kuma/LICENSE
chown kuma:kuma -R /opt/kaspersky/kuma/*
/opt/kaspersky/kuma/kuma license

Далее процесс установки службы коллектора/коррелятора проходит аналогично стандартному процессу. Пример с DNS коллектором.

Начиная с версии KUMA 2.1.3 доступен отдельный плейбук и скрипт для централизованной установки компонентов на отдельные сервера. Подробнее по ссылке: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222160.htm 

Установка компонентов KUMA на отдельную машину

Установка хранилища KUMA

Для установки дополнительного хранилища или других компонентов необходимо подготовить машину установив на нее поддерживаемую ОС и создав разделы в системе аналогично разделу «Подготовка» этой книги, а также другие компоненты KUMA должны быть доступны по сети от этой машины.

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

Для актуальных версий (c 2.1.3.49) с помощью expand.inventory:

Перейдите в папку установки kuma-ansible-installer

cp expand.inventory.yml.template expand.inventory.yml

Отредактируйте файл expand.inventory.yml, пример установки хранилища на kuma-additional-storage-1.example.com ниже:

kuma:
  vars:
    ansible_connection: ssh
    ansible_user: root
  children:
    kuma_collector:
    kuma_correlator:
    kuma_storage:
      hosts:
        kuma-additional-storage-1.example.com:

Запустите начало установки, следующей командой:

PYTHONPATH="$(pwd)/ansible/site-packages:${PYTHONPATH}" python3 ./ansible/bin/ansible-playbook -i expand.inventory.yml expand.inventory.playbook.yml

Для KUMA от 3.х:

PYTHONPATH="$(pwd)/ansible/site-packages:${PYTHONPATH}" python3 ./ansible/bin/ansible-playbook -i expand.inventory.yml expand.playbook.yml

Для старых версий:

В случае добавления нового сервера с репликой копирование данных начнется с текущего времени


Установка компонентов KUMA на отдельную машину

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

Создание и публикация сервиса агента

1. Зайдите в веб-интерфейс KUMA и перейдите на вкладку Ресурсы – Агенты.

2. Нажмите на кнопку Добавить агент.

3. Задайте необходимые параметры для агента в соответствии с ограничениями Linux-агентов: https://support.kaspersky.ru/help/KUMA/2.1/ru-RU/217776.htm 

4. Сохраните созданный ресурс агента.

5. Перейдите на вкладку Ресурсы – Активные сервисы.

6. Нажмите на кнопку Добавить сервис, выберите созданный ресурс агента и нажмите на кнопку Создать сервис.

7. Выберите галочкой созданный сервис агента и нажмите в верхней части экрана на кнопку Копировать идентификатор.

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

Установка агента в качестве службы

В данном разделе под <ID> понимается значение идентификатора агента, который был скопирован в предыдущем разделе в п. 7.  Под <KUMA-FQDN> понимается FQDN ядра KUMA.

1. Если установка агента осуществляется на сервер, на котором уже установлены какие-либо компоненты KUMA, то шаги 2, 3, 5, 7 нужно пропустить.

2. Скопируйте из дистрибутива KUMA файл kuma-ansible-installer/roles/kuma/files/kuma и переместите его на сервер для установки агента в любую директорию.

3. Создайте пользователя для запуска агента следующей командой 

useradd -Mrs /usr/bin/false kuma

4.    Создайте рабочую директорию для агента

mkdir -p /opt/kaspersky/kuma/agent/<ID>

5.    Скопируйте файл kuma в директорию /opt/kaspersky/kuma/

cp kuma /opt/kaspersky/kuma/

6.    Назначьте пользователя kuma владельцем директории

chown -R kuma:kuma /opt/kaspersky/kuma/

7.    Задайте права на выполнение файлу kuma 

chmod +x /opt/kaspersky/kuma/kuma

8.    Примите лицензионное соглашение

/opt/kaspersky/kuma/kuma license

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

/opt/kaspersky/kuma/kuma agent --core https://<KUMA-FQDN>:7210 --id <ID> --wd /opt/kaspersky/kuma/agent/<ID>

Для остановки выполнения воспользуйтесь комбинацией клавиш Ctrl + C

9.    Создайте файл с описанием сервиса агента

touch /usr/lib/systemd/system/kuma-agent-<ID>.service

10.    Любым удобным способом откройте созданный файл на редактирование и укажите в нем следующую конфигурацию

[Unit]
Description=KUMA Agent Syslog
StartLimitIntervalSec=1
After=network.target

[Service]
Type=notify
Restart=always
RestartPreventExitStatus=99
TimeoutSec=300
RestartSec=5
WatchdogSec=60

User=kuma
Group=kuma

ExecStartPre=+-chown kuma:kuma /opt/kaspersky/kuma/agent
ExecStartPre=+-chown -R kuma:kuma /opt/kaspersky/kuma/agent/<ID>
ExecStart=/opt/kaspersky/kuma/kuma agent --core https://<KUMA-FQDN>:7210 --id <ID> --wd /opt/kaspersky/kuma/agent/<ID>/

LimitFSIZE=infinity
LimitCPU=infinity
LimitAS=infinity
LimitNOFILE=64000
LimitNPROC=64000
LimitMEMLOCK=infinity
TasksMax=infinity
TasksAccounting=false

[Install]
WantedBy=multi-user.target

11.    Сохраните полученный файл
12.    Выполните обновление конфигурации

systemctl daemon-reload

13.    Запустите сервис агента

systemctl start kuma-agent-<ID>.service

14.    Настройте сервису автозапуск

systemctl enable kuma-agent-<ID>.service

После установки сервиса агента индикация состояния в веб-интерфейсе KUMA на вкладке Ресурсы – Активные сервисы изменится на Зеленый. Также будет отображен FQDN и IP-адрес агента.

Диагностика неполадок

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

1.    Просмотр состояния службы

systemctl status kuma-agent-<ID>.service

2.    Просмотр журнала службы

journalctl -f -u kuma-agent-<ID>.service

3.    Просмотр журнала агента

tail -f /opt/kaspersky/kuma/agent/<ID>/log/agent

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

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

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

  1. Остановка сервиса агента
    sudo systemctl stop kuma-agent-<ID>

  2. Отключение сервиса агента
    sudo systemctl disable kuma-agent-<ID>

  3. Удаление unit-файла агента
    sudo rm /usr/lib/systemd/system/kuma-agent-<ID>.service

  4. Перезапуск конфигурации systemd
    sudo systemctl daemon-reload

  5. (Опциональный шаг)
    sudo systemctl reset-failed

Установка компонентов KUMA на отдельную машину

Установка агента в режиме диод (Diode)

Схема работы сбора в режиме diode

image.png

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

Для осуществления описанного способа передачи событий через диод используется пара destination и connector типа diode, destination на агенте и connector на коллекторе. Агент может иметь любые из возможных типов connector, а коллектор - любые из возможных destination.

Агент при работе накапливает события в буфер. Как только буфер становится размером >=bufferSize (по умолчанию 64 Мб), или с момента предыдущей записи буфера в файл проходит > FlushInterval (по умолчанию 10 сек):

image.png

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

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

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

Для diode-агента невозможно выбрать коннекторы типа sql или netflow.

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

Конфигурацинный файл агента сохраняется в человекочитаемом виде для возможности добавления секретов вручную. Для избежания сохранения секретов в открытом виде, содержимое реальных секретов заменяется на шаблоны соответствующего типа секрета, также в конфигурационном файле генерируются шаблоны в местах, где это явно указано (см п. Шаблоны секретов). В ресурсах внутри агента, использующих секреты указан UUID секрета, содержимое секретов находится отдельно в поле secrets. Данные секретов можно заполнить вручную в конфигурационном файле, изменяя поля секретов.


Далее в таблице описаны поля секрета.

image.png

Конфигурационный файл скачивается из веб-интерфейся ядра KUMA в части настроек агента:

image.png

Запуск агента (автономный агент)

При установке агента его конфигурационный файл не должен находиться в директории, в которую устанавливается агент.

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

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

Справочная информация об установщике доступна по команде: kuma.exe help agent

Linux

Примите лицензионное соглашение: /opt/kaspersky/kuma/kuma license

Для запуска агента требуется скопировать файл /opt/kaspersky/kuma/kuma с машины, где установлена KUMA на машину с linux, где будет запущен агент и запустить его: ./kuma agent --cfg <path to config file> --wd <path to working directory>
Через опцию --wd указывается путь для хранения файлов агента, по умолчанию они будут храниться в текущей директории.

Конфигурационный файл может содержать секреты, его следует защищать при помощи ACL, позволяющих чтение только пользователю KUMA (600).

Windows

Примите лицензионное соглашение: /opt/kaspersky/kuma/kuma.exe license

Без установки

kuma.exe agent --cfg <path to config file>
kuma.exe  agent --cfg <путь к конфигурационному файлу агента> --wd <путь к директории, где будут размещаться файлы устанавливаемого агента. Если не указывать этот флаг, файлы будут храниться в директории, где расположен файл kuma>

С установкой

kuma.exe agent --cfg <path to config file> --user <user to start service as> --install

При установке используемый конфигурационный файл перемещается в рабочую директорию (ProgramData\Kaspersky Lab\KUMA\agent\<serviceID>\) (ID берется из ресурса агента в конфигурационном файле), kuma.exe перемещается в рабочую директорию (Program Files\Kaspersky Lab\KUMA).

В дальшейшем используется перемещенный конфигурационный файл.

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

Удаление

kuma.exe agent --cfg <path to config file> --uninstall

или

kuma.exe agent --id <идентификатор сервиса агента, созданного в KUMA> --uninstall


Установка компонентов KUMA на отдельную машину

Установка службы хранилища (если этого не произошло при установке)

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

В противном случае следует воспользоваться инструкцией: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-xranilishha-kuma 

Создаем сервис хранилища перейдите в Ресурсы – Хранилища затем нажать на кнопку Добавить хранилище придумайте название и затем укажите количество дней хранения событий и событий аудита (от 365 дней срок хранения аудита) и узлы кластера (от версии 2.1) в соответствии с проведенной установкой, ниже пример для All-In-One установки:

image.png

затем нажмите Сохранить.

Публикуем созданный сервис Ресурсы – Активные сервисы затем выбрать созданный ранее сервис и нажать на кнопку Создать сервис.

В случае кластера хранилищ, опубликуйте этот же сервис по количеству отдельных машин хранилищ и keeper'ов

Скопируйте идентификатор сервиса:

image.png

Зайдите по ssh на сервер где будет разворачиваться сервис хранилища и выполните команду (api.port 7230 можно использовать произвольный никем не занятый порт), сначала выполним проверку (без установки, ошибки приналичии будут отображаться в консоли):

Сначала происходит установка keeper'ов, затем нод Clickhouse

У каждой из машин хранилищ и keeper'ов  должен быть свой уникальный идентификатор

Устанавливаем службу хранилища:

/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://<FQDN/ИМЯ_ХОСТА_СЕРВЕРА_ЯДРА>:7210 --api.port 7230 --install

В разделе Ресурсы – Активные сервисы убедитесь, что служба работает более 30 секунд с «зеленым» статусом индикатора:

image.png

Далее создадим точку назначения, которая используется в маршрутизации событий, перейдите в Ресурсы – Точки назначения, затем нажмите на кнопку Добавить точку назначения. Придумайте название и затем в поле URL укажите FQDN и порт службы хранилища, например: kuma-1-5-1.sales.lab:7230, затем нажмите Сохранить.

В точке назначения в KUMA прописываются URL всех хранилищ, отдельно установленные машины с ролью keeper указывать НЕ нужно

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

Для удаления службы хранилища (если необходимо), можно использовать следующую команду:

/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --uninstall

Резервное копирование

Резервное копирование

Резервное копирование и восстановление KUMA

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222208.htm

Резервное копирование и восстановление KUMA версии 2.1+

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

Создание резервной копии Ядра KUMA по API

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

GET /api/v1/system/backup

В ответ на запрос возвращается архив tar.gz, содержащий резервную копию Ядра KUMA. На хосте, где установлено Ядро, резервная копия не сохраняется. Сертификаты включаются в состав резервной копии.

Если операция выполнена успешно, создается событие аудита со следующими параметрами:
DeviceAction = "Core backup created"
SourceUserID = "<user-login>"

Пример команды для бэкапа через curl:

curl -k --header 'Authorization: Bearer <token>' 'https://<ip_kuma>:7223/api/v1/system/backup' -o backup.tar.gz

У токена пользователя должны быть соответствующие права для выполнения бекапа

Восстановление Ядра KUMA из резервной копии по API

Восстановление данных из резервной копии доступно только при сохранении версии KUMA.

Необходим работающий сервис MongoDB.

Если сервис MongoDB в нерабочем состоянии

Останавливаете службы MongoDB и Core:

systemctl stop kuma-mongodb.service
systemctl stop kuma-core*.service

  Удаляете данные из папки data: 

rm -rf /opt/kaspersky/kuma/mongodb/data/*

 Запускаете службу MongoDB:

systemctl start kuma-mongodb.service

Инициализируете MongoDB:

/opt/kaspersky/kuma/mongodb/bin/mongo --eval 'rs.initiate()'

Запускаете службу Core:

systemctl start kuma-core*.service

Далее восстанавливаете ядро по пунктам ниже этой главы.

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

POST /api/v1/system/restore

curl -k --request POST 'https://<ip_kuma>:7223/api/v1/system/restore' --header 'Authorization: Bearer <token>'  --data-binary '@/backup/backup.tar.gz'

Тело запроса должно содержать архив с резервной копией Ядра KUMA, полученный в результате выполнения API-запроса создания резервной копии.

После получения архива с резервной копией KUMA выполняет следующие действия:

1. Распаковывает архив с резервной копией Ядра KUMA во временную директорию.

2. Сравнивает версию текущей KUMA и с версией резервной копии KUMA.

3. Если версии соответствуют друг другу, создается событие аудита со следующими параметрами:

DeviceAction = "Core restore scheduled"
SourceUserID = "<имя пользователя инициировавшего восстановление KUMA из резервной копии"

4. Если версии не различаются, выполняет восстановление данных из резервной копии Ядра KUMA.

5. Удаляет временную директорию и стартует в штатном режиме.
В журнале Ядра KUMA появится запись "WARN: restored from backup".

Резервное копирование и восстановление KUMA до версии 2.1 (включительно)

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

sudo /opt/kaspersky/kuma/kuma tools backup --dst <путь к директории для резервной копии> --certificates

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

sudo /opt/kaspersky/kuma/kuma tools backup --dst <путь к директории для резервной копии>

(Best Practice) Для автоматизации создания еженедельной (каждое воскресенье в 00:00) резервной копии (в защищенном виде, файлы будут находиться в папке /root/backup/ его можно заменить по желанию) создайте задачу в планировщике CRON следующей командой (выполняется от суперпользователя и в одну строку):

mkdir /root/backup ; echo  PATH=$PATH >> /var/spool/cron/root ; echo  SHELL=$SHELL >> /var/spool/cron/root ; echo "# m h dom mon dow user   command" >> /var/spool/cron/root ; echo "# m h dom mon dow user   command"  >>  /var/spool/cron/root  ;  echo  "0 0 * * 0  /opt/kaspersky/kuma/kuma tools backup --dst /root/backup/ --certificates"  >> /var/spool/cron/root ;  echo  "#0 0 * * 0  /opt/kaspersky/kuma/kuma tools backup --dst /root/backup/"  >> /var/spool/cron/root

Чтобы восстановить данные из резервной копии, войдите в ОС сервера, на котором установлено Ядро KUMA. Остановите Ядро KUMA, выполнив следующую команду:

sudo systemctl stop kuma-core

Выполните следующую команду:

sudo /opt/kaspersky/kuma/kuma tools restore --src <путь к директории с резервной копией> --certificates

Флаг --certificates не является обязательным и используется для восстановления сертификатов.

Запустите KUMA, выполнив следую команду:

sudo systemctl start kuma-core

(опционально) Для создания незащищенной резервной копии конфигураций ресурсов KUMA можно использовать команду, файл сохраните на отдельном носителе (файл будет находиться в папке /home):

/opt/kaspersky/kuma/mongodb/bin/mongodump --db=kuma --archive=/home/kuma_dump_$(date +"%d%m%Y")

Для восстановления:

/opt/kaspersky/kuma/mongodb/bin/mongorestore --drop --archive=<путь к архиву>

Полезные ссылки

Резервное копирование

Резервная копия (локальная) событий из хранилища

С помощью встроенного клиента clickhouse в KUMA

Сохранение данных

Сохранение данных за определенную дату в файл CSV:

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" > click_events.csv

Сохранение данных за определенную дату в файл CSV с максимальным сжатием (cырой файл CSV 1.4 Гб (строк 5630119) - сжатый 72 Мб):

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz

Сохранение данных за определенную дату по определенному промежутку в часах (время в UTC) в файл CSV с максимальным сжатием (с 10:00:00 до 11:00:00):

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDateTime(fromUnixTimestamp64Milli(Timestamp)) > toDateTime('2024-07-16 10:00:00') AND toDateTime(fromUnixTimestamp64Milli(Timestamp)) < toDateTime('2024-07-16 11:00:00') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz

Загрузка данных в хранилище

Распаковать данные с сохранением архива: gzip -dk click_events.csv.gz
Распаковать данные без сохранения архива: gzip -d click_events.csv.gz

Если необходима замена TenantID для видимости событий в определенном тенанте, нужно в распакованном файле CSV заменить третье значение после запятой (столбцы CSV "ID","Timestamp","TenantID","ServiceID","ServiceName"...), пример команды (старый TenantID 746c6045-b929-4edd-8e1e-84ebe4a11880, новый TenantID 911c6045-b929-4edd-8e1e-84ebe4a11911):

sed -i 's/746c6045-b929-4edd-8e1e-84ebe4a11880/911c6045-b929-4edd-8e1e-84ebe4a11911/g' click_events.csv

Загрузка событий из файла CSV в хранилище ClickHouse:

/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "INSERT INTO events_local_v2 FORMAT CSV" < /root/click_events.csv

В CSV файле не должно быть пустых строк, иначе будет ошибка: Code: 27. DB::ParsingException: Cannot parse input: expected ',' before: '\n\n':

С утилитой clickhouse-backup

Для создания резервной копией можно воспользоваться утилитой clickhouse-backup. Исполняемый файл (clickhouse-backup-linux-amd64.tar.gz) для ОС Linux  можно загрузить отсюда. Подробнее про утилиту https://github.com/Altinity/clickhouse-backup 

Подготовка

Разархивируем загруженный файл:

tar -xvf clickhouse-backup-linux-amd64.tar.gz

Добавляем возможность исполнения файла:

chmod +x clickhouse-backup

Добавляем следующую строку <access_management>1</access_management> в файл:

nano /opt/kaspersky/kuma/clickhouse/cfg/config.xml

В этот раздел конфига:

image.png

Создадим файл конфигурации:

nano click_backup_config.yml

Соследующим содержимым:

general:
  log_level: error
  # Uncomment below if needed
  # remote_storage: sftp

clickhouse:
  host: kuma-aio.sales.lab
  port: 9000
  username: default
  password: ""  # Use `null` or a valid password if required
  secure: true
  tls_key: "/opt/kaspersky/kuma/clickhouse/certificates/key.pem"
  tls_cert: "/opt/kaspersky/kuma/clickhouse/certificates/cert.pem"
  tls_ca: "/opt/kaspersky/kuma/clickhouse/certificates/ca-cert.pem"
  
  skip_tables:
    - system.*
    - INFORMATION_SCHEMA.*
    - information_schema.*
    - _temporary_and_external_tables.*

# Uncomment and configure the SFTP section if needed
# sftp:
#   address: "172.30.56.216"
#   port: 22
#   username: "sftpuser"
#   password: "password"
#   key: ""
#   path: "clickhouse-backup"
#   compression_format: gzip
#   compression_level: 1
#   concurrency: 1
#   debug: false

Для логирования действий утилиты используйте значение log_level: info в конфигурации click_backup_config.yml

В нашем случае восстанавливается Хранилище в инсталляции All-In-One.

Для создания копии данных (ВСЕХ событий) используйте команду:

./clickhouse-backup create -t kuma.events_local_v2 -c click_backup_config.yml

Резервная копия создастся по пути /opt/kaspersky/kuma/clickhouse/data/backup/

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

./clickhouse-backup list -c click_backup_config.yml

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

./clickhouse-backup restore 2024-04-08T11-07-24 -t kuma.events_local_v2 -c click_backup_config.yml

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

image.png

Для исправления ошибки перезапустите хранилище из активных сервисов.

Для удаления бекапа:

./clickhouse-backup delete local 2024-04-08T11-07-24 -c click_backup_config.yml

Удалить служебные данные утилиты:

./clickhouse-backup clean -c click_backup_config.yml
Резервное копирование

Архивировние и восстановление БД через ClickHouse BACKUP/RESTORE

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Данная инструкция проверена и актуальна только для версии KUMA 3.0.3.19

Описание

Данный метод позволяет выполнять локальное архивирование и восстановление партиций ClickHouse через встроенные механизмы BACKUP и RESTORE.

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

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

Настройка хранилища

1. Создать на сервере хранилища директорию для сохранения резервных копий, например, /tmp/test_backup

2. Сделать владельцем директории пользователя kuma с помощью команды:

chown kuma:kuma /tmp/test_backup/

3. Убедиться, что у пользователя kuma также есть права x и r на всех родительских директориях

4. Перейти в Web-интерфейс KUMA на вкладку "активные сервисы".

5. Открыть на редактирование требуемый сервис хранилища.

6. В поле "Переопределение параметров ClickHouse" задать разрешенный путь для сохранения резервных копий

image.png

<backups>
        <allowed_path>/tmp/test_backup/</allowed_path>
</backups>

7. Сохранить сервис хранилища

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

image.png

Как проверить, что изменения применились

1. Перейдите в консоль соответствующего сервиса Хранилища

2. Выполните команду 

cat /opt/kaspersky/kuma/clickhouse/cfg/config.d/override.xml

3. В выводе должны быть параметры, переопределенные в настройках севриса

image.png

Выполнение архивирования

1. Запустить клиента clickhouse командой

/opt/kaspersky/kuma/clickhouse/bin/client.sh

2. Выполнить запрос для просмотра партиций, например, такой

SELECT partition, name, partition_id 
FROM system.parts 
WHERE table='events_local_v2' 
AND NOT positionCaseInsensitive(partition,'audit')>0
ORDER BY partition DESC

3. В результате будут выведены названия и id партиций

Для фильтрации по дате можно воспользоваться следующим запросом 
SELECT partition, name, partition_id 
FROM system.parts 
WHERE substring(partition,2,8) = '20240406'
AND table='events_local_v2'
AND NOT positionCaseInsensitive(partition,'audit')>0

В результате будут выведены все партиции, кроме партиций событий аудита за 6 апреля 2024 года

4. Для архивации потребуется значение из первой колонки (partition) или последней (partition_id)

image.png

5. Для архивации партиции по id необходимо выполнить команду

BACKUP TABLE kuma.events_local_v2
PARTITION ID '0405a4ae764614f2283652209b390809'
TO File('/tmp/test_backup/20250221_0405a4ae764614f2283652209b390809.zip')
SETTINGS compression_method = 'lzma', compression_level=3
Описание параметров

04fb255c7659adfd1d43ed2dd0646b10 - id партиции из предыдущего запроса

/tmp/test_backup/ - директория для бэкапов

20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz - имя файла бэкапа (может быть произвольным)

Важно! В ClickHouse использующемся в KUMA до версии 3.4 включительно присутствует баг, при котором параметр compression_method игнорируется, если у итогового файла выбрано расширение отличное от .zip

В случае, если все прошло успешно будет получено сообщение о создании бэкапа:

image.png

Также посмотреть состояние бэкапа можно через запрос к таблице system.backups

SELECT * FROM system.backups ORDER BY start_time \G

image.png

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

SELECT * FROM system.backups WHERE id = 'd52ba745-7ad0-4099-827a-db688aa62649' \G

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

Пример удаления партиции из интерфейса

1. Перейти на вкладку "Активные сервисы"

2. Выбрать нужное хранилище, нажать по его имени правой кнопкой мыши и выбрать пункт "Смотреть разделы"

image.png

3. В разделах выбрать нужный и нажать удалить

image.png

Выполнение восстановления

1. Запустить клиента clickhouse командой

/opt/kaspersky/kuma/clickhouse/bin/client.sh

2. Выполнить запрос для восстановления

RESTORE TABLE kuma.events_local_v2 
PARTITION ID '0405a4ae764614f2283652209b390809' 
FROM File('/tmp/test_backup/20250221_0405a4ae764614f2283652209b390809.zip') 
SETTINGS allow_non_empty_tables=true

3. В результате будет восстановлена выбранная партиция из бэкапа и получено соответствующее сообщение:

image.png

Если бэкап содержит несколько партиций

В таком случае можно перечислить сразу несколько ID или названий партиций, например:

RESTORE TABLE kuma.events_local_v2 
PARTITIONS (20240405,'a1fbde7a-76d3-4bbc-a769-82126b41b56f',''),
(20240406,'faeede7a-76d3-4bbc-a769-82126b41e453','')
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.zip')
SETTINGS allow_non_empty_tables=true

Либо выполнить восстановления всех партиций из бэкапа (также полезно в случае, если не известно id или имя партиции)

RESTORE ALL 
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.zip')
SETTINGS allow_non_empty_tables=true

По аналогии с резервным копированием в таблице system.backups можно посмотреть состояние

SELECT * FROM system.backups ORDER BY start_time \G

image.png

Либо сразу с фильтрацией по соответствующему id, который был получен в результате выполнения восстановления:

SELECT * FROM system.backups WHERE id = 'd7758d2f-59c1-4650-afba-c1c288402bf5' \G

При восстановлении партиция ВСЕГДА восстанавливается на диск горячего хранения. Перенос данных на холодное хранение выполняется раз в 1 час. Для форсирования операции необходимо перезапустить сервис Ядра KUMA

Полезные ссылки

ClickHouse Backup and Restore: https://clickhouse.com/docs/en/operations/backup 

Настройка отказоустойчивости компонентов KUMA

Отказоустойчивость реализована встроенным функционалом KUMA для компонентов: Коррелятор и Хранилище (подробнее про кластер Хранилища). Для компонента Коллектор отказоустойчивость системы достигается за счёт комбинации наложенных средств HAProxy, Агента KUMA или другого балансировщика.

Отказоустойчивость компонентов KUMA можно обеспечить на уровне виртуализации

Отказоустойчивость Коррелятора и Хранилища

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

В Точках назначения добавляется второй компонент Коррелятора с его API портом для работы.

image.png

Далее необходимо перейти во вкладку дополнительные параметры, нас интересует параметр Политика выбора URL (URL selection policy), ниже описаны детали каждого метода:

  1. Любой (Any) - выбор любого доступного узла для отправки событий. Если в начале был выбран узел URL1, то события будут лететь в него до тех пор, пока он доступен, в случае выхода его из строя - будет выбран узел URL2, который тоже будет получать события пока сам не выйдет из строя. И так пока не закончатся активные узлы.
  2. Сначала первый (Prefer First) (рекомендуется для корреляторов) - события отправляются в URL1 до тех пор, пока сервис (URL1) живой. Если он выйдет из строя, события полетят в URL2. Когда URL1 снова станет активным, поток снова направится в него.
  3. По очереди (Round robin) (рекомендуется для хранилищ и агента KUMA для балансировки коллекторов) – отправляются события не по одному, а пачками. Количество событий в пачке почти всегда будет уникальным - пачка формируется, либо когда достигнут лимит ее размера, либо когда сработает таймер. Каждый URL получит равное количество пачек.

Параметр Ожидание проверки работоспособности (Health check timeout) – задает периодичность запросов Health check.

image.png

Детальнее про устройство кластера хранилища и комопонет keeper - тут

Отказоустойчивость Коллектора

Предварительно устанавливается на отдельную машину в качестве наложенного средства балансировщик HAProxy для своей версии ОС (процесс установки не будет показан в этой инструкции). Для Oracle Linux 8.x пакет установки HAProxy можно загрузить по ссылке - https://rpmfind.net/linux/RPM/centos/8-stream/appstream/x86_64/Packages/haproxy-1.8.27-5.el8.x86_64.html  

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

Настроим балансировку потока событий для двух коллекторов:
 

image.png

Конфигурация HAproxy будет следующая (путь файла конфигураций по умолчанию - /etc/haproxy/haproxy.cfg):

defaults
    timeout connect 5s
    timeout client 1m
    timeout server 1m

listen collectorTEST
    bind *:55777
    mode tcp
    balance roundrobin
    server tcp1 <IP_КОЛЛЕКТОРА_1>:5577 check
    server tcp2 <IP_КОЛЛЕКТОРА_2>:5578 backup check

Балансировщик прослушивает порт 55777, вы можете поменять конфигурацию порта на свое.

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

Для запуска HAproxy: 

haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)

Для остановки HAproxy: 

pkill haproxy

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

Отказоустойчивость за счет Rsyslog: Управление потоком событий с помощью rsyslog (kaspersky.com)

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

Отказоустойчивое ядро

HA ядра доступно для версии KUMA 2.1 и выше

Подробные детали по этой теме можно прочитать тут: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-kuma-versii-ot-21x-s-otkazoustoicivym-iadrom 

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

Отказоустойчивые балансировщики

VIP адрес для использования с балансировками (отказоустойчивость)

Информация, приведенная на данной странице, является разработкой community KUMA и НЕ является официальной рекомендацией вендора.

Чтобы настроить балансировку трафика между коллекторами KUMA:

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

2. Подготавливаем конфигурационный файл /etc/keepalived/keepalived.conf под свою задачу. Обратите внимание, конфига два! Нужно раскидать конфиг по серверам ACTIVE\BACKUP

#CONFIG FOR MASTER SERVER

! Barebones conf File for keepalived
 
  global_defs {
     notification_email {
       your_mail@testmailcompany.ru
     }
     notification_email_from keepalived@testmailcompany.ru
     smtp_server mail.testmailcompany.ru
     smtp_connect_timeout 60
  }
 
  vrrp_instance VI_1 {
      state MASTER
      interface ens192 #меняем под свой интерфейс
      virtual_router_id 100
      priority 100
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass 12345678 #меняем пароль!
      }
      virtual_ipaddress {
          10.10.10.10
      }
  }



#CONFIG FOR BACKUP SERVER

! Barebones conf File for keepalived
 
  global_defs {
     notification_email {
       your_mail@testmailcompany.ru
     }
     notification_email_from keepalived@testmailcompany.ru
     smtp_server mail.testmailcompany.ru
     smtp_connect_timeout 60
  }
 
  vrrp_instance VI_1 {
      state BACKUP
      interface ens192 #меняем под свой интерфейс
      virtual_router_id 100
      priority 100
      advert_int 1
      authentication {
          auth_type PASS
          auth_pass 12345678 #меняем пароль!
      }
      virtual_ipaddress {
          10.10.10.10
      }
  }

3. Запускаем службу командой sudo systemctl start keepalived на двух серверах, при  выводе ip -a можем наблюдать на MASTER сервере - дополнительный адрес - 10.10.10.10, для проверки "переезда" адреса можем остановить службу на MASTER сервере командой sudo systemctl stop keepalived, виртуальный адрес поднимется на BACKUP сервере.

4. Настраиваем по статье балансировку средствами nginx и получается следующая отказоустойчивая схема приёма логов на коллекторах:

image.png

Экстра возможности агента KUMA

Балансировка трафика

Агент KUMA может поддерживать множество подключений:

image.png

Типы коннекторов у агентов можно посмотреть тут (они отличаются в зависимости от типа ОС например) - https://support.kaspersky.com/KUMA/2.1/ru-RU/217690.htm 

Например, в нашей задаче мы поднимаем оди порт 51400:

image.png

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

test-fkE5R_kZn-transformed.png

А в дополнительных параметрах точки назначения выбираем Round robin ля балансировки:

image.png

В итоге получаем красивую балансировку:

image.png

Отправка копии трафика в несколько точек

Для решения такой задачи необходимо добавить еще однк точку назначения в конфигурации агента:

image.png

Точки назначения бывают такие:

image.png

Итого получаем нечто подобное:

image.png

 

Есть также сторонняя утилита по стресс тестов - Kraken STT - Kraken Stress Testing Toolkit (kraken-stt.ru)

 

Файловая интеграция с указанием файла и пути в событии

image.png

Для этого в агенте в коллектор необходимо указать транспорт internal в точке назначения:

image.png

Соответственно прием на коллекторе тоже должен быть транспортом internal:

image.png

Тестирование нормализации и нагрузки бинарем KUMA

Иполняемый файл KUMA имеет на борту полезный функционал тестирования, он может использоваться в отрыве от системы KUMA (полностью отдельно)  и вот его параметры запуска:

./kuma tools load --raw --events checkpoint-example.log --cfg config.cfg --limit 5000 --replay 200000
Пример события из файла checkpoint-example.log

<13>Sep 30 07:13:59 checkpoint.checkpoint.test 30Sep2020 07:13:59 10.1.253.3 product: VPN-1 &FireWall-1; src: 10.3.5.15; s_port: 61172; dst: 10.254.4.3; service: 53; proto: udp; rule:; policy_id_tag: product=VPN-1 & FireWall-1[db_tag={666B9F89-D1F9-7848-B5FB- BF8D97B768F8};mgmt=fw-mgmt;date=1601441138;policy_name=CBS_policy_Simplified_PlusDeskt];dst_machine_name: *** Confidential ***;dst_user_name: *** Confidential ***;fw_message: Connection is marked as trusted elephant flow. Use fastaccel tool to edit configuration if needed.;has_accounting: 0;i/f_dir: inbound;is_first_for_luuid: 131072;logId: -1;log_sequence_num: 11;log_type: log;log_version: 5;origin_sic_name: CN=x01_fw1,O=fw-mgmt.cu.com.pl.8pjujj;snid: 0;src_machine_name: *** Confidential ***;src_user_name: *** Confidential ***;user: *** Confidential ***;

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

Куда отправлять и как (только TCP) определено в конфигурационном файле config.cfg пример конфига:

{ "kind": "tcp", "name": "-", "connection": { "name": "-", "kind": "tcp", "urls": ["kuma.example.com:5141"]}}

 

Сторонняя утилита для нагрузочного тестирования 

Есть также сторонняя утилита по стресс тестов (Kraken) - Kraken STT - Kraken Stress Testing Toolkit (kraken-stt.ru)

Обновление ресурсов с помощью Kaspersky Update Utility (KUU)

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Загрузите утилиту:

Запустите с интерфейсом GUI:

image.pngПримите необходимые соглашения для работы:

image.png

image.png

При открытии интерфейса нажмите кнопку Start:

image.png

После выполнения, можно выбрать приложения:

image.png

Выбираем пакеты обновления соответвующей версии, затем Apply - ОК:

image.png

Запускаем загрузку пакетов для KUMA:

image.png

Убеждаемся в успешном выполнении:

image.png

Далее можно скопировать папку Updates на сам сервер KUMA (желательно на компонент ядра) и перейти в эту папку в консоли, затем выполнить команду:

python3 -m http.server

Запуститься веб-сервер с портом по умолчанию 8000:

image.png

Для прослушки другого порта:

python3 -m http.server 8080

Перейдите по адресу KUMA и порту 8000 в браузере, чтобы убедиться, что веб-сервер работает:

image.png

Добавьте репозиторий в интерфейсе KUMA, Параметры - Репозиторий, затем нажмите на кнопку Запустить обновление, затем Сохранить:

image.png

Перейдите в Ресурсы - Импорт ресурсов, выберите Тенант и источник обновления - Репозиторий:

image.png

После испорта ресурсов перейдите в ssh консоль и нажмите комбинацию клавиш Ctrl+C для остановки веб-сервера.

KUU поддерживает загрузку через прокси. Для автоматизации загрузки обновлений можно использовать работу с утилитой через командную строку - https://support.kaspersky.ru/kuu4-for-windows/howto/15693 

Установка компонентов KUMA за NAT

Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.

Начиная с версии KUMA 2.1 компоненты умеют находиться за NAT. Но при установле сервисов необходимо указывать дополнительные параметры, флаги:

Ниже покажем установку на примере службы коллектора (с остальными компонентами аналогично):

image.png

На Firewall (МЭ) осуществлен проброс портов 192.168.10.254:7210 → 10.10.10.100:7210 и 10.10.10.100:7135 → 192.168.10.254:7135

Строка установки коллектора:

/opt/kaspersky/kuma/kuma collector --core https://kuma-core.company.local:7210 --id <ваш_ID_сервиса> --advertise.api.port 7210 --advertise.fqdn gw.company.local --api.port 7135