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

• Подготовка ОС перед установкой и Требования
• Обновление/Установка KUMA
• Обновление/Установка KUMA версии до 2.0.Х (инсталляция «все в одном»)
• Обновление/Установка KUMA версии до 2.0.Х (распределенная инсталляция)
• Обновление/Установка KUMA версии от 2.1.Х
• Установка KUMA с отказоустойчивым ядром - RAFT
• Установка KUMA с отказоустойчивым ядром - Kubernetes
• Установка KUMA на ОС с установленным антивирусом
• Подготовка Astra Linux 1.7.х (с картинками)
• Установка компонентов KUMA на отдельную машину
• Установка службы хранилища (если этого не произошло при установке)
• Установка коллектора/коррелятора
• Установка хранилища KUMA
• Установка агента Linux
• Установка агента в режиме диод (Diode)
• Массовое обновление KUMA агентов
• Резервное копирование
• Резервное копирование и восстановление KUMA
• Резервная копия (локальная) событий из хранилища
• Архивировние и восстановление БД через ClickHouse BACKUP/RESTORE
• Обновление ресурсов с помощью Kaspersky Update Utility (KUU)
• Настройка отказоустойчивости компонентов KUMA
• Работа с балансировщиками
• Подключение агента KUMA через HA Proxy
• VIP адрес для использования с балансировками (отказоустойчивость)
• Балансировка UDP/TCP трафика (L3-L4) средствами службы Nginx
• Экстра возможности агента KUMA
• Тестирование нормализации и нагрузки бинарем KUMA
• Установка компонентов KUMA за NAT

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

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

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.ru/kuma/4.2/231034 

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

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

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

Внешние доступы

1. В процессе развертывания KUMA не подключается к внешним URL
2. В процессе работы KUMA может подключаться ко внешним URL в следующих случаях:
   • обновление контента (получение правил корреляции, нормализаторов и т.п.) по следующим адресам (либо используйте офлайн обновление ссылка)
   • обращение к KSN при наличии интеграции с KIRA или обнаружения DLL-Hijacking (требуется лицензия на модуль AI) по следующим адресам: https://llm-gateway.ksn.kaspersky-labs.com и https://dc1-file.ksn.kaspersky-labs.com
   • обращение к TIP (Threat Intelligence Portal) порталу для обогащения (требуется лицензия на TIP портал, отдельный продукт) или получение фидов продуктом Cyber Trace  по следующим адресам: https://wlinfo.kaspersky.com Также, во всех перечисленных случаях необходим доступ до серверов инфраструктуры публичных ключей: http://crl.kaspersky.com и http://ocsp.kaspersky.com

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

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

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/

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

• / и другие системные разделы - суммарно 16Гб
• /opt - все остальное место
• /var/log - 5Гб (не обязательно, но рекомендуется)

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

Процессор

Набор инструкций 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. Это можно сделать во время установки ОС.

sudo apt install chrony
sudo systemctl enable --now chronyd
sudo timedatectl | grep 'System clock synchronized'

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).

sudo setenforce 0

sudo reboot

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

ping ::1

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

Либо используйте конфигурацию хранилища без использования ipv6 - https://kb.kuma-community.ru/link/25#bkmrk-%D0%97%D0%B0%D0%BF%D1%83%D1%81%D0%BA-%D1%81%D0%BB%D1%83%D0%B6%D0%B1%D1%8B-keeper 

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

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

Убедитесь, что в рамках одной инсталляции KUMA на разных хостах не используются одновременно Python версии 3.6 и Python версии 3.10 и выше. Данное ограничение также распространяется на контрольный хост.

Пример НЕкорректной конфигурации:
Контрольный хост — Python 3.11.13
Целевые хосты — Python 3.6.8

Oracle Linux

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

• python3 (python 3.6 - 3.11)
• netaddr
• firewalld

sudo yum install -y python3.6 python3-netaddr

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

• compat-openssl11

sudo yum install -y compat-openssl11

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

• nss
• gtk2
• atk
• libnss3.so
• libatk-1.0.so.0
• libxkbcommon
• libdrm
• at-spi2-atk
• mesa-libgbm
• alsa-lib
• cups-libs
• libXcomposite
• libXdamage
• libXrandr

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

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

• python3 (python 3.6 - 3.11)
• python3-apt
• curl
• libcurl4
• netaddr
• python3-cffi-backend

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):

• libgtk2.0.0
• libnss3
• libatk-adaptor
• libatk1.0-0
• libdrm-common
• libgbm1
• libxkbcommon0
• libasound2

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

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

• python3 (python 3.6 - 3.11)
• python3-apt
• curl
• libcurl4
• openssl 1.1.1
• acl

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):

• 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

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

Процессор

• с частотой от 2 ГГц;
• с архитектурой x86_64 и поддержкой инструкций SSE 4.2;
• Рекомендуется использовать технологии Turbo Boost и Hyper-Threading (при наличии);

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

ОЗУ

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

• Рекомендуемый объем оперативной памяти от 16 Гб (для объемов данных ~ 16 - 32 ТБ [горячее хранение]);
• Рекомендуемый объем оперативной памяти от 32 Гб (для объемов данных ~ 32 - 48 ТБ);
• Рекомендуемый объем оперативной памяти от 48 Гб (для объемов данных ~ 48 - 64 ТБ);
• Рекомендуемый объем оперативной памяти от 64 Гб (для объемов данных ~ 64 - 80 ТБ);
• Рекомендуемый объем оперативной памяти от 128 Гб (для объемов данных > 80 ТБ);
  

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

Приемы оптимизации - ссылка

Диск

Отключайте файл подкачки (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 нужен IPv6, включите его в ОС, если он отключен;
• По возможности, используйте сети 10G и более высокого класса, минимально подойдет 1G.
• Пропускная способность сети критически важна для обработки распределенных запросов с большим количеством промежуточных данных. Также, скорость сети влияет на задержки в процессах репликации.
• Сетевые задержки не должны превышать 150 мс.

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); 

Сеть

• Обычно 1GbE достаточно для обычных развертываний. Но если есть возможность, то 10GbE более предпочтительно;
• Сетевые задержки не должны превышать 100 мс.
  

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

После проделанных выше инструкций все демо-сервисы должны быть в статусе зеленый. Корректность работы можно проверить, перейдя во вкладку События и нажав на значок увеличительного стекла (Поиск), должны появиться события, поступающие 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 будет выглядеть следующим образом:

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

Демонстрационные сервисы
Если Вы хотите, чтобы инсталлятор развернул демонстрационные сервисы, присвойте параметру 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 на актуальные имена хостов целевых машин.

• Группа core. Может содержать только одну целевую машину.
• Группа collector. Может содержать одну или несколько целевых машин.
• Группа сorrelator. Может содержать одну или несколько целевых машин.
• Группа storage. Может содержать одну или несколько целевых машин. Каждая машина должна иметь одну из следующих комбинаций параметров:
  • shard + replica + keeper
  • shard + replica
  • keeper
    

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

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

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

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

sudo -i

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

./install.sh distributed.inventory.yml

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

Корректность работы можно проверить, перейдя во вкладку События и нажав на значок увеличительного стекла (Поиск), должны появиться события, поступающие 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 при обновлении, в случае первичной установки смотрите пример заполенения тут): 

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

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

sed -i "s/kuma.example.com/$(hostname -f)/g" single.inventory.yml

cp distributed.inventory.yml.template distributed.inventory.yml

8. На серверах хранилищ, где используется роль Keeper, включите использование ipv6 (желательно, но не обязательно).

<keeper_server>
    <enable_ipv6>false</enable_ipv6>
</keeper_server>

ВАЖНО! С сервера хранилища до ядра должен быть доступен 7220 порт.

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  

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

/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.

• • Лог хранилища ведется в: /opt/kaspersky/kuma/storage/<ID хранилища>/log/storage
    

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

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

Если деморесурсы не появились при первичной установке в активных сервисах рекомендуется ручаня установка сервисов - подробнее

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

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

Кластер RAFT поддерживается в KUMA с версии 4.0 и позволяет обеспечить доступность компонентов ядра KUMA,  в случае сбоя работы одного из компонентов. Допустимо развертывать только нечетное количество сервисов Ядра KUMA. 

Схема ядра в RAFT (хранилище представлено с двумя репликами, т.е. с копией данных)

Теория

В кластере Raft каждый из серверов в каждый момент времени находится в одном из трёх состояний:

• Leader (лидер) – обрабатывает все клиентские запросы, является source of truth всех данных в логе, поддерживает лог фоловеров.
• Follower (фоловер) – пассивный сервер, который только «слушает» новые записи в лог от лидера и редиректит все входящие запросы от клиентов на лидера. По сути, является hot-standby репликой лидера.
• Candidate (кандидат) – специальное состояние сервера, возможное только во время выбора нового лидера.

Во время нормальной работы в кластере только один сервер является лидером, все остальные – его фоловеры. Например, в случае 3 компонентов ядра из строя может выйти толкьо 1 компонент, для иного количества компонентов - пока работает формула (n+1)/2. Полезная ссылка для понимания механизма работы: https://thesecretlivesofdata.com/raft/

Сетевые задержки не должны превышать 150 мс.

Расширение ядра до кластера в Raft

Сценарии установки с установкой Ядра в кластере Raft смотреть можно тут

Данный сценарий реализуется, если KUMA находится в инсталяции, где одно ядро (standalone). Для этого необходимо подготовить дополнительные целевые машины для установки сервисов, а также на контрольной машинке настроить обмен SSH  ключами. После создать копию файла на контрольной машине (с которой предполагается развертывание) expand.inventory.yml.template из распакованного архива KUMA 

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

Далее отредактировать файл expand.inventory.yml (разворачиваем дополнительные ядра 2 и 3):

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

Далее на контрольной машине с доступом root из папки с распакованным установщиком (скриншот выше) выполните следующую команду для начала установки:

./expand.sh expand.inventory.yml

В результате выполнения команды на каждой целевой машине, указанной в файле инвентаря expand.inventory.yml, появятся файлы для создания и установки дополнительных сервисов Ядра KUMA, для этого проверьте наличие директории /opt/kaspersky/kuma/kuma

В разделе Ресурсы → Активные сервисы нажмите Добавить и в раскрывающемся списке выберите Добавить сервис Ядро.

В открывшемся окне Добавить сервис Ядро укажите имя сервиса в поле Имя сервиса Ядро и нажмите Добавить. Добавленный сервис появится в списке Сервисы.

Установите флажок рядом с добавленным сервисом Ядра KUMA и на панели инструментов нажмите , в открывшемся меню нажмите Копировать идентификатор. Идентификатор сервиса Ядра KUMA понадобится для установки сервиса на сервере.

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

sudo /opt/kaspersky/kuma/kuma core --raft.join <FQDN хоста из секции kuma_core, где запущен первый сервис Ядра KUMA>:7210 --id <идентификатор сервиса Ядра KUMA, скопированный в веб-интерфейсе> --install

Повторите создание клиентской и серверной части сервиса Ядра KUMA для каждого хоста из группы kuma_core_peers.

На каждом хосте может быть установлен только один сервис Ядра KUMA.

После успешной установки в веб-интерфейсе KUMA, вы увидеть статус сервисов Вкл

Если ведущий узел выходит из строя, сервер будет следовать за новым ведущим, обеспечивая непрерывный доступ к интерфейсу SIEM или API.

Журналы Ядра KUMA хранятся в директории /opt/kaspersky/kuma/core/<идентификатор сервиса Ядра KUMA>/log/core.

Установка балансировщика - nginx

Установим балансировщик нагрузки nginx для удобства работы с кластером Raft, а именно обращение по единому hostname / IP-адресу.

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

Для установки балансировщика поднимем отдельный сервер и на него установим nginx, далее необходимо отредактировать файл /etc/nginx/nginx.conf и добавить конфиг в конец файла

stream {
    upstream raft_backend {
        server kuma-test.local:7220 max_fails=1 fail_timeout=5s;
        server kuma-core-2.local:7220 backup;
        server kuma-core-3.local:7220 backup;
    }

    server {
        listen 443;
        proxy_pass raft_backend;
        ssl_preread on;
    }
}

Далее перезапустить сервис systemctl restart nginx.service

Для проверки работоспособности отключаем сервис ядра на kuma-test  командой systemctl stop kuma-core-<идентификатор-ядра>.service. В браузере вводим https://<ip-балансировщика>, появится форма входа в интерфейс.

Далее нужно перейти в "Ресурсы" -> "Активные сервисы". Увидим, что сервис ядра отключен, но независимые компоненты имеют Статус: "Вкл"

Не забудьте запустить службу отключенного компонента, ядра systemctl start kuma-core-<идентификатор-ядра>.service

В данном случае в кластере всего три ноды, и больше одного выведенного из строя компонента ядра нельзя себе позволить, поскольку с менее чем 2 рабочими нодами теряется доступ к системе и перестает работать кластер

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

В нашем случае, если останется 1 живая нода - не сработает. Нода не образует кворум, а если захочет стать лидером, это никто не подтвердит.

Возможные ошибки кластера ядра:

Если вы столкнулись с ошибками после установки балансировщика, примеры:

request dropped as the cluster is not ready
failed to lookup: can't serve requests, not enough healthy nodes

Убедитесь, что у вас достаточное количество рабочих нод в кластере для его работы.

Альтернатива балансировщику - установка keepalived 

В основу данного способа заложена интеграция виртуального IP-адреса (VIP) с использованием функции keepalived для предоставления единой точки доступа. Такая конфигурация обеспечивает автоматическое переключение между узлами при отказе.  На каждом запускается скрипт для мониторинга состояния соответствующей службы ядра.  Все узлы обслуживают веб-интерфейс через собственные полные доменные имена (FQDN), но VIP обеспечивает унифицированный и стабильный доступ, обеспечивая доступность без вмешательства пользователя.

Детализация демонстрационных машин 

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

После подготовки файла  distributed.inventory.yml, необходимо сконфигурировать VIP для всех нод

Установка Keepalived на все основные узлы: dnf install -y keepalived

Для каждого узла требуется собственный скрипт для мониторинга локальной службы KUMA Core. Сохраните скрипт как /etc/keepalived/check_kuma.sh.

Пример для Core1 (ksiem-core1):

#!/bin/bash
if systemctl is-active --quiet kuma-core-00000000-0000-0000-0000-000000000000; then  
exit 0
else  exit 1
fi

Настройте имя службы для каждого узла (каждый имеет уникальное имя). Вы можете найти основную службу KUMA, выполнив команду на каждом узле: systemctl list-units --type=service | grep kuma-core

Сделайте скрипт исполняемым: chmod +x /etc/keepalived/check_kuma.sh

Далее настройте keepalived. Создайте или отредактируйте файл /etc/keepalived/keepalived.conf на каждом узле. Ниже представлена ​​адаптированная конфигурация.

Core -1

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state MASTER
    interface ens34              #необходимо поменять в соотетсвии со своей конфигурацией
    virtual_router_id 51
    priority 110
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
} 

Core -2

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens34             #поменяйте в соответcвии со своими параметрами
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
}

Core - 3

vrrp_script chk_kuma {
    script "/etc/keepalived/check_kuma.sh"
    interval 2
    timeout 3
    fall 2
    rise 3
}
vrrp_instance VI_1 {
    state BACKUP
    interface ens34             #поменяйте в соответcвии со своими сетевыми параметрами
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secretpass
    }
    virtual_ipaddress {
        192.168.100.200
    }
    track_script {
        chk_kuma
    }
}

Далее выполните команды 

systemctl enable keepalived
systemctl start keepalived

Зайдите в веб-интерфейс KUMA через VIP FKDN (ksiem.demo.lab) активируйте KUMA и убедитесь, что все ноды сервисов установлены и их статус "зеленый" 

Возможные проблемы

Проблема 1

Когда устанавливается сервис хранилища или другие ноды хранилища, необходимо указать все FQDN  ядер в команде, ниже представлен пример того, как установить хранилище в Raft -е ( 2 replica и 3 keeper)

Проблема 2. Как коллектор и коррелятор будут работать в этом режиме?

Когда вы создаете коллектор или коррелятор, все 3 ноды автоматически добавятся в скрипт, запустите этот скрипт на сервере (коллектора или коррелятора), в этом случае, если core1 упадет, то вы все равно будете иметь доступ к настройкам коррелятора или коллектора

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

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

Для установки 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 

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

• один контроллер (выделенный или совмещенный с рабочим узлом);
• один рабочий узел (выделенный, или совмещенный с контроллером);
• 0 и более выделенных рабочих узлов.

Минимальная конфигурация, на которую можно произвести установку - один контроллер, совмещенный с рабочим узлом. Данная конфигурация не обеспечивает отказоустойчивости 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/3.2/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 на ОС с установленным антивирусом необходимо в политике антивирусной защиты выставить исключение проверок средства защиты для папки:

/opt/kaspersky/kuma/*

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

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

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

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

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

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

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

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

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

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

Примечание 1

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

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

Пакет NetworkManager:

• предоставляет утилиту nmtui для настройки параметров в псевдографическом интерфейсе консоли;
• содержит инструмент nmcli для гибкой настройки в командной строке.

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

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

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. Публичные репозитории закомментированы.

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

Здесь вы можете изменить имя узла на 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

Пропишите 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 была успешно установлена, но служба хранилища не была развернута из демонстрационных ресурсах. Инструкция приведенная ниже подразумевает, что все действия и команды выполняются на серверах с размещенными файлами clickhouse и созданными учетными записями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для актуальных версий (c 3.2) с помощью 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

или

./expand.sh expand.inventory.yml

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

• Для установки отдельного хранилища (вне кластера ClickHouse) заполните данными о новой машине файл additional-storage-cluster.inventory.yml.template из инвентаря (его можно взять отсюда) из папки установки, поменяйте в скрипте установки install.sh плейбук (последняя строчка) с install.playbook.yml на additional-storage-cluster.playbook.yml, затем запустите установку.
• Для установки хранилища входящий в состав кластера ClickHouse) дополните данными о новой машине файл инвентаря distributed.inventory.yml (который ранее использовался для разворачивания системы) из папки установки.

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

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

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

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

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

3. Задайте необходимые параметры для агента в соответствии с ограничениями Linux-агентов: https://support.kaspersky.ru/help/KUMA/3.2/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>

cp kuma /opt/kaspersky/kuma/

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

chmod +x /opt/kaspersky/kuma/kuma

/opt/kaspersky/kuma/kuma license

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

cp agent /opt/kaspersky/kuma/ ; mv /opt/kaspersky/kuma/agent /opt/kaspersky/kuma/kuma_agent

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

chmod +x /opt/kaspersky/kuma/kuma_agent

/opt/kaspersky/kuma/kuma_agent license

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

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

   
   

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

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

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

С KUMA версии от 4.2 появилось создания точки назначения транспортом UDP

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

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

• Агент записывает события в файл во временной директории, указанную пользователем
• Агент переносит файл из временной папки в "Директорию, из которой диод данных получает события (Data diode source directory)" , попутно переименовывая файл. Название файла содержит sha256 хеш содержимого для возможности осуществления проверки целостности.

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

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

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

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

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

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

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

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

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

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

Необходимо при помощи списка контроля доступа (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

Сбор коллектором из изолированного сегмента

Для установки коллектора (т.к. агент поддерживает не все типы коннекторов) необходима связь с ядром, для этого ставим дополнительное отдельное ядро в изолированный сегмент, которое будет управлять этим коллектором. Далее коллектор в маршрутизации пишет результат обработки события НЕ в хранилище, а в файл (например: результирующий файл по работе с БД это JSON формат или CEF). Предварительно необходимо создать путь (папку) и дать права для пользователя kuma:

chown -R kuma:kuma /collector_file/
chown -R kuma:kuma /collector_file/result_file.txt

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

Массовое обновление KUMA агентов

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

Данный механизм работает с версии 3.4 KUMA, т.к именно в ней добавилась поддержка ключа --accept-eula

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

За основу берем скрипт

И заполняем в нём ключевые поля, а именно:

# Список серверов
$servers = @("server1.domain.local", "server2.domain.local")

# Задаем переменную версии
$version = "3.4.1.53"

# Локальный путь к файлу, который нужно скопировать
$localFilePath = "C:\Temp\kuma.exe"

# Путь на удаленном сервере, куда будет скопирован файл (если используется нестандартный путь для установки KUMA агента)
$remoteFilePath = "C$\Program Files\Kaspersky Lab\KUMA\kuma.exe"

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

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

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

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

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

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

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

для KUMA от 4.0 и выше используйте API v3

Для создания резервной копии ресурсов и сертификатов необходимо отправить следующий 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/v3/system/backup' -o backup.tar.gz

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

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

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

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

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

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

systemctl start kuma-mongodb.service

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

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=<путь к архиву>

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

• Резервное копирование KUMA (онлайн-справка): https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222208.htm 
• Создание резервной копии Ядра KUMA (Postman): https://www.postman.com/kl-ru-presales/workspace/kaspersky-products-apis-ru/request/23340929-bd766c26-c34b-467e-a28a-4ff65ac05328
• Восстановление Ядра KUMA из резервной копии (Postman): https://www.postman.com/kl-ru-presales/workspace/kaspersky-products-apis-ru/request/23340929-974b96b4-0876-449c-9001-9912783f6acc

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

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

С KUMA 4.0 путь к клиенту CH - /opt/kaspersky/kuma/storage/<ID Storage>/deps/clickhouse/bin/client.sh

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

Сохранение данных за определенную дату в файл 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

Gzip подходит для небольших объемов информации, т.к. он однопоточный. Для ускорения рекомендуется использовать pigz либо zstd, они используют все доступные ядра процессора, обеспечивая значительное ускорение экспорта больших CSV-файлов по сравнению с gzip. Если он не установлен, то:

sudo apt install pigz # Debian/Ubuntu
sudo yum install pigz # RHEL/CentOS

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

/opt/kaspersky/kuma/storage/c1114ebb-45e8-461c-a576-3a222dbfe3b2/deps/clickhouse/bin/client.sh \
  -d kuma \
  --multiline \
  --query "SELECT * FROM events_local_v2 \
           WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2025-08-13') \
           FORMAT CSVWithNames;" \
  | pigz > click_events.csv.gz

команда сохранения выглядит с zstd следующим образом:

/opt/kaspersky/kuma/storage/c1114ebb-45e8-461c-a576-3a222dbfe3b2/deps/clickhouse/bin/client.sh \
  -d kuma \
  --multiline \
  --query "SELECT * FROM events_local_v2 \
           WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2025-08-13') \
           FORMAT CSVWithNames;" \
  | zstd -T0 -15 -v -o click_events.csv.zst

Сохранение данных за определенную дату по определенному промежутку в часах (время в 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

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

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

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

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

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

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

./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" задать разрешенный путь для сохранения резервных копий

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

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

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

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

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

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

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

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

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

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

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

SELECT * FROM system.backups ORDER BY start_time \G

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

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

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

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

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

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

 с версии 4.0 путь к клиенту:  /opt/kaspersky/kuma/ID-storage/deps/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. В результате будет восстановлена выбранная партиция из бэкапа и получено соответствующее сообщение:

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

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

Либо сразу с фильтрацией по соответствующему 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 

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

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

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

• https://support.kaspersky.ru/kuu4-for-windows (рассматривается в статье) (работа через прокси ссылка)
• https://support.kaspersky.ru/kuu4-for-linux (работа через прокси ссылка)

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

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

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

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

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

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

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

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

python3 -m http.server

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

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

python3 -m http.server 8080

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

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

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

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

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

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

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

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

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

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

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

Далее необходимо перейти во вкладку дополнительные параметры, нас интересует параметр Политика выбора 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.

Детальнее про устройство кластера хранилища и комопонет 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 для балансировки трафика, подробнее тут.

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

Конфигурация 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>:5577 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 прокси не подойдет и потребуется написание скрипта для реализации следующего:

• создано 2 микросервиса коллектора SQL с одним конфигом
• установлены на сервера Coll-A и Coll-B
• один микросервис включен, второй - выключен
• у каждого из них сервисов в точке монтирования какая-то сетевая папка /opt/kaspersky/kuma/collector/<ID>/sql/ т.е. стейт (состояния) с позициями, которые уже были загружены из базы будут общими
• скрипт произаодит мониторинг за событиями аудита KUMA и если "микросервис перешел из зеленого в красный" и как только один SQL коллектор на сервере A стал красным - запускаем скриптом микросервис на сервере B и он начнет читать из базы из того же места (где остановился сервис А)

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

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

При накоплении буфера и если realtime поток событий от источника большой, то, например, коллектор подмешивает к потоку события в точку назначения из дискового буфера в соотношении 70% realtime + 30% из дискового буфера

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

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

Подробные детали по этой теме можно прочитать тут:

• https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-kuma-versii-ot-21x-s-otkazoustoicivym-iadrom 
• https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-kuma-s-otkazoustoicivym-iadrom-raft 

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

Т.к. в НА ядра, что в RAFT и Kubernetes (Control Plane) кластер нормально работает пока живы (n+1)/2 компонентов и в случае острой необходимости отказо- и катастрофо- устойчивости для двух ЦОДов, рекомендуется применять, мы это называем "3-й глаз":

3-й глаз / голос (witness / tie-breaker), где добавляется третий участник кворума (с минимальными ресурсами), который:

• не является полноценным ЦОДом
• Это:
  • небольшой VM в облаке
  • отдельная площадка
  • Lightweight-node
• машина "3-й глаз" должна быть очень стабильной по сети
  

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

• Ручное резервирование LB (Load Balancer). можно создать клон виртуальной машины с LB или скопировать конфигурацию на резервный "железный" сервер и в случае необходимости переключить трафик на резерв руками или с помощью какой-либо автоматизации. Возможны длительные задержки с момента обнаружения проблемы с LB до момента переключения трафика на резервный LB. FQDN и IP LB при этом переносятся на резервный хост;
• Можно использовать службу keepalived, позволяющая использоватьVRRP, пример настройки: https://docs.oracle.com/en/operating-systems/oracle-linux/6/admin/section_sm3_svy_4r.html. В качестве tcp балансировщиков могут выступать машины с nginx или haproxy. Переключение на резервный балансировщик при этом осуществляется автоматически. Такой подход может оказаться неприменим при размещении хостов с tcp балансировщиками в разных data-центрах, т.к. они использует VRRP;
• Для Nginx можно использовать коммерческую версию, пример - https://www.nginx.com/products/nginx/high-availability/;
• Отказоустойчивость компонентов также можно обеспечить функционалом систем виртуализации;
• Использование GSLB или других DNS-based балансировщиков "поверх" tcp LB, при такой схеме можно не покупать коммерческий Nginx.

Работа с балансировщиками

Подключение агента KUMA через HA Proxy

Схема работы агента KUMA через промежуточный узел с использованием haproxy

Для обращения агента KUMA к серверу Core используются порты 7210/tcp и 8429/tcp

Правила МЭ для работы

Для работы необходимо:

1. В файле hosts на хосте, где планируется установить агент kuma прописать fqdn- имя core kuma и ip-адрес с установленным haproxy (какое-то другое имя не подойдет, так как между компонентами kuma аутентификация происходит по сертификатам)
2. На промежуточном хосте с коллекторами установить haproxy
3. Установить агент kuma на машину, как рекомендует вендор, с указанием fqdn имени core kuma

Для нашего примера

1. В файл hosts прописываем  10.10.15.15  core.kuma.example
2.  В конфигурации с haproxy в файле /etc/haproxy/haproxy.cfg

Добавить следующий конфиг

frontend core.kuma.example:7210
        bind            *:7210
        mode            tcp
        log             global
        default_backend core_kuma_api

frontend core.kuma.example:8429
        bind            *:8429
        mode            tcp
        log             global
        default_backend core_kuma_agent

backend core_kuma_api
        mode                    tcp
        log                         global
        balance                 roundrobin
        option          tcp-check
        server          core   192.168.110.5:7210

backend core_kuma_agent
        mode                    tcp
        log                         global
        balance                 roundrobin
        option          tcp-check
        server          core   192.168.110.5:8429

3. Установить агента kuma

kuma.exe agent --core https://core.kuma.example:7210 --id 334b673f-b9a0-4dde-8398-45a7648ef767 --user имя_машины\имя_пользователя --install

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

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

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

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

• Команда для установки в Oracle Linux 8+:

  $sudo dnf install keepalived

• Команда для установки в Ubuntu 20.4:

  $sudo apt-get install keepalived

  
  

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 и получается следующая отказоустойчивая схема приёма логов на коллекторах:

Балансировка UDP/TCP трафика (L3-L4) средствами службы Nginx

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

Официальная документация по данному разделу приведена в Онлайн-справке на продукт: Управление потоком событий с помощью nginx (kaspersky.com)

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

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

• Команда для установки в Oracle Linux 8.6:

  $sudo dnf install nginx

• Команда для установки в Ubuntu 20.4:

  $sudo apt-get install nginx

  При установке из sources, необходимо собрать с параметром -with-stream:
  $sudo ./configure -with-stream -without-http_rewrite_module -without-http_gzip_module

2. Подготавливаем конфигурационный файл nginx.conf, где блоки выделенные красным меняем (название\ip адреса\порт) под свою задачу.

{
        upstream back_FW_ASA {
        server 10.11.17.145:514;
        server 10.11.18.145:514;
        }

и 

server {
                listen 514 udp;
                proxy_pass back_FW_ASA;
                proxy_bind $remote_addr transparent;
        }

При помощи данного файла nginx будет "прозрачно" для коллекторов пробрасывать оригинальный сетевой пакет трафика, позволяя передать реальный адрес\имя устройства, которое передало лог. При необходимости прослушивания TCP убираем в 16 строке udp.

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
events {
    worker_connections 1024;
}
stream {
        upstream back_FW_ASA {
        server 10.11.17.145:514;
        server 10.11.18.145:514;
        }
        server {
                listen 514 udp;
                proxy_pass back_FW_ASA;
                proxy_bind $remote_addr transparent;
        }
}

3. Укажите адреса коллекторов KUMA и порт, в примере их адреса\порты - 10.11.17.145:514 и 10.11.18.145:514, балансировка отправки сообщений будет вестись в соотношении 50:50 (при доступности двух коллекторов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• (?i)^[a-zA-Z]:\\Program Files
• (?i)^[a-zA-Z]:\\Program Files\(x86\)
• (?i)^[a-zA-Z]:\\Windows
• (?i)^[a-zA-Z]:\\ProgramData\\Kaspersky Lab\\KUMA

Однако существует возможность читать файлы из системных директорий через создание символических ссылок: например, mklink /D "C:\notsecret" "C:\Program Files (x86)\secret" и в конфигурации агента указать "C:\notsecret".

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

Получение дополнительных журналов с ОС Windows на примере Sysmon / PowerShell

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

Склейка событий Auditd

 в настройках коннектора агента, поставьте флаг  Auditd

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

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

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

./kuma tools load --raw --events checkpoint-example.log --cfg config.cfg --limit 5000 --replay 200000

• проигрывает "сырые" события из файла checkpoint-example.log (проигрываются строки в случайном порядке)

• потоком 5 kEPS (--limit 5000)
• будет проиграно 200000 событий (--replay 200000) из файла checkpoint-example.log 
  

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

• /lib64/libc.so.6: version `GLIBC_2.28'
• /lib64/libstdc++.so.6: version `CXXABI_1.3.8'
• /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21'
• /lib64/libstdc++.so.6: version `CXXABI_1.3.9' 
  

Куда отправлять и как (только 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)

Комьюнити скрипт - https://github.com/KUMA-Community/Sender 

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

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

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

• --advertise.api.port string API port to be reported to Core
• --advertise.fqdn string FQDN to be reported to Core

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

На 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