Установка и обновление
В данном разделе описаны установка и обновление, а также использование функционала KUMA для различных задач.
- Подготовка ОС перед установкой и Требования
- Обновление/Установка KUMA
- Обновление/Установка KUMA версии до 2.0.Х (инсталляция «все в одном»)
- Обновление/Установка KUMA версии до 2.0.Х (распределенная инсталляция)
- Обновление/Установка KUMA версии от 2.1.Х
- Установка KUMA версии от 2.1.Х с отказоустойчивым ядром
- Установка KUMA на ОС с установленным антивирусом
- Подготовка Astra Linux 1.7.х (с картинками)
- Установка компонентов KUMA на отдельную машину
- Установка коллектора/коррелятора
- Установка хранилища KUMA
- Установка агента Linux
- Установка агента в режиме диод (Diode)
- Установка службы хранилища (если этого не произошло при установке)
- Резервное копирование
- Резервное копирование и восстановление KUMA
- Резервная копия (локальная) событий из хранилища
- Архивировние и восстановление БД через ClickHouse BACKUP/RESTORE
- Настройка отказоустойчивости компонентов KUMA
- Экстра возможности агента KUMA
- Тестирование нормализации и нагрузки бинарем KUMA
- Обновление ресурсов с помощью Kaspersky Update Utility (KUU)
- Установка компонентов KUMA за NAT
Подготовка ОС перед установкой и Требования
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/231034.htm
Актуальные для развёртывания системы пакеты KUMA запросите у сотрудника Лаборатории Касперского.
Наборы правил корреляции и их описание доступно по ссылке - https://support.kaspersky.com/help/KUMA/3.2/ru-RU/SOC_correlation_rules_description.zip
Карта доступов для KUMA https://support.kaspersky.com/help/KUMA/3.2/ru-RU/217770.htm
Дополнение: Между шардами кластера хранилища необходимо также открывать порт 9000, несмотря на то, что это не указано в таблице документации
Подготовка целевой машины
Дистрибутивы
Oracle Linux 9.4: https://yum.oracle.com/ISOS/OracleLinux/OL9/u4/x86_64/OracleLinux-R9-U4-x86_64-dvd.iso
Ubuntu LTS 22.04: https://releases.ubuntu.com/jammy/ubuntu-22.04.4-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
.
Имя хоста можно задать во время установки, либо после.
Настоятельно не рекомендуется изменять FQDN машин после установки KUMA, особенно на сервере с компонентом Core! Это приведет к невозможности проверки подлинности сертификатов и нарушит сетевое взаимодействие между компонентами KUMA. Для восстановления работоспособности потребуется перевыпуск сертификатов всех сервисов, а также изменение их конфигурации!
Зарегистрируйте целевые машины в DNS-зоне вашей организации. Для пилотных инсталляций, как альтернативу, можно использовать файл hosts. Для этого на каждой целевой машине укажите в файле hosts имена всех машин и их ip-адреса (включая адрес машины, на которой происходит настройка).
Синхронизация времени
Настройте временную зону и синхронизацию системного времени с NTP-сервером на всех серверах KUMA. Это можно сделать во время установки ОС.
Пример команды для настройки NTP
sudo apt install chrony
sudo systemctl enable --now chronyd
sudo timedatectl | grep 'System clock synchronized'
Если доступ в Интернет отсутствует, то после установки chrony отредактируйте файл /etc/chrony.conf
, заменив в нем 2.pool.ntp.org
на адрес NTP сервера вашей организации.
Прочее
Задайте пароль пользователю root. Это можно сделать во время установки ОС.
Не создавайте на целевых машинах пользователя kuma! Он создается автоматически при установке продукта и наличие в системе пользователя с таким же именем может сделать вход в систему невозможным (придумайте другое имя).
Отключите SELinux на тех ОС, для которых это применимо (Oracle, Ubuntu).
Отключение SELinux
1. Выполните команду:
sudo setenforce 0
2. Откройте на редактирование файл /etc/selinux/config
и установите в нем параметру SELINUX=
значение disabled
3. Сохраните внесенные изменения и перезагрузите машину
sudo reboot
На серверах хранилищ включите использование ipv6. Если установка All-in-one, на целевой машине также требуется включить использование ipv6. Для проверки, что ipv6 включен, можно использовать команду:
ping ::1
Для включения ipv6 воспользуйтесь инструкцией из статьи.
Установка пакетов
Требования к установке на различных ОС приведены в официальной документации: https://support.kaspersky.com/help/KUMA/3.2/ru-RU/231034.htm
Oracle Linux
Основные пакеты:
- 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
- libatk-1.0.so.0
- libdrm-common
- libgbm1
- libxkbcommon0
- libasound2
sudo apt install -y libgtk2.0.0 libnss3 libatk-adaptor libatk-1.0.so.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
- libatk2.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 libatk2.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) в зависимости от нагрузки.
Пропускная способность диска является более важным фактором по сравнению с IOPS.
В случае использовании хранилищ в виде виртаульных машин на гипервизоре то необходимо использовать отдельные дисковые массивы для каждого из хранилищ. Также не желательно нахождение вместе с хранилищем других высоконагруженных сервисов на одном гипервизоре.
Файловая система ext4 — самый надежный вариант. XFS тоже работает хорошо. Большинство других файловых систем также должны работать нормально. FAT-32 и exFAT не поддерживаются из-за отсутствия жестких ссылок. Работа на NFS, тоже не лучшая идея.
Размер блока 64 КБ достаточен для большинства конфигураций RAID. Средний размер записи на сервере Clickhouse составляет примерно 1 МБ (1024 КБ), поэтому рекомендуемый размер страйпа (stripe) также составляет 1 МБ.
При необходимости размер блока можно оптимизировать, установив его равным 1 МБ, разделенному на количество дисков без четности в RAID-массиве, так что каждая запись распараллеливается на всех доступных дисках без четности. Никогда не устанавливайте размер блока слишком маленьким или слишком большим.
Keeper более критичен к диску и требует от 1000 IOPS, в зависимости от нагрузки, идеально использовать тип носителя NVMe
Сеть
- Keeper нужен IPv6, включите его в ОС, если он отключен;
- По возможности, используйте сети 10G и более высокого класса, минимально подойдет 1G.
- Пропускная способность сети критически важна для обработки распределенных запросов с большим количеством промежуточных данных. Также, скорость сети влияет на задержки в процессах репликации.
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.Х (инсталляция «все в одном»)
- Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой инструкции.
- Распакуйте архив:
tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
- Перейдите в распакованную папку:
cd kuma-ansible-installer
- Выполните команду копирования шаблона:
cp single.inventory.yml.template single.inventory.yml
- Для автоподстановки имени хоста в конфигурацию, используйте команду ниже:
Либо подставьте ранее использованный файл при обновлении. В случае ручной правки файла старайтесь не добавлять лишних пробелов. Если деморесурсы НЕ нужно разворачивать укажите в файлеsed -i "s/kuma.example.com/$(hostname -f)/g" single.inventory.yml
single.inventory.yml
в строке (значение false)deploy_example_services: false
. - Добавить файл лицензии в папку
kuma-ansible-installer/roles/kuma/files
и переименовать наlicense.key
- Входим в ОС из-под суперпользователя (root):
sudo -i
- Запустить установку:
./install.sh single.inventory.yml
- Должно все завершиться скриншотом ниже, ошибки отсутствуют (failed=0):
- Зайдите на веб интерфейс, проверьте статус Storage. Для этого перейдите во вкладку: Ресурсы - Активные сервисы. Если статус Storage отличается от зеленого (получить актуальный статус можно нажав кнопу обновить), то выполните нижеследующие команды.
После проделанных выше инструкций все демо-сервисы должны быть в статусе зеленый. Корректность работы можно проверить, перейдя во вкладку События и нажав на значок увеличительного стекла (Поиск), должны появиться события, поступающие KUMA или Сообщение «События не найдены». Если при поиске возникает ошибка, то необходимо проверить статусы сервисов в веб интерфейсе KUMA. Провести первичный траблшутинг по этому документу и сообщить ответственному инженеру Лаборатории Касперского в случае неуспеха.
Обновление/Установка KUMA версии до 2.0.Х (распределенная инсталляция)
- Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.
- Распакуйте архив (операции выполняются на ядре системы KUMA):
tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
- Перейдите в распакованную папку:
cd kuma-ansible-installer
- Добавить файл лицензии в папку
kuma-ansible-installer/roles/kuma/files
и переименовать наlicense.key
:cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
- Выполните команду копирования шаблона (либо подставьте ранее использованный файл при обновлении):
cp distributed.inventory.yml.template distributed.inventory.yml
- Добавьте публичный ключ SSH на все удаленные хосты в том числе и для хоста с которого происходит развертывание:
- На ВСЕХ хостах в конфигурации сервиса SSH должна быть включена опция удаленного входа от суперпользователя!
- На хосте с которого происходит развертывание сгенерируйте ключ командой (без указания пароля и доп. параметров):
ssh-keygen -t rsa
- Добавьте ключ по ssh на удаленные хосты и на сам хост развертывания:
ssh-copy-id login@remote_host_fqdn
- На ВСЕХ хостах в конфигурации сервиса SSH должна быть включена опция удаленного входа от суперпользователя!
- Отредактируйте файл инвентаря с командой:
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
Пункты 9, 10 и 16 данного раздела требуются только при обновлении с версии 2.0 на версию 2.1.0, рекомендуемая версия 2.1.3.49
Убедитесь, что все пункты из статьи подготовки в системе соблюдены
- Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой книге.
- Распакуйте архив (операции выполняются на ядре системы KUMA):
tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
- Перейдите в распакованную папку:
cd kuma-ansible-installer
- Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key:
cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
- Выполните команду копирования шаблона (либо подставьте ранее использованный файл single или distributed при обновлении, в случае первичной установки смотрите пример заполенения тут):
cp distributed.inventory.yml.template distributed.inventory.yml
Про устройство кластера хранилища можно почитать тут.
- ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды
hostname -f
- ВАЖНО! Хостнейм при команде
hostname -f
должен содержать хотя бы одну точку, пример:kuma.local
- На серверах хранилищ, где используется роль Keeper, включите использование ipv6.
ВАЖНО! С сервера хранилища до ядра должен быть доступен 7220 порт. - Измените конфигурацию сервиса хранилища
/usr/lib/systemd/system/kuma-storage-<ID хранилища>.service
пропишите:
TimeoutSec=57600 systemctl daemon-reload
- При наличии доменных пользователей в системе выполните следующие команды:
/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma db.users.updateMany({"accessMatrix":null},{$set: {"accessMatrix":{ "GET /resources" : false, "POST /resources/export" : false, "GET /services" : false, "POST /dictionaries/update" : false, "GET /assets" : false, "GET /dictionaries" : false, "POST /assets/import" : false, "POST /resources/upload" : false, "GET /users/whoami" : false, "GET /alerts" : false, "POST /events" : false, "GET /resources/download/:id" : false, "POST /alerts/close" : false, "GET /events/clusters" : false, "POST /resources/import" : false, "GET /activeLists" : false, "GET /tenants" : false, "POST /assets/delete" : false, "POST /resources/toc" : false, "POST /activeLists/import" : false}}}) systemctl restart kuma-core
- Активируйте (если он деактивирован) пользователя по умолчанию admin в веб интерфейсе и вспомните его пароль, он потребуется в процессе установки. Либо если используется пароль по умолчанию, можно запустить установку так:
-
./install.sh ./inventory.yml -e "accept_eula=yes default_admin_password=yes"
- Входим в ОС из-под суперпользователя (root), если это не было сделано ранее:
sudo -i
- Запустите установку:
./install.sh distributed.inventory.yml
- При наличии ошибки в конце установки
TASK [Start not orphaned KUMA storage services]
считаем установку успешной. Эта ошибка связана с таймаутом запуска ClickHouse, время старта процесса занимает ~10 минут. Убедитесь, что служба clickhouse потребляет ресурсы командой top.- Лог хранилища ведется в:
/opt/kaspersky/kuma/storage/<ID хранилища>/log/storage
- Лог хранилища ведется в:
- Если в KUMA была настроена интеграция с Active Directory и были заданы группы ролей пользователя, сразу после обновления программы необходимо выполнить на машине с Ядром KUMA запрос в монго. В противном случае параметры групп ролей пользователей могут быть потеряны:
/opt/kaspersky/kuma/mongodb/bin/mongo localhost/kuma var tenantID = db.tenants.findOne({ main: true })._id; db.settings.insert({_id: "f371fa1b-948e-45d2-a47c-86ddd67029ee", tenantID: tenantID, disabled: true, roleGroups: [], kind: 'adfs'});
- Зайдите на веб интерфейс ядра KUMA по адресу ядра -
https://<FQDN_CORE or IP_CORE>:7220
Учетные данные для входа по умолчанию:admin / mustB3Ch@ng3d!
В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить uninstall.sh.
Установка KUMA версии от 2.1.Х с отказоустойчивым ядром
Отказоустойчивость 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
Порты доступа для кластера ядра
Трафик KUMA core в отказоустойчивой конфигурации (трафик, в котором и источником и получателем выступают внешние сервисы KUMA здесь не рассматривается) | |||
В таблице указаны инициатор соединения (источник) и назначение. Номер порта на инициаторе может быть динамическим. Обратный трафик в рамках установленного соединения не должен блокироваться | |||
Источник | Назначение | Порт назначения | Тип |
Внешние сервисы KUMA | Балансировщик нагрузки | 7209 | tcp |
Внешние сервисы KUMA | Балансировщик нагрузки | 7210 | tcp |
Внешние сервисы KUMA | Балансировщик нагрузки | 7220 | tcp |
Внешние сервисы KUMA | Балансировщик нагрузки | 7222 | tcp |
Внешние сервисы KUMA | Балансировщик нагрузки | 7223 | tcp |
Рабочий узел | Балансировщик нагрузки | 6443 | tcp |
Рабочий узел | Балансировщик нагрузки | 8132 | tcp |
Управляющий узел | Балансировщик нагрузки | 6443 | tcp |
Управляющий узел | Балансировщик нагрузки | 8132 | tcp |
Управляющий узел | Балансировщик нагрузки | 9443 | tcp |
Рабочий узел | Внешние сервисы KUMA | в зависимости от настроек при создании сервиса | tcp |
Балансировщик нагрузки | Рабочий узел | 7209 | tcp |
Балансировщик нагрузки | Рабочий узел | 7210 | tcp |
Балансировщик нагрузки | Рабочий узел | 7220 | tcp |
Балансировщик нагрузки | Рабочий узел | 7222 | tcp |
Балансировщик нагрузки | Рабочий узел | 7223 | tcp |
Внешние сервисы KUMA | Рабочий узел | 7209 | tcp |
Внешние сервисы KUMA | Рабочий узел | 7210 | tcp |
Внешние сервисы KUMA | Рабочий узел | 7220 | tcp |
Внешние сервисы KUMA | Рабочий узел | 7222 | tcp |
Внешние сервисы KUMA | Рабочий узел | 7223 | tcp |
Рабочий узел | Рабочий узел | 179 | tcp |
Рабочий узел | Рабочий узел | 9500 | tcp |
Рабочий узел | Рабочий узел | 10250 | tcp |
Рабочий узел | Рабочий узел | 51820 | udp |
Рабочий узел | Рабочий узел | 51821 | udp |
Управляющий узел | Рабочий узел | 10250 | tcp |
Балансировщик нагрузки | Управляющий узел | 6443 | tcp |
Балансировщик нагрузки | Управляющий узел | 8132 | tcp |
Балансировщик нагрузки | Управляющий узел | 9443 | tcp |
Рабочий узел | Управляющий узел | 6443 | tcp |
Рабочий узел | Управляющий узел | 8132 | tcp |
Рабочий узел | Управляющий узел | 10250 | tcp |
Управляющий узел | Управляющий узел | 2380 | tcp |
Управляющий узел | Управляющий узел | 6443 | tcp |
Управляющий узел | Управляющий узел | 9443 | tcp |
Управляющий узел | Управляющий узел | 10250 | tcp |
Консоль управления кластером (CLI) | Балансировщик нагрузки | 6443 | tcp |
Консоль управления кластером (CLI) | Управляющий узел | 6443 | tcp |
Минимально кластер должен включать:
- один контроллер (выделенный или совмещенный с рабочим узлом);
- один рабочий узел (выделенный, или совмещенный с контроллером);
- 0 и более выделенных рабочих узлов.
Минимальная конфигурация, на которую можно произвести установку - один контроллер, совмещенный с рабочим узлом. Данная конфигурация не обеспечивает отказоустойчивости core и служит для демонстрации возможностей/проверки программной среды.
Для реализации отказоустойчивости необходим выделенный контроллер кластера и минимум 2 рабочих узла. Если контроллер кластера содержит рабочую нагрузку и под (pod) с Core размещается на нем, то его отключение приведет к полной потере доступа к Core.
На контроллерах кластера должен быть уникальный machine-id, это значит, что не рекомендуется клонирование машин с этой ролью, либо необходимо изменить ID на машинах до установки. Внимание! Допустимость данной операции должен определять администратор хоста с учётом возможного использования machine-id другими сервисами! rm /etc/machine-id /var/lib/dbus/machine-id && dbus-uuidgen --ensure=/etc/machine-id && dbus-uuidgen --ensure && reboot
- В нашем случае мы будем использовать установку 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/
- В распределенной установке kuma в секции инвентаря kuma_core нужно указать хост, который есть в роли worker (один из двух)
- ВАЖНО! Для успешной установки должны быть соблюдены следующие требования:
- все машины кластера должны быть добавлены в
/etc/hosts
; - установлены пакеты в соответствии с: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/244399.htm;
- На Astra Linux на машине балансировщика нужно установить в дополнение пакету nginx еще один пакет libnginx-mod-stream
- в
/var/lib/
должно быть не менее 32GB свободного места;
- все машины кластера должны быть добавлены в
- Значение переменных в инвентаре ansible:
need_transfer
– установка KUMA 2.1 происходит поверх предыдущей версии?;airgap
- значение неважно, может отсутствовать;low_resources
– использовать минимальные ресурсы для разворачивания? Отсутсвует по умолчанию. (Достаточно ресурсов: 2 CPU 4 RAM, НО при этом создается том хранения 4 Гб, без этого параметра том создается 512 Гб)- для части инвентаря kuma_k0s и переменных ansible_host важно указывать IP адреса
- если используется собственный балансировщик, то нужно указать
kuma_managed_lb: false
, при этом указать FQDN этого балансировщика (для корректного формирования сертификата коры) no_firewall_actions: false
- инсталлятор будет пытаться открыть необходимые порты на МЭ данного хоста
- Создайте резервную копию ресурсов и сертификатов, см. советующий раздел в этой инструкции.
- Распакуйте архив (операции выполняются на ядре системы KUMA):
tar -xvf kuma-ansible-installer-(ВЕРСИЯ).tar.gz
- Перейдите в распакованную папку:
cd kuma-ansible-installer
- Добавить файл лицензии в папку kuma-ansible-installer/roles/kuma/files и переименовать на license.key:
cp ПУТЬ_ДО_КЛЮЧА*.key roles/kuma/files/license.key
- Выполните команду копирования шаблона (пример заполненного файла в п. 0):
cp k0s.inventory.yml.template k0s.inventory.yml
- ВАЖНО! Регистр написания хостнеймов в inventory должен совпадать с выводом значения на хостах команды
hostname -f
- ВАЖНО! Хостнейм при команде
hostname -f
должен содержать хотя бы одну точку, пример: kuma.local - Входим в ОС из-под суперпользователя (root), если это не было сделано ранее:
sudo -i
- Запустите установку:
./install.sh k0s.inventory.yml
- Зайдите на веб интерфейс ядра KUMA по одному из адресов рабочих узлов или балансировщика, например, в нашем случае это - https://192.168.0.153:7220 Учетные данные для входа по умолчанию:
admin / mustB3Ch@ng3d!
- Для начального администрирования кластера воспользуйтесь командами этого раздела.
В случае, если при установке произошел сбой (НЕ обновлении), перед последующей установкой рекомендуется выполнить 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/*
Статья в скором времени будет дополняться...
Подготовка 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 должны быть доступны по сети от этой машины.
- Скопировать исполняемый файл kuma с любого из установленных компонентов KUMA (либо пакета установки), создайте идентичную структуру папок:
/opt/kaspersky/kuma/kuma
- Создайте пользователя и группу kuma на новой машине:
useradd -Mrs /usr/bin/false kuma
- Создайте структуру папок /opt/kaspersky/kuma/ на новой машине, добавьте папки correlator и collector.
- Поменяйте владельца и группу исполняемого файла и всех подпапок и принимаете соглашение
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 2.1.3.49) с помощью expand.inventory:
Перейдите в папку установки kuma-ansible-installer
cp expand.inventory.yml.template expand.inventory.yml
Отредактируйте файл expand.inventory.yml, пример установки хранилища на kuma-additional-storage-1.example.com ниже:
kuma:
vars:
ansible_connection: ssh
ansible_user: root
children:
kuma_collector:
kuma_correlator:
kuma_storage:
hosts:
kuma-additional-storage-1.example.com:
Запустите начало установки, следующей командой:
PYTHONPATH="$(pwd)/ansible/site-packages:${PYTHONPATH}" python3 ./ansible/bin/ansible-playbook -i expand.inventory.yml expand.inventory.playbook.yml
Для KUMA от 3.х:
PYTHONPATH="$(pwd)/ansible/site-packages:${PYTHONPATH}" python3 ./ansible/bin/ansible-playbook -i expand.inventory.yml expand.playbook.yml
Для старых версий:
- Для установки отдельного хранилища (вне кластера 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/2.1/ru-RU/217776.htm
4. Сохраните созданный ресурс агента.
5. Перейдите на вкладку Ресурсы – Активные сервисы.
6. Нажмите на кнопку Добавить сервис, выберите созданный ресурс агента и нажмите на кнопку Создать сервис.
7. Выберите галочкой созданный сервис агента и нажмите в верхней части экрана на кнопку Копировать идентификатор.
Идентификатор будет скопирован в буфер обмена. Сохраните полученный таким образом идентификатор, он потребуется для дальнейшей установки сервиса агента.
Установка агента в качестве службы
В данном разделе под <ID> понимается значение идентификатора агента, который был скопирован в предыдущем разделе в п. 7. Под <KUMA-FQDN> понимается FQDN ядра KUMA.
1. Если установка агента осуществляется на сервер, на котором уже установлены какие-либо компоненты KUMA, то шаги 2, 3, 5, 7 нужно пропустить.
2. Скопируйте из дистрибутива KUMA файл kuma-ansible-installer/roles/kuma/files/kuma
и переместите его на сервер для установки агента в любую директорию.
3. Создайте пользователя для запуска агента следующей командой
useradd -Mrs /usr/bin/false kuma
4. Создайте рабочую директорию для агента
mkdir -p /opt/kaspersky/kuma/agent/<ID>
5. Скопируйте файл kuma в директорию /opt/kaspersky/kuma/
cp kuma /opt/kaspersky/kuma/
6. Назначьте пользователя kuma владельцем директории
chown -R kuma:kuma /opt/kaspersky
7. Задайте права на выполнение файлу kuma
chmod +x /opt/kaspersky/kuma/kuma
8. Примите лицензионное соглашение
/opt/kaspersky/kuma/kuma license
На данном этапе можно выполнить ручной запуск агента для проверки его работоспособности. Для этого необходимо выполните команду
/opt/kaspersky/kuma/kuma agent --core https://<KUMA-FQDN>:7210 --id <ID> --wd /opt/kaspersky/kuma/agent/<ID>
Для остановки выполнения воспользуйтесь комбинацией клавиш Ctrl + C
9. Создайте файл с описанием сервиса агента
touch /usr/lib/systemd/system/kuma-agent-<ID>.service
10. Любым удобным способом откройте созданный файл на редактирование и укажите в нем следующую конфигурацию
[Unit]
Description=KUMA Agent Syslog
StartLimitIntervalSec=1
After=network.target
[Service]
Type=notify
Restart=always
RestartPreventExitStatus=99
TimeoutSec=300
RestartSec=5
WatchdogSec=60
User=kuma
Group=kuma
ExecStartPre=+-chown kuma:kuma /opt/kaspersky/kuma/agent
ExecStartPre=+-chown -R kuma:kuma /opt/kaspersky/kuma/agent/<ID>
ExecStart=/opt/kaspersky/kuma/kuma agent --core https://<KUMA-FQDN>:7210 --id <ID> --wd /opt/kaspersky/kuma/agent/<ID>/
LimitFSIZE=infinity
LimitCPU=infinity
LimitAS=infinity
LimitNOFILE=64000
LimitNPROC=64000
LimitMEMLOCK=infinity
TasksMax=infinity
TasksAccounting=false
[Install]
WantedBy=multi-user.target
11. Сохраните полученный файл
12. Выполните обновление конфигурации
systemctl daemon-reload
13. Запустите сервис агента
systemctl start kuma-agent-<ID>.service
14. Настройте сервису автозапуск
systemctl enable kuma-agent-<ID>.service
После установки сервиса агента индикация состояния в веб-интерфейсе KUMA на вкладке Ресурсы – Активные сервисы изменится на Зеленый. Также будет отображен FQDN и IP-адрес агента.
Диагностика неполадок
В случае возникновения сбоев в работе агента или ошибок установки службы диагностическую информацию можно получить следующими способами:
1. Просмотр состояния службы
systemctl status kuma-agent-<ID>.service
2. Просмотр журнала службы
journalctl -f -u kuma-agent-<ID>.service
3. Просмотр журнала агента
tail -f /opt/kaspersky/kuma/agent/<ID>/log/agent
Для получения дополнительной информации в журнале агента необходимо в веб-интерфейсе KUMA в параметрах агента установить галочку рядом с параметром Отладка после чего выполнить обновление параметров сервиса агента.
Установка агента в режиме диод (Diode)
Схема работы сбора в режиме diode
Агент, находящийся в изолированном сегменте сети, собирает события с источников и перемещает их в директорию источник, откуда их забирает диод (дата-диод). Диод переносит файлы в директорию назначения основной сети, удаляя их директории источника. Из директории назначения события собирает коллектор, удаляя их после считывания.
Для осуществления описанного способа передачи событий через диод используется пара 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
Установка службы хранилища (если этого не произошло при установке)
Данная инструкция применима только в случае, если KUMA была успешно установлена, но служба хранилища не была развернута из демонстрационных ресурсах. Инструкция приведенная ниже подразумевает, что все действия и команды выполняются на серверах с размещенными файлами clickhouse и созданными учетными записями.
В противном случае следует воспользоваться инструкцией: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-xranilishha-kuma
Создаем сервис хранилища перейдите в Ресурсы – Хранилища затем нажать на кнопку Добавить хранилище придумайте название и затем укажите количество дней хранения событий и событий аудита (от 365 дней срок хранения аудита) и узлы кластера (от версии 2.1) в соответствии с проведенной установкой, ниже пример для All-In-One установки:
затем нажмите Сохранить.
Публикуем созданный сервис Ресурсы – Активные сервисы затем выбрать созданный ранее сервис и нажать на кнопку Создать сервис.
В случае кластера хранилищ, опубликуйте этот же сервис по количеству отдельных машин хранилищ и keeper'ов
Скопируйте идентификатор сервиса:
Зайдите по ssh на сервер где будет разворачиваться сервис хранилища и выполните команду (api.port 7230 можно использовать произвольный никем не занятый порт), сначала выполним проверку (без установки, ошибки приналичии будут отображаться в консоли):
У каждой из машин хранилищ и keeper'ов должен быть свой уникальный идентификатор
sudo -u kuma /opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://<FQDN/ИМЯ_ХОСТА_СЕРВЕРА_ЯДРА>:7210 --api.port 7230
Если ошибок нет, то устанавливаем службу хранилища:
/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://<FQDN/ИМЯ_ХОСТА_СЕРВЕРА_ЯДРА>:7210 --api.port 7230 --install
В разделе Ресурсы – Активные сервисы убедитесь, что служба работает более 30 секунд с «зеленым» статусом индикатора:
Далее создадим точку назначения, которая используется в маршрутизации событий, перейдите в Ресурсы – Точки назначения, затем нажмите на кнопку Добавить точку назначения. Придумайте название и затем в поле URL укажите FQDN и порт службы хранилища, например: kuma-1-5-1.sales.lab:7230
, затем нажмите Сохранить.
Аналогичные действия понадобятся для установки остальных компонентов, только в интерфейсе будет доступна команда, которую необходимо будет выполнить для установки службы.
Для удаления службы хранилища (если необходимо), можно использовать следующую команду:
/opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --uninstall
Резервное копирование
Резервное копирование и восстановление KUMA
Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и НЕ является официальной рекомендацией вендора.
Официальная документация по данному разделу приведена в Онлайн-справке на продукт: https://support.kaspersky.com/help/KUMA/2.1/ru-RU/222208.htm
Резервное копирование и восстановление KUMA версии 2.1+
В связи с появлением возможности организации отказоустойчивого ядра в кластере kubernetes добавился новый механиз создания резервных копий ядра. Данный механизм использует API системы и в дальнейшем будет основным механизмом резервного копирования и восстановления.
Создание резервной копии Ядра KUMA по API
Для создания резервной копии ресурсов и сертификатов необходимо отправить следующий API-запрос:
GET /api/v1/system/backup
В ответ на запрос возвращается архив tar.gz, содержащий резервную копию Ядра KUMA. На хосте, где установлено Ядро, резервная копия не сохраняется. Сертификаты включаются в состав резервной копии.
Если операция выполнена успешно, создается событие аудита со следующими параметрами:
DeviceAction = "Core backup created"
SourceUserID = "<user-login>"
Пример команды для бэкапа через curl:
curl -k --header 'Authorization: Bearer <token>' 'https://<ip_kuma>:7223/api/v1/system/backup' -o backup.tar.gz
Восстановление Ядра KUMA из резервной копии по API
Для восстановления из резервной копии необходимо отправить следующий 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.
Восстановление данных из резервной копии доступно только при сохранении версии 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
Сохранение данных
Сохранение данных за определенную дату в файл CSV:
/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" > click_events.csv
Сохранение данных за определенную дату в файл CSV с максимальным сжатием (cырой файл CSV 1.4 Гб (строк 5630119) - сжатый 72 Мб):
/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDate(fromUnixTimestamp64Milli(Timestamp)) = toDate('2024-07-16') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz
Сохранение данных за определенную дату по определенному промежутку в часах (время в UTC) в файл CSV с максимальным сжатием (с 10:00:00 до 11:00:00):
/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "SELECT * FROM events_local_v2 WHERE toDateTime(fromUnixTimestamp64Milli(Timestamp)) > toDateTime('2024-07-16 10:00:00') AND toDateTime(fromUnixTimestamp64Milli(Timestamp)) < toDateTime('2024-07-16 11:00:00') FORMAT CSVWithNames;" | gzip -9 -c > click_events.csv.gz
Загрузка данных в хранилище
Распаковать данные с сохранением архива: gzip -dk click_events.csv.gz
Распаковать данные без сохранения архива: gzip -d click_events.csv.gz
Если необходима замена TenantID для видимости событий в определенном тенанте, нужно в распакованном файле CSV заменить третье значение после запятой (столбцы CSV "ID","Timestamp","TenantID","ServiceID","ServiceName"...
), пример команды (старый TenantID 746c6045-b929-4edd-8e1e-84ebe4a11880, новый TenantID 911c6045-b929-4edd-8e1e-84ebe4a11911):
sed -i 's/746c6045-b929-4edd-8e1e-84ebe4a11880/911c6045-b929-4edd-8e1e-84ebe4a11911/g' click_events.csv
Загрузка событий из файла CSV в хранилище ClickHouse:
/opt/kaspersky/kuma/clickhouse/bin/client.sh -d kuma --multiline --query "INSERT INTO events_local_v2 FORMAT CSV" < /root/click_events.csv
В CSV файле не должно быть пустых строк, иначе будет ошибка: Code: 27. DB::ParsingException: Cannot parse input: expected ',' before: '\n\n':
С утилитой clickhouse-backup
Для создания резервной копией можно воспользоваться утилитой clickhouse-backup. Исполняемый файл (clickhouse-backup-linux-amd64.tar.gz) для ОС Linux можно загрузить отсюда. Подробнее про утилиту https://github.com/Altinity/clickhouse-backup
Подготовка
Разархивируем загруженный файл:
tar -xvf clickhouse-backup-linux-amd64.tar.gz
Добавляем возможность исполнения файла:
chmod +x clickhouse-backup
Добавляем следующую строку <access_management>1</access_management>
в файл:
nano /opt/kaspersky/kuma/clickhouse/cfg/config.xml
В этот раздел конфига:
Создадим файл конфигурации:
nano click_backup_config.yml
Соследующим содержимым:
general:
log_level: error
#remote_storage: sftp
clickhouse:
host: kuma-aio.sales.lab
port: 9000
username: default
password: ""
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.*
#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. На вкладке "Активные сервисы" выбрать галочкой соответствующий сервис и нажать перезапустить в верхнем меню для применения настроек
Как проверить, что изменения применились
1. Перейдите в консоль соответствующего сервиса Хранилища
2. Выполните команду
cat /opt/kaspersky/kuma/clickhouse/cfg/config.d/override.xml
3. В выводе должны быть параметры, переопределенные в настройках севриса
Выполнение архивирования
1. Запустить клиента clickhouse командой
/opt/kaspersky/kuma/clickhouse/bin/client.sh
2. Выполнить запрос для просмотра партиций, например, такой
SELECT partition, name, partition_id
FROM system.parts
WHERE table='events_local_v2'
AND NOT positionCaseInsensitive(partition,'audit')>0
ORDER BY partition DESC
3. В результате будут выведены названия и id партиций
Для фильтрации по дате можно воспользоваться следующим запросом
SELECT partition, name, partition_id
FROM system.parts
WHERE substring(partition,2,8) = '20240406'
AND table='events_local_v2'
AND NOT positionCaseInsensitive(partition,'audit')>0
В результате будут выведены все партиции, кроме партиций событий аудита за 6 апреля 2024 года
4. Для архивации потребуется значение из первой колонки (partition) или последней (partition_id)
5. Для архивации партиции по id необходимо выполнить команду
BACKUP TABLE kuma.events_local_v2
PARTITION ID '04fb255c7659adfd1d43ed2dd0646b10'
TO File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
SETTINGS compression_method='gzip'
Описание параметров
04fb255c7659adfd1d43ed2dd0646b10 - id партиции из предыдущего запроса
/tmp/test_backup/ - директория для бэкапов
20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz - имя файла бэкапа (может быть произвольным)
compression_method='gzip' - выбранный метод сжатия
В случае, если все прошло успешно будет получено сообщение о создании бэкапа:
Также посмотреть состояние бэкапа можно через запрос к таблице system.backups
SELECT * FROM system.backups ORDER BY start_time \G
Либо сразу с фильтрацией по соответствующему id, который был получен в результате выполнения резервного копирования
SELECT * FROM system.backups WHERE id = '66bc2331-9d66-445f-87e7-56e42e2c2b58' \G
После выполнения резервного копирования партицию можно удалить из интерфейса KUMA, либо с помощью клиента ClickHouse, либо же дождаться истечения срока хранения.
Пример удаления партиции из интерфейса
1. Перейти на вкладку "Активные сервисы"
2. Выбрать нужное хранилище, нажать по его имени правой кнопкой мыши и выбрать пункт "Смотреть разделы"
3. В разделах выбрать нужный и нажать удалить
Выполнение восстановления
1. Запустить клиента clickhouse командой
/opt/kaspersky/kuma/clickhouse/bin/client.sh
2. Выполнить запрос для восстановления
RESTORE TABLE kuma.events_local_v2
PARTITION ID '04fb255c7659adfd1d43ed2dd0646b10'
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
SETTINGS allow_non_empty_tables=true
3. В результате будет восстановлена выбранная партиция из бэкапа и получено соответствующее сообщение:
Если бэкап содержит несколько партиций
В таком случае можно перечислить сразу несколько ID или названий партиций, например:
RESTORE TABLE kuma.events_local_v2
PARTITIONS (20240405,'a1fbde7a-76d3-4bbc-a769-82126b41b56f',''),
(20240406,'faeede7a-76d3-4bbc-a769-82126b41e453','')
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
SETTINGS allow_non_empty_tables=true
Либо выполнить восстановления всех партиций из бэкапа (также полезно в случае, если не известно id или имя партиции)
RESTORE ALL
FROM File('/tmp/test_backup/20240406_04fb255c7659adfd1d43ed2dd0646b10.tar.gz')
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
Настройка отказоустойчивости компонентов KUMA
Отказоустойчивость реализована встроенным функционалом KUMA для компонентов: Коррелятор и Хранилище (подробнее про кластер Хранилища). Для компонента Коллектор отказоустойчивость системы достигается за счёт комбинации наложенных средств HAProxy, Агента KUMA или другого балансировщика.
Отказоустойчивость компонентов KUMA можно обеспечить на уровне виртуализации
Отказоустойчивость Коррелятора и Хранилища
Предварительно устанавливается дублирующий компонент на отдельных от первого ресурсах (процесс установки не будет показан в этой инструкции). Ниже будет показан пример настройки для Коррелятора, для Хранилища процесс аналогичный.
В Точках назначения добавляется второй компонент Коррелятора с его API портом для работы.
Далее необходимо перейти во вкладку дополнительные параметры, нас интересует параметр Политика выбора URL (URL selection policy), ниже описаны детали каждого метода:
- Любой (Any) - выбор любого доступного узла для отправки событий. Если в начале был выбран узел URL1, то события будут лететь в него до тех пор, пока он доступен, в случае выхода его из строя - будет выбран узел URL2, который тоже будет получать события пока сам не выйдет из строя. И так пока не закончатся активные узлы.
- Сначала первый (Prefer First) (рекомендуется для корреляторов) - события отправляются в URL1 до тех пор, пока сервис (URL1) живой. Если он выйдет из строя, события полетят в URL2. Когда URL1 снова станет активным, поток снова направится в него.
- По очереди (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>:5578 backup check
Балансировщик прослушивает порт 55777, вы можете поменять конфигурацию порта на свое.
Опция backup используется для того, чтобы использовать этот (сервер с этой опицей) сервер в случае отказа первого.
Для запуска HAproxy:
haproxy -D -f /etc/haproxy/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
Для остановки HAproxy:
pkill haproxy
Для типа коннектора SQL прокси не подойдет и потребуется написание скрипта для реализации следующего:
- создано 2 микросервиса коллектора SQL с одним конфигом
- установлены на сервера Coll-A и Coll-B
- один микросервис включен, второй - выключен
- у каждого из них сервисов в точке монтирования какая-то сетевая папка /opt/kaspersky/kuma/collector/<ID>/sql/ т.е. стейт (состояния) с позициями, которые уже были загружены из базы будут общими
- скрипт произаодит мониторинг за событиями аудита KUMA и если "микросервис перешел из зеленого в красный" и как только один SQL коллектор на сервере A стал красным - запускаем скриптом микросервис на сервере B и он начнет читать из базы из того же места (где остановился сервис А)
Отказоустойчивость за счет Rsyslog: Управление потоком событий с помощью rsyslog (kaspersky.com)
На компонентах всех комопнентах, где присутсвует точка назначения возможно настроить буферизацию (ОЗУ и на диске), в случае если точка назначения недоступна.
Отказоустойчивое ядро
HA ядра доступно для версии KUMA 2.1 и выше
Подробные детали по этой теме можно прочитать тут: https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-kuma-versii-ot-21x-s-otkazoustoicivym-iadrom
В случае выхода из строя ядра, остальные компоненты будут продолжать корректно функционировать, тк у них в памяти сохраняется конфигурация от ядра (нельзя перезагружать компоненты, когда ядро недоступно).
Отказоустойчивые балансировщики
- Ручное резервирование 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.
Экстра возможности агента KUMA
Балансировка трафика
Агент KUMA может поддерживать множество подключений:
Типы коннекторов у агентов можно посмотреть тут (они отличаются в зависимости от типа ОС например) - https://support.kaspersky.com/KUMA/2.1/ru-RU/217690.htm
Например, в нашей задаче мы поднимаем оди порт 51400:
И мы хотим балансировать трафик между двумя коллекторами, для этого в точке назначения агента прописываем:
А в дополнительных параметрах точки назначения выбираем Round robin ля балансировки:
В итоге получаем красивую балансировку:
Отправка копии трафика в несколько точек
Для решения такой задачи необходимо добавить еще однк точку назначения в конфигурации агента:
Точки назначения бывают такие:
Итого получаем нечто подобное:
Тестирование нормализации и нагрузки бинарем KUMA
Иполняемый файл KUMA имеет на борту полезный функционал тестирования, он может использоваться в отрыве от системы KUMA (полностью отдельно) и вот его параметры запуска:
./kuma tools load --raw --events checkpoint-example.log --cfg config.cfg --limit 5000 --replay 200000
- проигрывает "сырые" события из файла
checkpoint-example.log
(проигрываются строки в случайном порядке)
Пример события из файла checkpoint-example.log
<13>Sep 30 07:13:59 checkpoint.checkpoint.test 30Sep2020 07:13:59 10.1.253.3 product: VPN-1 &FireWall-1; src: 10.3.5.15; s_port: 61172; dst: 10.254.4.3; service: 53; proto: udp; rule:; policy_id_tag: product=VPN-1 & FireWall-1[db_tag={666B9F89-D1F9-7848-B5FB- BF8D97B768F8};mgmt=fw-mgmt;date=1601441138;policy_name=CBS_policy_Simplified_PlusDeskt];dst_machine_name: *** Confidential ***;dst_user_name: *** Confidential ***;fw_message: Connection is marked as trusted elephant flow. Use fastaccel tool to edit configuration if needed.;has_accounting: 0;i/f_dir: inbound;is_first_for_luuid: 131072;logId: -1;log_sequence_num: 11;log_type: log;log_version: 5;origin_sic_name: CN=x01_fw1,O=fw-mgmt.cu.com.pl.8pjujj;snid: 0;src_machine_name: *** Confidential ***;src_user_name: *** Confidential ***;user: *** Confidential ***;
- потоком 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)
Обновление ресурсов с помощью 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 за 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