Ниже вы можете найти ответы на часто задаваемые вопросы, а также задать свои в комментариях
--- ##### **Q**: Где найти логи компонентов KUMA? **A**: Логи всех компонентов находятся по пути `/opt/kaspersky/kuma/Информация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и **НЕ** является официальной рекомендацией вендора.
Полная таблица доступов по портам (используемые порты) KUMA: [https://support.kaspersky.ru/kuma/4.2/217770](https://support.kaspersky.ru/kuma/4.2/217770)
Между шардами кластера хранилища необходимо также открывать порт **9000**, несмотря на то, что это не указано в таблице документации
Схема (хранилище представлено с двумя репликами, т.е. с копией данных):В случае если не дать доступ от Ядра до API портов служб (оранжевая стрелка), ядро не сможет отслеживать статусы служб и метрики, но события могут отправляться на корреляцию и хранение (если эти доступы открыты)
Для работы в изолированных сегментах через дата-диод, можно узнать в [**этой**](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-agenta-v-rezime-diod-diode) статье
Файл для редактирования (draw.io): [https://box.kaspersky.com/d/757e0187aeae4d1caffb/](https://box.kaspersky.com/d/757e0187aeae4d1caffb/) # Модель лицензирования KUMA (Licensing)Проверить поддержку версии продукта [https://support.kaspersky.com/corporate/lifecycle#b2b.block13.kuma](https://support.kaspersky.com/corporate/lifecycle#b2b.block13.kuma)
Лицензирование продукта Kaspersky Unified Monitoring and Analysis Platform (KUMA) происходит по **среднему** количеству обрабатываемых событий в секунду (EPS) за 24 часа.Минимально возможное количество EPS к приобретению = **500**.
Подсчет событий идет после процесса их обработки, то есть после фильрации, агрегации и обогащения.Если от коллектора событие отправляется в несколько точек назначения, то оно учитывается как одно событие.
В случае, если среднее значение превышает ограничение по EPS, указанное в лицензионном ключе, KUMA уведомляет о данном событии в интерфейсе. А также, если за 7 дней работы KUMA среднее значение EPS превышало ограничение 30% времени и более, KUMA дополнительно отправляет на email-адрес администратора уведомление о превышении количества полученных событий и продолжает далее подсчёт среднего значения EPS, не блокируя функционал.
**Лицензии срочные, выписываются на 1, 2 или 3 года**, если необходимо больше, то цена складвается из цен за ранее указанные периоды.По истечении лицензии **+ 7 дней** блокируются все функции (создание и / или изменение контента SIEM, обработка новых событий, корреляция, а также создание или изменение правил корреляции, нормализации, дашбордов, отчетов и пр.), за исключением просмотра информации по ранее собранным событиям.
--- ### Описание модулей лицензирования Решение класса SIEM (Security Information and Event Management), предназначенное для централизованного сбора, анализа и корреляции событий информационной безопасности с различных источников данных. Решение обеспечивает единую консоль мониторинга, анализа и реагирования на угрозы ИБ, объединяя как решения «Лаборатории Касперского», так и сторонних производителей. Начиная с версии 2.1 поддерживается развёртывание в режиме отказоустойчивости, при котором отказ одного или нескольких узлов не приводит к нарушению потоковой обработки событий и выявления инцидентов. Отказоустойчивость системы достигается за счёт встроенных механизмов маршрутизации данных. Дополнительных лицензии и лицензионного ключа для отказоуствойчивости не требуется. Отдельный модуль High Availability доступен только до версии 2.0 (включительно).Каждый из модулей решения KUMA включает в себя возможность сделать **50 запросов в Kaspersky Threat Lookup** для получения дополнительного контекста в ходе проведения расследования. Чтобы активировать эту функцию, отправьте запрос с указанием номера заказа на адрес intelligence@kaspersky.com.
#### Netflow Support (Netflow) События телеметрии о трафике, которые помогают в обнаружении аномалий на сетевом уровне и расследовании инцидентов. KUMA выполняет приём и обработку Netflow событий без ограничений, при этом данные Netflow не учитываются в счётчике EPS. Следует учитывать дополнительную нагрузку на мощности машины при анализе Netflow. Поддерживаются стандарты NetFlow v5/v9/IPFIX, Flexible NetFlow (FNF, где периодичноть темплейта должна быть до 1 мин.) и sFlow.Использовать фиды и Kaspersky CyberTrace, приобретённые в рамках данного модуля, можно **только для обогащения событий**, получаемых KUMA (использовать с другими SIEM системами, а также для интеграции с системами других классов недопустимо).
Предоставляется к KUMA дополнительно лицензия (Enterprise TIP) на продукт CyberTrace + сертификат для CyberTrace для получения фидов. При приобретении KUMA (любых модулей) также предоставляется доступ к Kaspersky Threat Intelligence Portal (до 100 запросов в Kaspersky Threat Lookup и до 10 запросов в Kaspersky Threat Analysis) в период действия лицензии. Портал позволяет получить дополнительный контекст в ходе проведения расследований. Чтобы активировать эту функцию, отправьте запрос с указанием номера заказа на адресОтправка событий из журналов начинается с самой начальной записи
Указанное в лицензии ограничение на максимальное количество устройств номинальное (на текущий момент)
#### Модуль AI (Artificial intelligence) ##### Kaspersky Investigation & Response Assistant (KIRA) Облачный ИИ-ассистент предназначен для анализа событий и корреляционных событий в KUMA. Он выполняет детальный разбор командных строк (Windows/Linux) с деобфускацией, формирует краткое содержание и предоставляет аналитическую информацию, необходимую для расследования инцидентов и приоритизации алертов. Для функционирования модуля требуется действующая лицензия KUMA и сертификат, обеспечивающий возможность выполнения запросов. Использование KIRA [**подробнее**](https://kb.kuma-community.ru/books/integracii/page/rabota-s-kira-i-primery-ispolzovaniia-iuzkeisy).  ##### Сервис AI (on-prem) по рейтингу и статусу активов AI-сервис ([Инструкция](https://kb.kuma-community.ru/books/integracii/page/ai-skoring-aktivov) по настройке) получает корреляционные события со связанными активами, формирует ожидаемые цепочки событий и обучает модель на поведении конкретной инфраструктуры. На основе анализа последовательности срабатываний корреляционных правил система определяет, является ли данная цепочка нетипичной, и автоматически: - рассчитывает AI-рейтинг актива (числовое значение от 0 до 1); - предоставляет оценку аномальности, на основе которой можно уточнить приоритет алерта Модель переобучается раз в сутки, а переоценка рейтинга активов выполняется каждый час для всех активов, участвовавших в событиях за последние 24 часа. Результат — снижение нагрузки на специалистов ИБ, фокус на реальных инцидентах и ускорение реакции за счет минимизации ложных срабатываний. ##### Обнаружение атак DLL Hijacking Облачный модуль обнаружение атак DLL Hijacking — AI механизм выявления одной из самых скрытных техник компрометации. DLL Hijacking используется злоумышленниками для запуска вредоносного кода через легальное ПО за счёт подмены динамических библиотек. Детектирование выполняется на этапе обогащения событий, что позволяет выявлять атаку ещё до её развития. Ключевые особенности решения: - Используется обогащение типа «Проверка DLL Hijacking» на корреляторе; - Требуется доступ к KSN; - В облачный AI-модуль передаются: - хэш и путь DLL-файла; - хэш и путь процесса; - цифровая подпись процесса (опционально) Облачный AI-детект усиливает классический сигнатурный подход, обеспечивая более высокую точность и выявление ранее неизвестных атак. Результат — раннее обнаружение DLL Hijacking, снижение риска обхода средств защиты и повышение эффективности реагирования на сложные атаки. Материалы: - [Видео](https://vk.com/video-28022322_456241195) из конференции PHDays - Прикладная [статья](https://securelist.ru/detecting-dll-hijacking-with-machine-learning-in-kaspersky-siem/113569/) об этой технике атаки - подробная [инструкция](https://support.kaspersky.com.br/help/KUMA/4.0/ru-RU/304384.htm) по настройке в официальной документации ##### Обнаружение (on-prem) использования скомпроментированной УЗ (Lateral Movement) Модуль представляет собой ML-механизм для выявления скрытого горизонтального перемещения злоумышленника внутри инфраструктуры. Работает с Correlator-NG / Correlator 2.0 (KUMA от 4.2) и анализирует поведение учетных записей, сравнивая текущую активность пользователя с его выученным историческим профилем. Модель обучается на данных за последние 60 дней, что позволяет точно определять индивидуальную «норму» и фиксировать отклонения. Покрываемые сценарии: - Аномальное количество ранее неизвестных IP-адресов, с которых выполнялся логон под учетной записью. - Аномальное количество новых host’ов, куда осуществляется логон и другие активности от имени аккаунта. - Прочие нетипичные действия, указывающие на попытки горизонтального перемещения. Результат — раннее обнаружение компрометации, сокращение времени присутствия атакующего в сети и предотвращение развития атаки на критические ресурсы. --- ### Предлагаемая техническая поддержка[https://support.kaspersky.ru/corporate/msa#tab2](https://support.kaspersky.ru/corporate/msa#tab2) по KUMA см. документ "Поддержка для Premium и Premium Plus"
#### Каналы связи| **Premium** | **Premium Plus** | |
| Company account (веб-портал, уведомления через почту) | ✔ | ✔ |
| Телефон | ✔ | ✔ |
| **Premium** | **Premium Plus** | |
| Критический (24 / 7) | 2 часа | 0,5 часа |
| Высокий (в рабочие часы) | 6 часов | 4 часа |
| Средний (в рабочие часы) | 8 часов | 6 часов |
| Низкий (в рабочие часы) | 10 часов | 8 часов |
| Программные исправления | **Premium** | **Premium Plus** |
| Удаленное подключение для диагностики проблем | ✔ | ✔ |
| Постпроектная поддержка\* | ✔ | ✔ |
| Частные исправления | ✔ | ✔ |
| Рекомендации по оптимизации | ✔ | ✔ |
| Персональный технический аккаунт менеджер (ТАМ) | ❌ | ✔ |
| Регулярные статус-встречи с ТАМ для анализа зарегистрированных инцидентов, связанных с ТП | ❌ | Ежеквартальный отчет |
| Разработка нормализаторов для нестандартных источников событий | 10 шт.\*\* | 20 шт.\*\* |
Ссылка на официальный ресурс: [https://academy.kaspersky.ru/course/kaspersky-unified-monitoring-and-analysis-platform-administration](https://academy.kaspersky.ru/course/kaspersky-unified-monitoring-and-analysis-platform-administration)
- Разворачивание KUMA для демонстрации решения - Расширение уже существующей инсталляции - Обеспечение отказоустойчивости ядра, хранилища и коллекторов - Настройка получения событий из разных источников - Настройка уведомлений #### Расследование (KL 051.4)Ссылка на официальный ресурс: [https://academy.kaspersky.ru/course/kaspersky-unified-monitoring-and-analysis-platform-investigation](https://academy.kaspersky.ru/course/kaspersky-unified-monitoring-and-analysis-platform-investigation)
*Фокус: Расследование и анализ атак* - Настройка обработки событий (нормализация, агрегация, обогащение, и т.д.) - Создание правил корреляции и реагирования, с последующим анализом данных для выявления угроз - Использование ресурсов и функций KUMA для анализа и выявления угроз (активные списки, словари, переменные, API и т.п.) #### Аналитик безопасности KUMAСсылка на официальный ресурс: [https://academy.kaspersky.ru/course/kuma-security-analyst](https://academy.kaspersky.ru/course/kuma-security-analyst)
*Фокус: мониторинг + первичный анализ* - Анализ алертов и событий безопасности (от первичного анализа до эскалации в инцидент) - Архитектура KUMA - Работа с логами: - поиск и фильтрация - ретроспективный анализ - SQL-запросы - Создание правила корреляции для выявления атак - Проводить расследование инцидентов и выявление угроз - Использовать подходы вроде MITRE ATT&CK для анализа атак --- ### Состав поставки дистрибутива ##### Обычная версия KUMA - **kuma-ansible-installer-k8s-\*.tar.gz** — архив с пакетами установки KUMA, где отказоустойчивое ядро разворачивается в кластере Kubernetes - **kuma-ansible-installer-\*.tar.gz** — стандартный архив с пакетами установки KUMA ##### Сертифицировнная версия KUMA **Обычный архив = certified-архив (ISO) + env\* (ISO)** *\*env — архив с компонентами, не подлежащими сертификации. Используется для получения функционирующего инсталлятора из сертифицированного архива.* # Типы хранения данных в KUMA В KUMA существует три типа пространства для хранения событий: - Горячее - Холодное - Архивное Для оптимизации использования дискового пространства и ускорения выполнения запросов в KUMA введено несколько уровней устройств хранения: - **Горячее (hot)** - оперативное хранение, обычно состоит из быстродействующих устройств с ограниченным объемом пространства \[Диски, например: NVMe или SSD\]. Поиск по событиям доступен из веб-интерфейса KUMA. - **Холодное (cold)** - медленные устройства, но большого объема \[Диски, например: HDD SAS или HDD SATA\]. Поиск по событиям доступен из веб-интерфейса KUMA. Основная идея разделения хранилищ на "горячие" и "холодные" состоит в том, что доступ к данным сохраняется, но при этом увеличиваются задержки. Используется сочетание настроек политики хранения ClickHouse и механизма переноса разделов таблиц между дисками. Плюсом подхода является возможность использовать в качестве хранилища любое примонтированное в качестве каталога Linux устройство, хранилища **HDFS** (используется функционал хранения, поиск делается с ClickHouse), а также **S3**.Планируется прекращение поддержки **HDFS** и рекомендуется запланировать перенос данных в **S3**.
Подробнее про холодное хранение - [https://support.kaspersky.ru/kuma/4.2/221257?page=help](https://support.kaspersky.ru/kuma/4.2/221257?page=help)
Для холодного по объему пространства нужно столько же, сколько и для горячего (нет дополнительной компресии), сами диски можно использовать менее производительней и подешвле. С версии 3.4 в связи с расширением функционала, изменился подход к определению срока хранения событий при использовании холодного хранения: Общий срок хранения событий определяется параметром TTL события - отсчет начинается от момента попадания события в хранилище. Значение TTL указывает, сколько времени событие будет храниться в KUMA. Время нахождения события в горячем хранилище определяется Вариантами условий хранения и может быть определено в днях, гигабайтах или процентах дискового пространства. Для горячего хранения можно применить до двух политик. Данные будет находиться в горячем хранилище до срабатывания одной из политик, после чего раздел с самыми старыми данными будет перемещен в холодное хранилище и будет находиться в холодном хранилище до истечения TTL. Общее время = горячее + холодное. Холодное пространство монтируется на сами хранилища (в случае локального типа холодного хранения) в нужном объеме, на рисунке ниже схематично показано, как это выглядит для двух реплик (R) и одного шарда (S): [](https://kb.kuma-community.ru/uploads/images/gallery/2023-11/gIfimage.png)Владельцем папки по точке монтирования холодного хранения должна быть УЗ kuma, команда: `chown -R kuma:kuma /mnt/cold_stor/`
Если добавить второй локальный диск, то данные между ними будут распределяться по алгоритму round-robin до тех пор, пока кусок данных, который мы хотим вставить не окажется больше свободного зарезервированного места на диске. Когда это случится все записи будут падать по round-robin в следующие диски. Если дисков всего 2, то соответственно в тот, где есть место
KUMA позволяет гибко настроить политику хранения событий (retention-период) по разным условиям: По дате, По объему, По проценту от занятого места на диске
# Первичный Траблшут в KUMA (Troubleshoot) ### Проверка статуса основных компонентов Основные службы KUMA: ```bash= systemctl status kuma-collector-ID_СЕРВИСА.service systemctl status kuma-correlator-ID_СЕРВИСА.service systemctl status kuma-storage-ID_СЕРВИСА.service systemctl status kuma-core-ID_СЕРВИСА.service systemctl status kuma-metrics-ID_СЕРВИСА.service ```В версии KUMA 3.2 сервис ядра изменил название на **kuma-core-00000000-0000-0000-0000-000000000000.service**
ID\_СЕРВИСА можно скопировать в веб-интерфейсе системы, в разделе Активные сервисы, выделив в checkbox нужный сервис, затем нажав кнопку скопировать ID. [](https://kb.kuma-community.ru/uploads/images/gallery/2023-08/I9Nimage.png)Перед рестартом коры (в версии KUMA 3.2) необходимо убедиться, что БД SQLite не находится в обслуживающем режиме (VACUUM), для этого перед рестартом убедитесь, что после выполенения команды **sqlite3 /opt/kaspersky/kuma/core/00000000-0000-0000-0000-000000000000/raft/sm/db 'PRAGMA locking\_mode;'** получаете ответ `normal`
--- ### Проверка журнала ошибок KUMA `/opt/kaspersky/kuma/<Компонент>/Для версий ниже 3.2
В случае если раздел метрик пустой (отсутствуют значения на дашбордах), то проверьте указан ли IP и hostname сервера KUMA в файле /etc/hosts, если нет то добавьте. Перезапустите службы: ```bash systemctl restart kuma-victoria-metrics.service systemctl restart kuma-grafana.service ``` Либо присутствует конфликт со службой Cockpit на Oracle Linux. Она слушает тот же порт 9090, что и Victoria Metrics. Останови Cockpit и посмотри, поднимутся ли метрики. Либо проблема из-за наличия прокси между ядром и АРМом, с которого к вебке подключались. --- ### Проверка прослушивания порта, например, 5144 ```bash netstat –antplu | grep 5144 ``` --- ### Работа с портами на МЭ (firewall-cmd) Проверка открытых портов на МЭ: ```bash firewall-cmd --list-ports ``` Добавление порта 7210 на МЭ: ```bash firewall-cmd --add-port=7210/tcp --permanent ``` Применение настроек: ```bash firewall-cmd --reload ``` --- ### Проверка получения событий на порту 5144 в ASCII ```bash tcpdump -i any port 5144 -A ``` --- ### Отправка тестового события на порт 5144, для проверки работы коллектора Для TCP: ```bash nc 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"' ``` Для UDP: ```bash nc -u 127.0.0.1 5144 <<< 'CEF:0|TESTVENDOR|TESTPRODUCT|1.1.1.1|TEST_EVENT|This is a test event|Low|message="just a test coming through"' ``` В случае наличия в сыром событии двух типов кавычек ' и ", то целесообразно отпралять событие из файла (для этого тестовое событие запишите в файл 1 строку). ``` cat test.txt | nc -u 127.0.0.1 5144 ``` Для HTTP: ```bash curl -X POST -d "Your message here" http://localhost:Для версий ниже 3.2
``` sudo -u kuma /opt/kaspersky/kuma/kuma core --external :7220 --internal :7210 --mongo mongodb://localhost:27017 ``` --- ### Ручная очистка пространства хранилища Если место на сервере хренения заканчивается, но еще не закончилось. Выберите в активных сервисах - сервис хранилища (storage) и нажмите на кнопку смотреть разделы. Удаляйте наиболее старые партиции. Далее (чтобы в будущем не заполнялось): 1. Resources/Storage - уменьшаем ретеншен период 2. после этого рестарт сервисов KUMA Storage. Изменения применятся примерно в течение часа и место освободится. --- ### Закончилось дисковое пространство Если место уже закончилось. - При all-in-one инсталляции в web консоль KUMA уже не пустит. Для all-in-one последовательность действий следующая: - Останавить все сервисы `systemctl stop kuma-*` - Удалить буферы коллекторов и коррелятора: `rm -rf /opt/kaspersky/kuma/collector/*/buffers/*` и `rm -rf /opt/kaspersky/kuma/correlator/*/buffers/` - Удалить кеш обогащения (если есть) коллекторов и коррелятора: `rm -rf /opt/kaspersky/kuma/collector/*/cache/enrichment/*` и `rm -rf /opt/kaspersky/kuma/correlator/*/cache/enrichment/` - Удалить лог файлы clickhouse: `rm -rf /opt/kaspersky/kuma/storage/*/logs/` - запустить сервис clickhouse: `systemctl start kuma-storage*` - запустить сервисы core: `systemctl start kuma-core-00000000-0000-0000-0000-000000000000` - залогиниться в web консоль KUMA, удалить лишние партиции (см. предыдущий пункт траблшута) - Стартуем оставшиеся сервисы KUMA (`kuma-metrics-В случае использования ядра в кластере **Raft** в параметре **--core** необходимо указать адреса всех серверов ядра через запятую.
```bash /opt/kaspersky/kuma/kuma storage --id <ВАШ_ИДЕНТИФИКАТОР> --core https://Правила корреляции из коробки в KUMA (SOC Package и Community-Pack) покрываются техниками и тактиками из матрицы MITRE ATT&CK
Начиная с версии KUMA 2.1 контент от Лаборатории Касперского (правила корреляции, нормализаторы, коннекторы и т.п.) публикуются в репозитории ЛК: [https://support.kaspersky.com/help/KUMA/4.0/ru-RU/250594.htm](https://support.kaspersky.com/help/KUMA/4.0/ru-RU/250594.htm)
Возможно также офлайн обновление с помощью утилиты KUU - [https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/obnovlenie-resursov-s-pomoshhiu-kaspersky-update-utility-kuu](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/obnovlenie-resursov-s-pomoshhiu-kaspersky-update-utility-kuu)
### Как получить SOC Package и другой коробочный контент? 1\. В Web-интерфейсе KUMA нужно настроить интеграцию с репозиторием Список серверов, до которых нужно предоставить доступ с KUMA представлен в официальной документации: [https://support.kaspersky.ru/common/start/6105](https://support.kaspersky.ru/common/start/6105)
Для обновления напрямую с репозитория **НЕЛЬЗЯ** использовать Proxy для KUMA < 3.4. Если для доступа к репозиторию требуется использование Proxy или у KUMA нет доступа в Интернет напрямую, то следует использовать Kaspersky Update Utility (KUU). Подробнее в статье: [https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/obnovlenie-resursov-s-pomoshhiu-kaspersky-update-utility-kuu](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/obnovlenie-resursov-s-pomoshhiu-kaspersky-update-utility-kuu)
2\. После настройки интеграции с репозиторием и Запуска обновления перейдите в Ресурсы и выберите Импортировать ресурсы  3\. Далее выберите Репозиторий в качестве источника Контент в системе применяется сверху вниз, проверяйте, что выбирается к применению, чтобы иметь актуальный набор ресурсов
4\. Нажав на имя конкретного пакета, вы увидите информацию о пакете, журнал изменений и перечень импортируемых ресурсов.Описание пакетов на странице справки [https://support.kaspersky.com/help/KUMA/4.0/ru-RU/250594.htm](https://support.kaspersky.com/help/KUMA/4.0/ru-RU/250594.htm)
Описание правил из SOC Package можно скачать из официальной документации: [https://support.kaspersky.com/help/KUMA/3.4/ru-RU/250594.htm](https://support.kaspersky.com/help/KUMA/3.2/ru-RU/250594.htm)
Альтернативно, можно воспользоваться интерактивной библиотекой правил по **[ссылке](https://kb.kuma-community.ru/kuma-rules-lib)**
##### На что ориентируемся при разработке правил Вширь: - Покрытие матрицы MITRE - Покрытие новых источников событий Вглубь - Отчет MDR Report - Отчет IR Report (GERT) - Отчет Threat Landscape Report - Внутренняя экспертиза (EDR, MDR) Ad-hoc - Интересные публикации в блогах и телеграмм-каналах - Замечания/предложения пользователей --- ### Где взять мапинг коробочных нормализаторов?Сопоставление полей коробочных нормализаторов можно скачать из официальной документации: [https://support.kaspersky.com/help/KUMA/3.4/ru-RU/267237.htm](https://support.kaspersky.com/help/KUMA/3.2/ru-RU/267237.htm)
 # Форматы времени, которые понимает KUMA ``` May 8, 2009 5:57:51 PM oct 7, 1970 oct 7, '70 oct. 7, 1970 oct. 7, 70 Mon Jan 2 15:04:05 2006 Mon Jan 2 15:04:05 MST 2006 Mon Jan 02 15:04:05 -0700 2006 Monday, 02-Jan-06 15:04:05 MST Mon, 02 Jan 2006 15:04:05 MST Tue, 11 Jul 2017 16:28:13 +0200 (CEST) Mon, 02 Jan 2006 15:04:05 -0700 Mon 30 Sep 2018 09:09:09 PM UTC Mon Aug 10 15:44:11 UTC+0100 2015 Thu, 4 Jan 2018 17:53:36 +0000 Fri Jul 03 2015 18:04:07 GMT+0100 (GMT Daylight Time) Sun, 3 Jan 2021 00:12:23 +0800 (GMT+08:00) September 17, 2012 10:09am September 17, 2012 at 10:09am PST-08 September 17, 2012, 10:10:09 October 7, 1970 October 7th, 1970 12 Feb 2006, 19:17 12 Feb 2006 19:17 14 May 2019 19:11:40.164 7 oct 70 7 oct 1970 03 February 2013 1 July 2013 2013-Feb-03 // dd/Mon/yyy alpha Months 06/Jan/2008:15:04:05 -0700 06/Jan/2008 15:04:05 -0700 // mm/dd/yy 3/31/2014 03/31/2014 08/21/71 8/1/71 4/8/2014 22:05 04/08/2014 22:05 4/8/14 22:05 04/2/2014 03:00:51 8/8/1965 12:00:00 AM 8/8/1965 01:00:01 PM 8/8/1965 01:00 PM 8/8/1965 1:00 PM 8/8/1965 12:00 AM 4/02/2014 03:00:51 03/19/2012 10:11:59 03/19/2012 10:11:59.3186369 // yyyy/mm/dd 2014/3/31 2014/03/31 2014/4/8 22:05 2014/04/08 22:05 2014/04/2 03:00:51 2014/4/02 03:00:51 2012/03/19 10:11:59 2012/03/19 10:11:59.3186369 // yyyy:mm:dd 2014:3:31 2014:03:31 2014:4:8 22:05 2014:04:08 22:05 2014:04:2 03:00:51 2014:4:02 03:00:51 2012:03:19 10:11:59 2012:03:19 10:11:59.3186369 // Chinese 2014年04月08日 // yyyy-mm-ddThh 2006-01-02T15:04:05+0000 2009-08-12T22:15:09-07:00 2009-08-12T22:15:09 2009-08-12T22:15:09.988 2009-08-12T22:15:09Z 2017-07-19T03:21:51:897+0100 2019-05-29T08:41-04 // no seconds, 2 digit TZ offset // yyyy-mm-dd hh:mm:ss 2014-04-26 17:24:37.3186369 2012-08-03 18:31:59.257000000 2014-04-26 17:24:37.123 2013-04-01 22:43 2013-04-01 22:43:22 2014-12-16 06:20:00 UTC 2014-12-16 06:20:00 GMT 2014-04-26 05:24:37 PM 2014-04-26 13:13:43 +0800 2014-04-26 13:13:43 +0800 +08 2014-04-26 13:13:44 +09:00 2012-08-03 18:31:59.257000000 +0000 UTC 2015-09-30 18:48:56.35272715 +0000 UTC 2015-02-18 00:12:00 +0000 GMT 2015-02-18 00:12:00 +0000 UTC 2015-02-08 03:02:00 +0300 MSK m=+0.000000001 2015-02-08 03:02:00.001 +0300 MSK m=+0.000000001 2017-07-19 03:21:51+00:00 2014-04-26 2014-04 2014 2014-05-11 08:20:13,787 // yyyy-mm-dd-07:00 2020-07-20+08:00 // mm.dd.yy 3.31.2014 03.31.2014 08.21.71 2014.03 2014.03.30 // yyyymmdd and similar 20140601 20140722105203 // yymmdd hh:mm:yy mysql log // 080313 05:21:55 mysqld started 171113 14:14:20 // unix seconds, ms, micro, nano 1332151919 1384216367189 1384216367111222 1384216367111222333 ``` # Как перенести KUMA на другой диск ### Кейс 1. Диск смонтирован в неверный разделПредположим, при подготовке сервера диск, предназначенный для хранения примонтировали не верно, например в папку `/var/data`. KUMA установлена в папку `/opt`
Запись в `/etc/fstab` выглядит примерно следующим образом ``` /dev/sdb1 /var/data xfs defaults 0 0 ``` Последовательность действий будет следующая 1\. Останавливаем сервисы kuma-\* ```bash systmctl stop kuma-* ``` 2\. Переносим данные из `/opt/kaspersky/kuma` в `/var/data/kaspersky/kuma` 3\. Отмонтируем папку `/var/data` ```bash umount /var/data ``` 4\. Редактируем `/etc/fstab`, что бы там была такая запись ```bash /dev/sdb1 /opt xfs defaults 0 0 ``` 5\. Выполняем команду ```bash mount -a ``` 6\. Проверяем, что файловая структура `/opt/kaspersky/kuma` корректна, проверяем, что на всех папках owner `kuma:kuma`, если нет, то можно запустить команду ```bash chown -R kuma:kuma /opt/kaspersky/kuma ``` 7\. Стартуем сервисы kuma-\* ```bash systemctl start kuma-* ``` --- ### Кейс 2. Появилась возможность подключить большой дискПредположим, при подготовке сервера, для папки `/opt` был выделен диск sdb размером 1 ТБ, но теперь есть возможность подключить диск sdc размером 12 Тб
Запись в `/etc/fstab` выглядит примерно следующим образом ``` /dev/sdb1 /opt xfs defaults 0 0 ``` Последовательность действий будет следующая 1\. Останавливаем сервисы kuma-\* ```bash systmctl stop kuma-* ``` 2\. Отмонтируем диск `/dev/sdb1` из `/opt` и монтируем в какой-то иной раздел, например в `/mnt/old_opt` ```bash mkdir /mnt/old_opt && umount /opt && mnt /dev/sdb1 /mnt/old_opt ``` 3\. Редактируем `/etc/fstab`, что бы там была такая запись ```bash /dev/sdc1 /opt xfs defaults 0 0 ``` 4\. Запускаем команду монтирования ```bash mount -a ``` 5\. Создаем структуру папок `/opt/kaspersky/kuma` 6\. Переносим данные из `/mnt/old_opt/kaspersky/kuma` в папку `/opt/kaspersky/kuma`. Проверяем иерархию папок, убеждаемся, что на всех папках owner `kuma:kuma`, если нет, то можно запустить команду: ```bash chown -R kuma:kuma /opt/kaspersky/kuma ``` 7\. Стартуем сервисы kuma-\* ```bash systemctl start kuma-* ``` 8\. Отмонтируем старый не нужный диск # Лайфхаки для шаблонов В KUMA во многих местах можно использовать шаблоны для обогащения. Но мало кто знает, что в template можно использовать не только значения полей, например, `{{.DeviceAddress}}`, но и другой функционал шаблонов GO ([ссылка](https://pkg.go.dev/text/template)). Ниже приведем несколько полезных лайфхаков, которые сделают ваши события красивыми и упростят обогащение и корреляцию. --- ### Простое обогащение Обогащать события можно не только классическими полями, например, `{{.DeviceAddress}}`, но и полями Extra, а также переменными. Шаблон с обычными полем: ```go {{.DeviceAddress}} ``` Шаблон с Extra полем: ```go {{index .Extra "myField"}} ``` Шаблон с переменными (в функциях переменных): ```go template('Значения локальных переменных {{index . 0}} и {{index . 1}} а также {{index . 2}}', $var1, $var2, $var10) ``` --- ### Обогащение с условиями Чтобы в message вставить текст `"Пользователь user1 на хосте user1-pc.local (10.10.10.10) выполнил команду 'whoami'"`, а hostname и address не всегда могут быть указаны, но хочется красивую надпись без пустых скобок или лишних пробелов, то можно использовать условия: ```go Пользователь {{.DestinationNtDomain}}\{{.DestinationUserName}} на хосте {{if and .DeviceAddress .DeviceHostName}} {{.DeviceHostName}} ({{.DeviceAddress}}) {{else if .DeviceAddress}} {{.DeviceAddress}} {{ else }} {{.DeviceHostName}} {{ end }} выполнил команду "{{.DeviceCustomString4}}" ``` Такой же шаблон можно создать и с Extra-полями. Например, в поле события DeviceProcessName нужно записать значение из Extra-поля myField1, а в случае его отсутствия - myField2: ```go {{if index .Extra "myField1"}}{{index .Extra "myField1"}}{{else}}{{index .Extra "myField2"}}{{end}} ``` Еще пример: ```go {{if eq .DeviceCustomString1 "" }}{{""}}{{else}}{{"vlan"}}{{end}} ``` Также пример с использованием логических операторов `and` и `or`: ```go {{if and (eq .DeviceEventCategory "Application") ((or (eq .DeviceCustomString4 "MSSQL") (eq .DeviceCustomString4 "SQLISPackage")))}}{{.DestinationUserName}}{{end}} ``` Еще пример: ```go {{if and ((eq .DeviceCustomIPv6Address2 "") (not (eq .SourceAddress ""))) }}{{.SourceAddress}}{{else}}{{.DeviceCustomIPv6Address2}}{{end}} ``` --- ### Использование шаблонов с корреляционными правилами В правилах standard можно в шаблоне указать количество базовых событий, которые попали в окно корреляции: ```go {{ len (.BaseEvents) }} ``` В правилах standard можно в шаблоне перечислить все значения, которые были в базовых событиях: ```go {{range .BaseEvents}} {{.SourceUserName}}{{end}} ``` В правилах standard можно в шаблоне достать значение из конкретного события, используя условия: ```go {{range .BaseEvents}}{{if eq .DeviceEventClassID "4688"}}{{.DestinationProcessName}}{{end}}{{end}} ``` Также в шаблонах можно использовать переменные, например, можем весь массив сырых событий положить в отдельную переменную $baseEvents и использовать её дальше. Пример ниже сортирует события 4104 по dcn1 и конкатенирует куски ScriptBlockText, чтобы в корреляционном событии получить весь PowerShell скрипт, а не куски из 15,5к символов. ```go {{ $baseEvents := .BaseEvents }} {{range $index, $element := $baseEvents}} {{range $i, $e := $baseEvents}} {{if eq $e.DeviceCustomNumber1 (len (printf "a%*s" $index ""))}} {{.S.ScriptBlockText}} {{end} }{{end}} {{end}} ``` ### Шаблоны с алертами В правиле обогащения, когда вы обращаетесь, вы как бы находитесь в событии и можете напрямую обращаться к полям. Но в шаблоне уведомлений вы находитесь уже в алерте и в нем нет полей события, но сами события есть. Поэтому нужно сначала проитерироваться по Events (корреляционные события) или дополнительно по Events.BaseEvents (базовые события корреляционных) и оттуда достать уже поле, куда вы в правиле корреляции все сложили.  --- ### Полезные ссылки Другие варианты работы с шаблонами GO в KUMA: - [https://support.kaspersky.com/kuma/2.1/ru-ru/233508.htm](https://support.kaspersky.com/kuma/2.1/ru-ru/233508.htm) - [https://pkg.go.dev/text/template](https://pkg.go.dev/text/template) # Замена сертификата (веб - интерфейсе) KUMAПроцесс перевыпуска сертификата ядра в версии KUMA 3.2 был изменен! Актуальная информация приведена в онлайн-справке: [https://support.kaspersky.ru/help/KUMA/3.2/ru-RU/275543.htm](https://support.kaspersky.ru/help/KUMA/3.2/ru-RU/275543.htm) и [https://support.kaspersky.ru/kuma/3.2/217747](https://support.kaspersky.ru/kuma/3.2/217747 "https://support.kaspersky.ru/kuma/3.2/217747")
### Общая информация После установки Ядра KUMA установщик создает следующие сертификаты в папке /opt/kaspersky/kuma/core/certificates: - Самоподписанный корневой сертификат ca.cert с ключом ca.key. Подписывает все другие сертификаты, которые используются для внутренней связи между компонентами KUMA. - Сертификат internal.cert, подписанный корневым сертификатом, и ключ internal.key сервера Ядра. Используется для внутренней связи между компонентами KUMA. - Сертификат веб-консоли KUMA external.cert и ключ external.key. Используется в веб-консоли KUMA и для запросов REST API.Между взаимодействием компонентов KUMA не должно быть SSL-инспекции
### Запрос сертификата от центра сертификации CA Создаем файл `openssl.cnf`: ```bash =====это пример, вписываем свои значения====== [ req ] default_bits = 4096 # RSA key size encrypt_key = no # Protect private key default_md = sha256 # MD to use utf8 = yes # Input is UTF-8 string_mask = utf8only # Emit UTF-8 strings prompt = no # Prompt for DN distinguished_name = server_dn # DN template req_extensions = server_reqext # Desired extensions [ server_dn ] countryName = RU # ISO 3166 localityName = Moscow organizationName = MYCOMPANY organizationalUnitName = SOC commonName = kuma.mycompany.ru # Should match a SAN under alt_names [ server_reqext ] basicConstraints = CA:FALSE keyUsage = critical,digitalSignature,keyEncipherment extendedKeyUsage = serverAuth,clientAuth subjectKeyIdentifier = hash subjectAltName = @alt_names [alt_names] DNS.1 = kuma.mycompany.ru IP.1 = 1.2.3.4 ``` Делаем запрос на сертификат: ```bash openssl req -new -nodes -sha256 -out external.csr -config /root/cert/openssl.cnf -keyout external.key ``` В текущем каталоге будут созданы файлы external.key (файл с закрытым ключом ) и external.csr (файл запроса на сертификат) Отдаем запрос на сертификат в центр сертификации. От центра сертификации должны получить сертификат сервера и корневой сертификат центра сертификации и все сертификаты промежуточных центров сертификации если они есть. - Все сертификаты должны быть в формате PEM (BASE64). - Содержимое сертификатов должно выглядеть - ( -----BEGIN CERTIFICATE----- и -----END CERTIFICATE-----) Полученные сертификаты необходимо объединить в одну полную цепочку сертификатов в правильном порядке. ```bash openssl x509 -inform PEM -in server.pem > external.cert openssl x509 -inform PEM -in subca.pem >> external.cert openssl x509 -inform PEM -in root.pem >> external.cert ```В файле с сертификатами важен порядок и должнен быть примерно такой: rootca-subca1-subca2-subca3-...
Полученный файл external.cert необходимо проверить на корректность (должен быть вывод списка цепочки сертификатов): ```bash openssl crl2pkcs7 -nocrl -certfile external.cert | openssl pkcs7 -print_certs -noout openssl verify external.cert #external.cert: OK ``` Проверяем корректность полученного сертификата и ключа (результат должен совпадать): ```bash openssl x509 -noout -modulus -in external.cert | openssl md5 #(stdin)= 239994c3bd2a90507a548bf373127e18 openssl rsa -noout -modulus -in external.key | openssl md5 #(stdin)= 239994c3bd2a90507a548bf373127e18 ``` ### Замена в обычной инсталляции (не кластер ядра)Перед заменой пары external.cert external.key создайте их резервную копию.
Создание источников событий происходит один раз в минуту с именем следующего формата после парсинга: "DeviceProduct|DeviceHostname|DeviceAddress|DeviceProcessName".
Настроим политику мониторинга для этого источника: хотя бы 1 событие в течение 1 минуты. Перейдите на вкладку **Политики мониторинга** и наша политика будет выглядеть следующим образом: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/8GPimage.png) Также можно настроить электронную почту для уведомлений в случае срабатывания политики. Затем необходимо нажать на кнопку **Добавить**. Затем необзодимо перейти снова на вкладку **Список источников событий**, выделить источник и закрепить ранее созданную политику: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/tRcimage.png) Флажок статуса источника после добавления станет зеленым (означает - соответствие политике). Убедимся, что правило корреляции мониторинга источников (в стоставе Pre-Sales-Pack) добавлено в коррелятор: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/f8aimage.png) Отключаем подачу событий и получаем следующее: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/HFQimage.png) В событиях: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/tb6image.png) Алерт: [](https://kb.kuma-community.ru/uploads/images/gallery/2023-09/Pm6image.png) # Аудит изменений по активамИнформация, приведенная на данной странице, является разработкой команды pre-sales и/или community KUMA и **НЕ** является официальной рекомендацией вендора.
Официальная документация по данному разделу приведена в Онлайн-справке на продукт: [https://support.kaspersky.com/KUMA/2.1/ru-RU/233948.htm](https://support.kaspersky.com/KUMA/2.1/ru-RU/233948.htm)
Аудит изменений по активам позволяет произволить корреляцию событий аудита по активам по измененям данных ассета. Перейдите в раздел **Параметры - Аудит** **активов** веб-интерфейсе KUMA. Щелкните (или добавьте) на тенант и выберите по каким параметрам вести аудит (чтобы производить корреляцию по изменениям необходимо добавить коррелятор): [](https://kb.kuma-community.ru/uploads/images/gallery/2023-10/image.png)Событие формируется на каждое изменение: по одному событию на каждое изменение (например, добавлено 5 уязвимостей - значит будет 5 событий аудита ассетов с типом "Добавление уязвимости ассета").
В событиях информацию можно найти следующим запросом: ```sql SELECT * FROM `events` WHERE DeviceEventCategory = 'Audit assets' ORDER BY Timestamp DESC LIMIT 250 ``` [](https://kb.kuma-community.ru/uploads/images/gallery/2023-10/JsTimage.png) Типы событий по которым ведется аудит: - Ассет добавлен. Создание ассета любым способом: вручную через web-интерфейс KUMA, REST API, импорт KSC и тд. - Ассет изменен. Изменены такие поля как: Name, IP address, Mac Address, FQDN, Operating system. - Ассет удален. Ассет помечается как удаленный, если был удален вручную пользователем или если по нему не пришла информация из KSC по истечению срока в параметре TTL. - Добавление уязвимости ассета. Пришла информация о новой уязвимости, ранее отсутствующей у ассета. - Устранение уязвимости ассета. Уязвимость считается устраненной, если по ней отсутствует информация во всех источниках ассета. Информация об уязвимостях может приходить от разных источников. Считаем уязвимость устраненной, если со всех источников пришла информация об ее устранении. - Ассет добавлен в категорию. Реативная категоризация (например, когда правило отправило ассет в определенную категорию) - фиксируется какое правило отправило и какая категория. - Ассет удален из категории. В наборе правил корреляции ПресейлПак есть пример правила корреляции по обнаружению новой уязвимости на Ассете по событию аудита в KUMA. [](https://kb.kuma-community.ru/uploads/images/gallery/2023-10/F23image.png) # Тенанты в KUMA (Multitenancy) ### Термины - **Multitenancy** — "множественное владение", использование общих ресурсов разными пользователями изолировано друг от друга. - **Tenant (тенант)** — огранизация / филиал организации (в рамках KUMA). - **General tenant** — основной тенант (Main), который имеет доступ ко всем данным и настройкам своих филиалов, может осуществлять централизованное управление филиалами.Права на создание нового и редактирование существующего тенанта — только у пользователя с ролью General admin.
Для редактирования ресурсов в определенном тенанте, помимо прав администратора тенанта добавьте еще права аналитика к УЗ
Отключить Main тенант нельзя (можно переименовать), так как некоторые разделы в KUMA доступны только ему, например, Audit события KUMA складваются только в нем.
### Принцип работы KUMA Core (ядро SIEM) — это web консоль и компонент управления всеми микросервисами KUMA. В каждой инсталляции один сервер Core. Все остальные микросервисы можно распределять по инфраструктуре, как удобно, даже без разделения по тенантам. Разделение по тенантам позволяет разграничить доступ пользователей KUMA по событиям (как базовым так и корреляционным), контенту (правила парсинга, корреляции и т.д.). Тенант может назначаться Коллектору или Коррелятору, а Хранилищу можно назначить Тенант (если это архитектурно тербуется), когда оно отдельное со своими дисками и мощностями. Ниже схематично представлен путь событий от коллекторов в разных тенантах (А и В) в единое Хранилище (Тенант Main), где пользователь Тенанта А может видеть только свои события (Тенанта А):  Пользователи подключаются к Core и через него отправляют поисковые запросы в хранилище (или хранилища) своего тенанта. Выбор тенанта производится в соответсвующем разделе:  Core выступает единой точкой администрирования всей инфраструктуры KUMA, при этом в Core передаются не все события, а только результаты поисковых запросов пользователей, поэтому сетевой трафик минимален. Отдельные (филиальные) Коррелятор и/или Хранилище имеют смысл, если не хочется значительно нагружать каналы связи между Головным офисом и Филиалом, либо архитектурные / организационные требования, например, локальное хранение.  ### Кросс-тенантный коррелятор События разных тенантов могут быть собраны коЛЛекторами, но направляться в один коРРелятор, в этом случае корреляционные события и алерты будут помечены тенантом коррелятора. Ниже представлен пример отправки события от коллектора в Тенанте А в коррелятор Тенант В: [](https://kb.kuma-community.ru/uploads/images/gallery/2025-01/deep-dive-page-3-drawio.png)Ресурсы, используемые в корреляторе, должны принадлежать тому же тенанту, что и сам коррелятор (т.е. правила корреляции из Тенанта А могут прилинковаться к коррелятору Тенанта А). Исключение Shared тенант, ресурсы общего тенанта могут быть использованы в любом корреляторе.
# Описание метрик в KUMAОфициальная документация по данному разделу приведена в Онлайн-справке на продукт: [https://support.kaspersky.ru/help/KUMA/3.2/ru-RU/218035.htm](https://support.kaspersky.ru/help/KUMA/3.2/ru-RU/218035.htm)
По умолчанию данные о работе KUMA хранятся 3 месяца. Этот срок можно изменить, см. справку.
В KUMA роль системы мониторинга выполняет **Victoria Metrics**. Информация по всем микросервисам обновляется каждые 5 секунд по HTTP-интерфейсу. А **Grafana** отвечает за отображение метрик, собранных с помощью Victoria Metrics. Для просмотра всех наборов графиков щелкните сюда (на имя подсвеченное зеленым) в разделе KUMA "Метрики": [](https://kb.kuma-community.ru/uploads/images/gallery/2024-01/ub4image.png) ### Общие метрики Следующие метрики извлекаются из всех микросервисов KUMA - Process — Общие метрики процесса - Memory — Утилизация оперативной памяти, оценивается резидентная память (RSS - Resident set size) - DISK BPS — Количество байт в секунду прочитанных/записанных на диск - Network BPS — Количество байт в секунду полученных/отправленных в сеть - Network Packet Loss — Количество утраченных сетевых пакетов в секунду - GC Latency — Время (медиана), затраченное на цикл Garbage Collector'а GO - Goroutines — Текущее количество активных Go-рутин (потоки в Golang) ##### OS (Общие метрки операционной системы) - Load — Load average (средняя нагрузка) на ЦП. Обычно да 1, 5 и 15 минут, если число нагрузки за 15 минут более количества ядер (включая виртуальные) системы, то это не нормально - CPU — Общая утилизация ЦП - Memory — Общая утилизация оперативной памяти (RSS). В норме, когда число не доходит до 100% - Disk — Утилизация дискового пространства ### Метрики Collectors ##### IO (Input-Output) - Processing EPS — Количество обрабатываемых событий в секунду - Output EPS — Количество отправляемых в точку назначения событий в секунду - Output Latency — Время, затраченное на передачу пачки событий точке назначения и на получения ответа от нее - Output Errors — Количество ошибок отправки пачки событий точке назначения в секунду. Ошибки отправки по сети и ошибки записи в дисковый буффер отображаются отдельно - Output Event Loss — Количество потерянных событий в секунду. Потеря может произойти, если их не удалось отправить ни в сеть, ни записать в дисковый буффер - Output Disk Buffer Size — Текущий размер дискового буффера точки назначения. Ноль означает, что ни одна пачка событий не буферизирована, и это хорошо, не копится очередь ##### Normalization - Raw & Normalized event size — Размер (медиана) оригинального лога источника и размер нормализованной формы этого лога (события) - Errors — Количество ошибок нормализации в секунду ##### Filtration - EPS — Количество событий в секунду, отбрасываемых фильтром коллектора ##### Aggregation - EPS — Количество событий, входящих и выходящих из правила агрегации в секунду. Позволяет оценить эффективность правил агрегации - Buckets — Текущее количество бакетов в правиле агрегации ##### Enrichment - Cache RPS — Количество обращений к локальному кешу в секунду - Source RPS — Количество обращений к источнику обогащения в секунду - Source Latency — Время (медиана), затраченное на отправку запроса и получение ответа от источника обогащения - Queue — Размер очереди запросов на обогащение. Позволяет оценить, является ли данное правило обогащения узким местом - Errors — Количество ошибок обращений к источнику обогащения, обозреваемых в секунду ### Метрики Correlator ##### IO (Input-Output) - Processing EPS — Количество обрабатываемых событий в секунду - Output EPS — Количество событий, отправляемых в точку назначения в секунду - Output Latency — Время (медиана), затраченное на передачу пачки событий точке назначения и на получения ответа от нее - Output Errors — Количество ошибок отправки пачки событий точке назначения в секунду. Ошибки отправки в сеть и ошибки записи в дисковый буффер отображаются отдельно - Output Event Loss — Количество потерянных событий в секунду. Потеря может произойти, если их не удалось отправить ни в сеть, ни записать в дисковый буффер - Output Disk Buffer Size — Текущий размер дискового буффера точки назначения. Ноль означает, что ни одна пачка событий не буферизирована, и это хорошо, не копится очередь ##### Correlation - EPS — Количество корреляционных событий, порождаемых правилом корреляции в секунду - Buckets — Текущее количество бакетов внутри правила корреляции (только для правил Standard) - Rate Limiter Hits — Превышение лимита срабатываний правилом корреляции в секунду - Active Lists OPS — Количество обращений к активному листу в секунду, с указанием операции - Active Lists Records — Текущее количество записей в активном листе - Active Lists On-Disk Size — Текущий размер активного листа на диске ##### Enrichment - Cache RPS — Количество обращений к локальному кешу в секунду - Source RPS — Количество обращений к источнику обогащения в секунду - Source Latency — Время (медиана), затраченное на отправку запроса и получение ответа от источника обогащения - Queue — Размер очереди запросов на обогащение. Позволяет оценить, является ли данное правило обогащения узким местом - Errors — Количество ошибок обращений к источнику обогащения, обозреваемых в секунду ##### Response - RPS — Количествово запусков/активаций правил реагирования (response) в секунду. ### Метрики Storage ##### Clickhouse / General - Active Queries — Общее кол-во запросов к кластеру Clickhouse, выполняемых в данный момент. Метрика отображается по каждому инстансу Clickhouse - QPS — Общее количество запросов в секунду - Failed QPS — Общее количество неуспешных запросов в секунду - Allocated memory — Количество памяти (RAM), выделенное процессу Clickhouse ##### Clickhouse / Insert - Insert EPS — Количество событий, вставляемых за одну секунду в инстанс Clickhouse - Insert QPS — Количество запросов на вставку в секунду - Failed Insert QPS — Количество неуспешных запросов на вставку в секунду - Delayed Insert QPS — Количество запросов на вставку (в секунду), которые были отложены нодой Clickhouse по превышению soft лимита активных слияний. - Rejected Insert QPS — Количество запросов на вставку (в секунду), которые были отвергнуты нодой Clickhouse по превышению hard лимита активных слияний. - Active Merges — Количество активных слияний - Distribution queue — Количество файлов, в которые сохранены временно эвенты в кластере Clickhouse. Эвенты предназначены для инсерта в тот или иной шард, но не попали из-за того, что шард был недоступен. Эти события недоступны в поиске ##### Clickhouse / Select - Select QPS — Количество запросов на выборку данных в секунду - Failed Select QPS — Количество неуспешных запросов на выборку данных в секунду ##### Clickhouse / Replication - Active Zookeeper Connections — Количество активных подключений к нодам кластера Zookeeper. В норме должно быть равным количеству нод в кластере Zookeeper - Read-only Replicas — Количество нод-реплик Clickhouse, находящихся в режиме read-only. В норме таких реплик быть не должно (равно нулю) - Active Replication Fetches — Количество активных процессов репликации данных в настоящий момент (скачивание данных с ноды) - Active Replication Sends — Количество активных процессов репликации данных в настоящий момент (отправка данных ноде) - Active Replication Consistency Checks — Количество текущих проверок консистентности данных на репликах ##### Clickhouse / Networking - Active HTTP Connections — Количество активных подключений к HTTP серверу Clickhouse - Active TCP Connections — Количество активных подключений к TCP серверу Clickhouse - Active Interserver Connections — Количество активных служебных подключений между нодами Clickhouse ### Метрики Core ##### IO (Input-Output) - RPS — Количество запросов в секунду - Latency — Время (медиана), затраченное на обработку одного запроса - Errors — Количество ошибок обоработки запросов в секунду ##### Notification Feed - Subscriptions — Количество клиентов, подключенных к Core с помощью SSE для получения сообщений от сервера в реальном времени. Обычно равно количеству клиентов, использующих Web-console - Errors — Количество ошибок отправки оповещений в секунду ##### Schedulers - Active — Текущее количество активных системных повторяющихся задач. Фоновые задачи, запущенные пользователем, не учитываются - Latency — Время (медиана), затраченное на выполнение задачи - Errors — Количество ошибок выполнения задач, обозреваемых в секунду С KUMA версии 3.2: ##### Raft - Lookup RPS — Количество вызовов процедур чтения в секунду. С указанием процедуры - Lookup Latency — Длительность выполнения процедур чтения, с указанием процедуры. (99 percentile) - Propose RPS — Количество вызовов процедур обновления состояния Raft (SQLITE) в секунду. С указанием процедуры - Propose Latency — Длительность выполнения процедур обновления состояния Raft (SQLITE), с указанием процедуры. (99 percentile) ##### API - RPS — Количество запросов в секунду - Latency — Время, затраченное на обработку одного запроса. Медиана - Errors — Количество ошибок обоработки запросов, обозреваемых за 1 секунду С KUMA версии 3.4: #### Tasks - Active tasks — Число выполняемых задач за единицу времени, в шт. - Task Execution latency — Время выполняемых задач, в сек - Errors — Ошибки при выполнении задач, в шт ##### Data Mining - Executing Rules — Суммарное количество Data Mining правил, которые сейчас выполняются - Execution Latency — Продолжительность выполнения Data Mining правил (сколько время занял сам запрос в БД от момента запуска, до передачи в коррелятор) - Queued Rules — Суммарное количество правил в очереди. Очередь появляется тогда, когда запланировано на одно время больше правил, чем разрешено параметром конкурентности (по умолчанию = 1) - Execution Errors — Количество ошибок при выполнении Data Mining правил ## С KUMA версии 3.2 ### Метрики KUMA AgentДля сбора доступ в ядро по порту 8429/tcp
##### IO (Input-Output) - Processing EPS — Количество обрабатываемых событий за 1 секунду - Output EPS — Количество отправляемых в точку назначения событий за 1 секунду - Output Latency — Время, затраченное на передачу пачки событий точке назначения и на получения ответа от нее. Иными словами - продолжительность round-trip. Медиана - Output Event Loss — Количество потерянных событий за 1 секунду. Потеря может произойти, если их не удалось ни отправить в сеть, ни записать в дисковый буффер. Кроме того, если точка назначения ответила кодом, означающим, к примеру, некорректно сформированный запрос - события также будут утеряны - Output Errors — Количество ошибок отправки пачки событий точке назначения, обозревамое за 1 секунду. Ошибки отправки в сеть и ошибки записи в дисковый буффер отображаются отдельно - Output Disk Buffer Size — Текущий размер дискового буффера destination. Ноль означает, что ни одна пачка событий не буферизирована, все в порядке - Write Network BPS — Количество байт отправленных в сеть за 1 секунду ### Метрики EventRouter ##### IO (Input-Output) - Processing EPS — Количество обрабатываемых событий за 1 секунду - Output EPS — Количество отправляемых в точку назначения событий за 1 секунду - Output Latency — Время, затраченное на передачу пачки событий точке назначения и на получения ответа от нее. Иными словами - продолжительность round-trip. Медиана - Output Event Loss — Количество потерянных событий за 1 секунду. Потеря может произойти, если их не удалось ни отправить в сеть, ни записать в дисковый буффер. Кроме того, если точка назначения ответила кодом, означающим, к примеру, некорректно сформированный запрос - события также будут утеряны - Output Errors — Количество ошибок отправки пачки событий точке назначения, обозревамое за 1 секунду. Ошибки отправки в сеть и ошибки записи в дисковый буффер отображаются отдельно - Output Disk Buffer Size — Текущий размер дискового буффера destination. Ноль означает, что ни одна пачка событий не буферизирована, все в порядке - Write Network BPS — Количество байт отправленных в сеть за 1 секунду - Connector Errors — Количество ошибок в логах коннектора # Как узнать связи между ресурсами KUMAДанный способ является workaround, KUMA до 4.0, в будущих релизах будет добавлен штатный механизм отображения зависимостей.
**Шаг 0.** Предварительно создаем копию нужного ресурса. [](https://kb.kuma-community.ru/uploads/images/gallery/2024-02/ijZimage.png) **Шаг 1.** Выбираем ресурс и нажимаем "Удалить"  **Шаг 2.**  **Шаг 3.** Подтверждаем удаление.  **Шаг 4.** В случае, если от ресурса зависят другие ресурсы KUMA, удаление не произойдет и будет выведен список зависимых ресурсов. Если зависимостей не было найдено, то ресурс будет безвозвратно удален (поэтому на шаге 0 был сделан дубликат ресурса).  # Устройство кластера хранилищаБесплатный курс обучения по ClickHouse от Яндекс Практикум - [https://yandex.cloud/ru/training/clickhouse](https://yandex.cloud/ru/training/clickhouse)
**Кластер** - логическая группа машин, обладающих всеми накопленными нормализованными событиями KUMA. Подразумевает наличие одного или нескольких логических шардов. **Shard (шард)** - логическая группа машин, обладающих некоторой частью всех накопленных в кластере нормализованных событий. Подразумевает наличие одной или нескольких реплик. Если обьяснить на пальцах, механика работы кластера с несколькими шардами - это работа дисков в RAID0. Увеличение количества шардов позволяет: - накапливать больше событий за счет увеличения общего количества серверов и дискового пространства; - поглощать больший поток событий за счет распределения нагрузки, связанной со вставкой новых событий; - уменьшить время поиска событий за счет распределения поисковых зон между несколькими машинами.В случае выхода из строя машины с определенным шардом (при отсутствии репликации) данные продолжат накапливаться другими шардами, но в интерефейсе KUMA нельзя будет искать по событиям до тех пор, пока не ввести в строй обратно "упавшую" машину или поиск вернет не консистентные данные
**Replica (реплика)** - машина, являющаяся членом логического шарда и обладающая одной копией данных этого шарда. Если реплик несколько - копий тоже несколько (репликация данных). Если обьяснить на пальцах, механика работы кластера с несколькими репликами - это работа дисков в RAID1. Увеличение количества реплик позволяет: - улучшить отказоустойчиовость; - распределить общую нагрузку, связанную с поиском данных, между несколькими машинами (однако для этой цели лучше увеличить количество шардов). **Keeper** - машина участвующая в репликации и координации (распределенные Data Definition Language (DDL) запросы) данных на уровне всего кластера хранилищ, позволяющее иметь линеаризуемую запись и нелинейное чтение данных. На весь кластер минимально требуется хотя бы 1 реплика с данной ролью. Рекомендуемое и отказоустойчивое количество таких реплик - 3. Число реплик, участвующих в координации репликации, должно быть нечетным. Если Keeper перестанет работать, то реплики переходят в Read only, при этом поиск будет работать, но новые события записываться не будут.При разворачивании распределенного кластера, машины с ролью Keeper должны быть запущены **ДО** запуска / установки машин без роли Keeper
При работе keeper машины испольют [RAFT алгоритм ](https://ru.wikipedia.org/wiki/Raft_(%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC))для определения лидера среди нескольких keeper машин. Лидер выполняет все операции записи и запускает автоматическое восстановление при отказе любого из подключенных серверов. Остальные узлы — подписчики или последователи, реплицируют данные с лидера и используются клиентскими приложениями для чтения. Подробнее можно почитать [тут](https://bigdataschool.ru/wiki/zookeeper). Кластер может оставаться работоспособным при отказе определенного количества нод в зависимости от размера кластера. Например, для кластера из 3 нод (Keeper), алгоритм кворума продолжает работать при отказе не более чем одной ноды.Доп. информация: [https://clickhouse.com/docs/en/architecture/horizontal-scaling#architecture-diagram](https://clickhouse.com/docs/en/architecture/horizontal-scaling#architecture-diagram)
### Описание конфигурации хранилища в инвентаре ansible Пример инвентаря `distributed.inventory.yml`, если используется два хранилища и 3 кипера, то конфигурация storage будет выглядеть следующим образом: [](https://kb.kuma-community.ru/uploads/images/gallery/2024-04/vBlimage.png)В точке назначения в KUMA (для записи событий в хранилище) прописываются URL всех хранилищ, отдельно установленные машины с ролью keeper указывать НЕ нужно
Буфер хранилища по умолчанию 128 Мб, при большом количестве шардов и заметной медленной работе поиска - увеличьте размер буфера, например, до 512 Мб и увеличте таймаут (интервал очистки буфера), например, до 60 сек.
Редкие большие вставки для БД ClickHouse лучше, чем частые и небольшие.
Установка службы хранилища - [https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-sluzby-xranilishha-esli-etogo-ne-proizoslo-pri-ustanovke](https://kb.kuma-community.ru/books/ustanovka-i-obnovlenie/page/ustanovka-sluzby-xranilishha-esli-etogo-ne-proizoslo-pri-ustanovke)
Смотри также статью про схему взаимодействия KUMA - [https://kb.kuma-community.ru/books/kuma-how-to/page/sxema-setevogo-vzaimodeistviia-kuma](https://kb.kuma-community.ru/books/kuma-how-to/page/sxema-setevogo-vzaimodeistviia-kuma)
Корректность работы хранилища можно проверить, перейдя во вкладку События и нажав на значок увеличительного стекла (Поиск), далее должны появиться события, поступающие в KUMA или Сообщение «События не найдены». Если при поиске возникает ошибка, то необходимо проверить статусы сервисов в веб интерфейсе KUMA. Провести первичный траблшутинг по [этой ](https://kb.kuma-community.ru/books/kuma-how-to/page/pervicnyi-trablsut-v-kuma-troubleshoot)статье, воспользоваться комьюнити ресурсами или завести кейс в поддержку
# Как расширить диск с данными KUMA в случае с lvm ### Кейс 1. Увеличивается объем дискаВ данном примере расширяется размер диска **sda** и раздел **sda3**
1. Расширяем диск средствами гипервизора 2. Проверяем текущее состояние дисков ```bash lsblk ```  3. Проверяем свободное место ```bash parted /dev/sda unit MB print free ```  4. Изменяем целевой раздел (под номером 3) ```bash parted /dev/sda resizepart 3 ```  5. (опционально) Проверяем свободное место, чтобы убедиться, что изменения применились ```bash parted /dev/sda unit MB print free ```  6. (опционально) Проверяем размер физического тома ```bash pvdisplay ```  7. Расширяем физический том ```bash pvresize /dev/sda3 ```  8. (опционально) Проверяем логический раздел ```bash lvscan ```  9. Расширяем логический раздел ```bash lvextend /dev/ubuntu-vg/ubuntu-lv -l +100%FREE -r ```  10. (опционально) Проверяем, что все изменения применены ```bash lsblk ```  --- ### Кейс 2. Добавляется новый дискВ данном примере добавляется новый диск **sdb**
1. Подключаем новый диск средствами гипервизора или к железному серверу 2. Проверяем текущее состояние дисков ```bash lsblk ```  3. Создаем физический том ```bash pvcreate /dev/sdb ```  4. (опционально) Проверяем том (должны увидеть старый и новый) ```bash pvdisplay ```  5. Расширяем группу томов новым томом ```bash vgextend ubuntu-vg /dev/sdb ```  6. (опционально) Проверяем, что группа томов увеличилась в размере ```bash vgdisplay ```  7. Расширяем логический раздел ```bash lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv ```  8. (опционально) Проверяем, что раздел был успешно расширен ```bash lvdisplay ```  9. Увеличиваем раздел файловой системы (**ext4**) ``` resize2fs /dev/ubuntu-vg/ubuntu-lv ```  Если файловая система **xfs** используйте следующую команду ```bash xfs_growfs /dev/ubuntu-vg/ubuntu-lv ``` 10. (опционально) Проверяем, что все изменения применены ```bash df -h ```  --- # Продление сессии пользователя для режима ТВ (TV-mode)Не актуально для версий KUMA >3.2
В рамках данной статьи настраивается автоматическое продление сессии пользователя для ТВ режима, чтобы отображать дашборды на экранах без перелогина.По умолчанию в KUMA сессия длится 12 часов и этот параметр не изменяется
1\. Создайте пользователя с ролью Младший аналитик (минимальные привилегии для просмотра дашбордов) с доступом в нужные тенанты:  2\. Сделайте выход пользователя из KUMA. Перейдите на страницу входа в KUMA, нажмите в браузере F12 (или перейдите в режим разработчика), затем зайдите новым пользователем:  3\. Перейдите в окне режима разработчика в браузере во вкладку Application, затем раздел Cookies и скопируйте значения переменных XSRF-TOKEN и kuma\_m\_sid:  4\. Заполните запрос curl своими данными из переменных: ```bash curl -s -k --location 'https://10.68.85.126:7220/api/reset-session-ttl' --header 'Cookie: XSRF-TOKEN=acdb1014-a95e-40c0-afdd-5080133a6463; kuma_session=n6xXfEgIxiC3Bo896X0Ece0sGmovt72RFksI9_PJ09g%3D' --compressed ``` 5\. Создайте задачу в crontab на ядре KUMA с повторением каждые 4 часа, выполните команду `crontab -e` и добавьте запись в конце, зайтем выйдите с сохранением: ```bash 0 */4 * * * /usr/bin/curl -s -k --location 'https://10.68.85.126:7220/api/reset-session-ttl' --header 'Cookie: XSRF-TOKEN=39dd617f-d016-4d12-b6b1-d9ec4cf30a24; kuma_session=RX8WiZVn0H-xxLR_7wEdU4XCARcNUHWaDwS9CQDBQYA%3D' --compressed ``` # Как определить средний размер события ### В веб-интерфейсе Для того, чтобы определить средний размер хранимого события из веб-интерфейса, выполните следующие действия: 1\. Войдите в веб-интерфейс с учетной записью администратора 2\. Перейдите в **Ресурсы** - **Активные сервисы** 3\. Выберите ваше хранилище правой кнопкой мыши и нажмите **Смотреть разделы**  4\. В результате откроектся таблица с разделами (партициями). Вы можете найти необходимые партиции через поиск или отфильтровать по доступным полям, например по полю **Пространство**.  В колонке Размер представлен размер хранимых событий в разделе с учетом реплик в Байтах (до версии 4.0, в 4.0 возможно выбрать единицы отображения). В колонке События представлено количество событий в разделе. Для того, чтобы посчитать средний размер хранимого события необходимо воспользоваться формулой: ##### **(Размер ÷ События) ÷ Количество реплик** Для более точного результата рекомендуется проделать вычисления для нескольких разделов одного типа за разные даты и затем вычислить среднее арифметическое. # Cканер уязвимостей ADPulse DC **ADPulse** — это инструмент аудита безопасности Active Directory с открытым исходным кодом, который подключается к контроллеру домена через LDAP(S), выполняет 35 автоматических проверок безопасности и создает подробные отчеты в консольном формате, формате JSON и HTML. Он предназначен для ИТ-администраторов, специалистов по тестированию на проникновение и групп безопасности, которым необходима быстрая оценка неправильных настроек Active Directory и поверхности атаки в режиме только для чтения.ADPulse работает в режиме только для чтения и не вносит изменений в инфраструктуру — но это не делает его использование безобидным с правовой точки зрения.
**Используйте инструмент только если:** - Вы администратор или сотрудник ИБ своей организации - У вас есть письменное разрешение на проведение аудита (scope of work, договор, приказ) - Вы проводите работы в рамках официального пентеста с согласованным техническим заданием **Проверки безопасности**| \# | Проверять | Описание |
|---|---|---|
| 1 | **Политика паролей** | Минимальная длина, история, сложность, порог блокировки, обратимое шифрование, детализированные PSO. |
| 2 | **Привилегированные учетные записи** | Членство в группах администраторов домена, администраторов предприятия, администраторов схем и других группах с конфиденциальной информацией; устаревшие данные участников, пароли, срок действия которых не истекает, пароли в описаниях, встроенный статус администратора, возраст krbtgt. |
| 3 | **Kerberos** | Учетные записи, допускающие завышение рейтинга Kerberos (SPN в объектах пользователей), учетные записи, допускающие завышение рейтинга AS-REP, шифрование только DES, высокоприоритетные цели, объединяющие adminCount=1 + SPN + PasswordNeverExpires |
| 4 | **Неограниченное делегирование** | Компьютеры и учетные записи пользователей, не относящиеся к центру обработки данных, используются для неограниченного делегирования полномочий Kerberos. |
| 5 | **Ограниченное делегирование** | Учетные записи с переходом протокола (S4U2Self) и стандартными целями с ограниченным делегированием. |
| 6 | **ADCS / PKI** | ESC1, ESC2, ESC3, ESC6, ESC8, ESC9, ESC10, ESC11, ESC13, ESC15, слабые размеры ключей, перечисление ACL участников |
| 7 | **Доверительное использование доменов** | Двустороннее доверие без фильтрации SID, доверие между лесами, внешнее доверие. |
| 8 | **Гигиена аккаунта** | Устаревшие пользователи/компьютеры, учетные записи, в которые никогда не входили, флаг PASSWD\_NOTREQD, обратимое шифрование для каждой учетной записи, старые пароли, повторяющиеся SPN. |
| 9 | **Безопасность протокола** | Подписание LDAP/привязка каналов, версии операционных систем контроллеров домена, функциональный уровень домена/леса, рекомендации по NTLMv1/WDigest. |
| 10 | **Объекты групповой политики** | Отключенные, осиротевшие, несвязанные и пустые групповые политики; чрезмерное количество групповых политик. |
| 11 | **LAPS** | Обнаружение устаревших схем LAPS и схем Windows LAPS; компьютеры без паролей LAPS. |
| 12 | **LAPS coverage** | Процентное покрытие всех компьютеров, не являющихся центрами обработки данных, с паролем, управляемым LAPS. |
| 13 | **DNS и инфраструктура** | Использование подстановочных DNS-записей, рекомендации по отравлению LLMNR/NetBIOS-NS. |
| 14 | **Контроллеры домена** | Обнаружение отдельного контроллера домена, устаревшие ОС на контроллерах домена, роли FSMO, политика репликации паролей RODC. |
| 15 | **ACL / Права доступа** | Права доступа ESC4, ESC5, ESC7, DCSync для непривилегированных субъектов, группа защищенных пользователей, списки контроля доступа (ACL) для делегирования. |
| 16 | **Дополнительные функции** | Корзина Active Directory, управление привилегированным доступом (PAM) |
| 17 | **Replication Health** | Количество сайтов, интервалы репликации связей между сайтами, объекты nTDSDSA |
| 18 | **Служебные аккаунты** | Внедрение gMSA, обычные учетные записи пользователей, учетные записи пользователей с adminCount=1 |
| 19 | **Miscellaneous Hardening** | Квота для учетных записей машин, время жизни удаленных файлов, членство в группах администраторов схемы/корпоративных администраторов, гостевая учетная запись, рекомендации по политике аудита. |
| 20 | **Устаревшие операционные системы** | Включены учетные записи компьютеров, сообщающие об окончании поддержки версий Windows. |
| 21 | **Устаревшие протоколы** | Обнаружение SMBv1, обеспечение подписи SMB, принятие нулевых сессий (проверка сети в реальном времени) |
| 22 | **Exchange** | Группа разрешений Windows Exchange (PrivExchange / CVE-2019-0686), доверенная подсистема Exchange |
| 23 | **Защищенные администраторы** | adminCount=1 inventory — orphaned, ghost (disabled) and stale accounts |
| 24 | **Пароли в описаниях** | Обнаружение учетных данных, хранящихся в поле «Описание» пользователей, администраторов и компьютеров, на основе ключевых слов. |
| 25 | **GPP / cpassword (MS14-025)** | Программа выполняет обход файлов XML с атрибутами групповых политик в каталоге SYSVOL ``` cpassword ``` и расшифровывает их с помощью общеизвестного ключа AES от Microsoft. |
| 26 | **AdminSDHolder ACL** | Считывает двоичный список ``` CN=AdminSDHolder ``` контроля доступа (DACL) и помечает непривилегированные учетные записи с правами на запись — эти записи автоматически распространяются на все защищенные учетные записи каждые 60 минут через SDProp. |
| 27 | **История SID** | Обнаруживает учетные записи с ``` sIDHistory ``` заполненными данными; повышает статус до CRITICAL, если какой-либо внедренный SID соответствует привилегированной группе (администраторы домена, администраторы предприятия и т. д.). |
| 28 | **Shadow Credentials** | Функция помечает неожиданные ``` msDS-KeyCredentialLink ``` записи в объектах пользователей и компьютеров, позволяя использовать аутентификацию на основе сертификатов без знания пароля учетной записи. |
| 29 | **RC4 / Устаревшее шифрование Kerberos** | Проверяет ``` msDS-SupportedEncryptionTypes ``` учетные записи служб, контроллеров домена и администраторов, чтобы выявить те, которые по-прежнему разрешают использование RC4-HMAC — уязвимого типа шифрования, специально запрашиваемого злоумышленниками для взлома в автономном режиме. |
| 30 | **Foreign Security Principals in Privileged Groups** | Выявляет ``` CN=ForeignSecurityPrincipals ``` и помечает любые FSP из доверенного домена, являющиеся членами конфиденциальной локальной группы (администраторы домена, операторы резервного копирования и т. д.). |
| 31 | **Доступ, совместимый с версиями до Windows 2000.** | Проверяет, являются ли ``` Everyone ``` или ``` Anonymous Logon ``` являются членами этой группы, что позволяет осуществлять неаутентифицированное перечисление SAMR/LSARPC из любой точки сети. |
| 32 | **Dangerous Constrained Delegation Targets** | Проводит перекрестную проверку целевых объектов делегирования на основе имен хостов контроллеров домена и помечает учетные записи, делегирующие делегирование приоритетным классам обслуживания ( ``` ldap/ ``` , ``` cifs/ ``` , ``` host/ ``` , ``` gc/ ``` , ``` krbtgt/ ``` ) на контроллерах домена. |
| 33 | **Orphaned AD Subnets** | Обнаруживает подсети без ``` siteObject ``` назначений, в результате чего клиенты получают случайный контроллер домена и потенциально маршрутизируют трафик аутентификации через каналы WAN. |
| 34 | **Legacy FRS SYSVOL Replication** | Определяет, продолжает ли SYSVOL реплицироваться с помощью устаревшей службы репликации файлов (File Replication Service) вместо DFSR, и помечает состояния, остановившиеся в процессе миграции. |
| 35 | **RBCD on Domain Object / DCs** | Проверяет ``` msDS-AllowedToActOnBehalfOfOtherIdentity ``` состояние головного узла домена NC и всех объектов компьютеров контроллера домена — любая из конфигураций предоставляет фактические права администратора домена разрешенным субъектам через S4U2Proxy. |
| Аргумент | Необходимый | По умолчанию | Описание |
|---|---|---|---|
| `--domain` | Да | — | Целевой домен AD (например `corp.local`) |
| `--user` | Да | — | Имя пользователя домена |
| `--password` | Да | — | пароль домена |
| `--hash` | Только без пароля | — | Хэш домена NTLM |
| `--dc-ip` | Нет | Автоматически решено | IP-адрес контроллера домена |
| `--report` | Нет | `all` | Формат отчета: `console`, `json`, `html`, или`all` |
| `--output-dir` | Нет | `.` | Родительский каталог для `Reports/`папки |
| `--no-color` | Нет | `false` | Отключить цвет в выводе на консоль |
| Счет | Уровень риска | Значение |
|---|---|---|
| 80–100 | НИЗКИЙ | Хорошая система безопасности, лишь незначительные проблемы. |
| 60–79 | СЕРЕДИНА | Существенные недостатки, которые следует устранить. |
| 40–59 | ВЫСОКИЙ | Присутствуют существенные уязвимости. |
| 0–39 | КРИТИЧЕСКИЙ | Серьезные риски — требуется немедленное устранение последствий. |
Информация преведенная в данной статье расчитана исключительно на опытных пользователей KUMA и **не** является официально поддерживаемым сценарием.
Данная инструкция актуальна для версий KUMA **до** появления отдельного сервиса **metrics**.
### Описание С помощью встроенного в продукт модуля vmalerts есть возможность отправки уведомлений по достижении метриками, определенных пользователем, пороговых значений. Уведомления отправляются пользователю, как стандартные уведомления мониторинга. Используются настройки SMTP-сервера в KUMA ([https://support.kaspersky.com/KUMA/2.1/ru-RU/217936.htm)](https://support.kaspersky.com/KUMA/2.1/ru-RU/217936.htm)), а у пользователя должна быть включена возможность получения уведомлений KUMA. ### Настройка Core вне кластера k0s Настройка vmalerts осуществляется с помощью правил, которые должны быть помещены в директорию ``` /opt/kasperksy/kuma/victoria-metrics/cfg/rules/ ``` ### Настройка Core в кластере k0s В случае размещения Core в кластере k0s правило может быть помещено в контейнер одним из следующих способов: 1\. На любом контроллере, используя k0s: ```bash export POD=$(k0s kubectl get pods --namespace kuma -l "app=core" -o jsonpath="{.items[0].metadata.name}") k0s kubectl cp --no-preserve rule.yml kuma/$POD:/opt/kaspersky/kuma/victoria-metrics/cfg/rules/ -c core ``` Где `rule.yml` - заранее созданное правило для vmalert 2\. С контрольной машины, если каталог с инсталлятором, в котором сохранен сертификат для kubectl, доступен. Используя kubectl: ```bash export KUBECONFIG=/