14 февраля 2024
KUMA
Статья 3: Парсинг логов. Подключение логов CheckPoint
Цикл "Kaspersky Symphony XDR"
Вводная статья
Блок KUMA
Блок KATA
Блок KEDR
Блок KUMA
- KUMA. Введение: обзор архитектуры
- Установка системы. Подключение активов
- Парсинг логов. Подключение логов CheckPoint, KSC, KSMG, Microsoft AD
- Написание своего парсера и нормализации
- Обогащение логов в коллекторе
- Работа с простыми алертами и инцидентами. Создание простых корреляционных правил
- Работа с тяжелыми алертами. Создание тяжелых корреляционных правил
- Оповещения в телеграмм
- Построение дашбордов
- Symphony XDR, автоматическое реагирование через агенты
Блок KATA
- Защита периметра. Теория
- Защита периметра. Развертывание системы
- Защита периметра. Развертывание центрального узла
- Защита периметра. Настройка платформы
- Защита периметра. Подключение источника
- Защита периметра. Тестирование
Блок KEDR
Введение
Приветствуем вас в новой статье цикла «Kaspersky Symphony XDR»!
В этом материале мы непосредственно переходим к работе с событиями. И прежде всего нужно понять, какие события будут интересны нам для анализа информации и формирования инцидентов. Необходимо составить список источников, откуда мы будем собирать события. В этом моменте будет работать принцип необходимости и достаточности.
Необязательно заводить все логи на свете, если они не нужны для вашего анализа (это сильно уменьшает место на диске и подъедает вашу лицензию). Если весь точный список пока непонятен, можно начать с основного. Как правило, типовые источники событий в среднем одинаковы у всех.
Типовые источники для подключения:
· NGFW (CheckРoint, fortinet, АПКШ Континент);
· Логи с AD серверов;
· Windows логи со всех машинок внутри организации;
· Linux сервера (логи аудита, sudo);
· Антивирусные решения (KSC);
· Nginx;
· Почтовые события (KSMG, Exchange);
· Сканеры (PT VM, Redcheck);
· DLP решения (SearchIform, InfoWatch);
· Сетевые устройства.
В рамках нашего курса, разумеется, заводить все вышеперечисленные источники мы не будем, но некоторым наиболее интересным и важным посвятим внимание.
Давайте для начала вспомним информацию из предыдущих статей.
Ниже представлена архитектура решения:
В этом материале мы непосредственно переходим к работе с событиями. И прежде всего нужно понять, какие события будут интересны нам для анализа информации и формирования инцидентов. Необходимо составить список источников, откуда мы будем собирать события. В этом моменте будет работать принцип необходимости и достаточности.
Необязательно заводить все логи на свете, если они не нужны для вашего анализа (это сильно уменьшает место на диске и подъедает вашу лицензию). Если весь точный список пока непонятен, можно начать с основного. Как правило, типовые источники событий в среднем одинаковы у всех.
Типовые источники для подключения:
· NGFW (CheckРoint, fortinet, АПКШ Континент);
· Логи с AD серверов;
· Windows логи со всех машинок внутри организации;
· Linux сервера (логи аудита, sudo);
· Антивирусные решения (KSC);
· Nginx;
· Почтовые события (KSMG, Exchange);
· Сканеры (PT VM, Redcheck);
· DLP решения (SearchIform, InfoWatch);
· Сетевые устройства.
В рамках нашего курса, разумеется, заводить все вышеперечисленные источники мы не будем, но некоторым наиболее интересным и важным посвятим внимание.
Давайте для начала вспомним информацию из предыдущих статей.
Ниже представлена архитектура решения:
События от информационных систем попадают на коллектор, который разбирает (парсит) и нормализует события. После этого нормализованное событие отправляется в коррелятор и в хранилище данных. В хранилище оно будет просто находиться. А коррелятор проверяет события и создает алерты, если логи удовлетворяют определенным паттернам. В результате мы получаем потенциальный инцидент ИБ.
Все реализовано через микросервисную архитектуру: значит под каждый источник данных есть свой микросервис, который будет отвечать за парсинг и нормализацию логов. Ниже мы более подробно рассмотрим процесс настройки сбора и парсинга событий от некоторых источников.
Первыми изучим события от СheckРoint.
Все реализовано через микросервисную архитектуру: значит под каждый источник данных есть свой микросервис, который будет отвечать за парсинг и нормализацию логов. Ниже мы более подробно рассмотрим процесс настройки сбора и парсинга событий от некоторых источников.
Первыми изучим события от СheckРoint.
CheckРoint
События с межсетевого экрана checkpoint отравляются с сервера управления. Для этого используется утилита cp_log_export.
Её синтаксис представлен далее:
cp_log_export add name <Name> [domain-server {mds | all}] target-server <HostName or IP address of Target Server> target-port <Port on Target Server> protocol {udp | tcp} format {syslog | splunk | cef | leef | generic | json | logrhythm | rsa} [<Optional Arguments>]
В зависимости от того, куда отправляем события, все параметры указываются в команде.
Для того чтобы отправить логи в KUMA используем такую команду:
cp_log_export add name to_Kuma target-server 10.10.30.195 target-port 5514 protocol udp format syslog
Здесь мы отправляем логи на определенный порт и IP адрес. Очень важным является тип протокола (когда летит много событий, tcp очень сильно может нагружать как сами устройства, так и канал, по которому эти логи будут проходить). Поэтому советуем использовать режим udp для источников с большим количеством событий.
Её синтаксис представлен далее:
cp_log_export add name <Name> [domain-server {mds | all}] target-server <HostName or IP address of Target Server> target-port <Port on Target Server> protocol {udp | tcp} format {syslog | splunk | cef | leef | generic | json | logrhythm | rsa} [<Optional Arguments>]
В зависимости от того, куда отправляем события, все параметры указываются в команде.
Для того чтобы отправить логи в KUMA используем такую команду:
cp_log_export add name to_Kuma target-server 10.10.30.195 target-port 5514 protocol udp format syslog
Здесь мы отправляем логи на определенный порт и IP адрес. Очень важным является тип протокола (когда летит много событий, tcp очень сильно может нагружать как сами устройства, так и канал, по которому эти логи будут проходить). Поэтому советуем использовать режим udp для источников с большим количеством событий.
На приемнике проверим, что логи доходят через tcpdump. Если логов не будет, то высока вероятность что межсетевой экран где-то внутри режет траффик, а значит нужно прописать дополнительное файервольное правило.
В нашем случае траффик идет, отлично! Заранее мы дополнительно откроем порт через firewall-cmd, на который летят события.
firewall-cmd --permanent --add-port=5514/udp
firewall-cmd --reload
Теперь настраиваем приемник данных на стороне KUMA.
Для этого пройдём в пункт меню Resources. Здесь представлены все настройки в системе. Сейчас же нас интересует Collectors.
firewall-cmd --permanent --add-port=5514/udp
firewall-cmd --reload
Теперь настраиваем приемник данных на стороне KUMA.
Для этого пройдём в пункт меню Resources. Здесь представлены все настройки в системе. Сейчас же нас интересует Collectors.
Выбираем в меню add collector:
Создаем новый микросервис, называем его CheckPoint. Остальные пункты оставляем в дефолте. Можно включить режим Debug, в этом случае на коллекторе будет записываться лог файл со всеми ошибками.
Далее настраиваем то, по какому порту будем принимать соединение и по какому протоколу. Здесь выставляем Udp и указываем порт :5514, последнее значит что мы будем слушать на всех сетевых интерфейсах порт 5514.
И в самом конце указываем разграничитель для событий, чаще всего это знак новой строки:
И в самом конце указываем разграничитель для событий, чаще всего это знак новой строки:
В Advanced settings можно настроить параметры шифрования, если мы хотим отправлять логи во шифрованному каналу. Далее переходим к настройке парсинга информации.
Добавляем парсер из списка существующих:
Выбираем парсер уже существующий в системе: «Checkpoint Syslog Basic».
Цельный парсер выглядит таким образом:
Здесь у нас есть вход. Как правило в самом начале разбираются заголовки пакетов, затем лог переходит в следующий бокс, где мы непосредственно парсим событие и нормализуем его под конкретные поля. Детально разберём один бокс.
Вначале мы настраиваем то, при каком условии событие попадет в этот бокс. И если оно удовлетворяет требованиям — указываем какое поле мы берем из полей, сформированных на предыдущем шаге.
В данном случае мы разбираем, то что у нас лежит в поле msg:
Вначале мы настраиваем то, при каком условии событие попадет в этот бокс. И если оно удовлетворяет требованиям — указываем какое поле мы берем из полей, сформированных на предыдущем шаге.
В данном случае мы разбираем, то что у нас лежит в поле msg:
После этого переходим к парсеру.
В методе парсера (1) выбираем функцию по которой мы будем разбирать трафик.
Здесь можно выбрать методы:
По опыту можем сказать, что больше всего дел вам придется иметь с методами kv и regexp. Regexp рассмотрим позже, в нашем случае подходит kv, рассмотрим дополнительные параметры для него:
Это очень сильный инструмент, используемый для парсинга событий: с его помощью вы буквально «на лету» сможете найти проблему и ее исправить без особых трудностей.
В пункте 6 указаны оригинальное поля из исходного сообщения: его мы сопоставляем с полем из пункта 7. Здесь происходит нормализация. Она обязательна.
В KUMA все поля должны быть нормализованы и вы выбираете, какое нормализованное поле наиболее близко подходит к оригинальному значению. Если такого поля нет — можно сохранить в дополнительные поля «DeviceCustomNumber*», и в Label указать его оригинальное поле.
В результате в *String/*Number будет указано значение поля, а в Label его оригинальное название. И в пункте 9 будет пример значения поля из тестового события, взятый из example.
Если все хорошо, то здесь появятся значения, если же будут ошибки, то поля в этом пункте не будут указаны.
Здесь можно выбрать методы:
- json
- cef
- regexp
- syslog
- csv
- kv
- xml
- netflow5
- netflow9
- ipfix
- sql
По опыту можем сказать, что больше всего дел вам придется иметь с методами kv и regexp. Regexp рассмотрим позже, в нашем случае подходит kv, рассмотрим дополнительные параметры для него:
- В pair delimiter (2) указывается как разбивать отдельные пары значений, в данном случае у нас стоит «;» но также популярен пробел;
- В value delimiter (3) уже разделяются поля и значения;
- В example (5) можно добавить пример лога, и если ваш парсер правильный табличка ниже заполнится предварительными значениями
Это очень сильный инструмент, используемый для парсинга событий: с его помощью вы буквально «на лету» сможете найти проблему и ее исправить без особых трудностей.
В пункте 6 указаны оригинальное поля из исходного сообщения: его мы сопоставляем с полем из пункта 7. Здесь происходит нормализация. Она обязательна.
В KUMA все поля должны быть нормализованы и вы выбираете, какое нормализованное поле наиболее близко подходит к оригинальному значению. Если такого поля нет — можно сохранить в дополнительные поля «DeviceCustomNumber*», и в Label указать его оригинальное поле.
В результате в *String/*Number будет указано значение поля, а в Label его оригинальное название. И в пункте 9 будет пример значения поля из тестового события, взятый из example.
Если все хорошо, то здесь появятся значения, если же будут ошибки, то поля в этом пункте не будут указаны.
Есть и дополнительная настройка Enrichment: сюда мы добавляем константные значения. Например, здесь всегда будут разбираться логи CheckРoin, а значит добавим константу поле DeviceVendor, которое всегда будет со значением CheckРoint.
Мы ещё несколько раз столкнемся с этими настройками.
Сейчас же перейдем в следующие пункты.
Мы ещё несколько раз столкнемся с этими настройками.
Сейчас же перейдем в следующие пункты.
В фильтеринге мы можем отбросить какие-то события, которые нам не интересны для хранения и анализа. Это сэкономит как место на диске, так и вашу лицензию.
Идем в следующий пункт.
Идем в следующий пункт.
Здесь можно объединить несколько событий в одном. Это редко используемая настройка, в основном она нужна для экономии пространства и лицензии.
В Enrichment мы можем обогатить события из других источников.
Например, обогащение с DNS добавит пункт адреса или имени. Geoip добавит метку гео-данных на основе внешнего адреса. LDAP дополнит информацию о пользователе.
Этот пункт мы будем рассматривать в отдельной статье как довольно важную и удобную настройку.
Например, обогащение с DNS добавит пункт адреса или имени. Geoip добавит метку гео-данных на основе внешнего адреса. LDAP дополнит информацию о пользователе.
Этот пункт мы будем рассматривать в отдельной статье как довольно важную и удобную настройку.
В роутинге указываем место, куда сохраняем события и отправляем нормализованные события в коррелятор, который будет находить инциденты в трафике.
И теперь нас ждет финальный этап: настройки для создания сервиса!
И теперь нас ждет финальный этап: настройки для создания сервиса!
Команду мы выполняем и поднимаем сервис на том сервере, на который прилетают логи. Сервис будет постоянно обращаться на ядро и брать настройки из базы данных mongodb.
Проверяем в ресурсах то, что сервис создался и работает в меню Resources.
Перфект! Идем смотреть логи в пункт меню Events.
Логи летят, но совершенно не разбираются, а значит есть проблемы в парсинге.
Берем оригинальное событие отсюда и идем проверять парсер.
Событие:
<134>1 2023-11-10T12:20:39Z ts-spb-cpmgmt CheckPoint 29930 - [action:"Accept"; flags:"417028"; ifdir:"inbound"; ifname:"LAN2"; logid:"0"; loguid:"{0x43bbe628,0xf4aa3c4d,0x95451c56,0x64240fa4}"; origin:"91.224.182.20"; originsicname:"CN=tss-moscow-gw,O=ts-spb-cpmgmt.tssolution.local.ai4paf"; sequencenum:"6"; time:"1699618839"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={7A6D3D54-2DD2-644B-BED6-E09B908ED1A9};mgmt=ts-spb-cpmgmt;date=1699539248;policy_name=TS-Moscow\]"; dst:"8.8.8.8"; inzone:"Internal"; layer_name:"TS-Moscow Network"; layer_uuid:"bf74c75d-192f-463a-8e7d-be40dcf3c917"; match_id:"12"; parent_rule:"0"; rule_action:"Accept"; rule_name:"Acces for class, GUEST Wi-FI, servers"; rule_uid:"8afbc9b8-38cc-48a3-a805-57b0d702d9d0"; nat_addtnl_rulenum:"0"; nat_rulenum:"67"; outzone:"External"; product:"VPN-1 & FireWall-1"; proto:"17"; s_port:"39300"; service:"53"; service_id:"domain-udp"; src:"10.77.128.10"; xlatedport:"0"; xlatedst:"0.0.0.0"; xlatesport:"51809"; xlatesrc:"91.224.182.20"]
Событие ставим в первый бокс парсера и смотрим что оно выдаст.
Берем оригинальное событие отсюда и идем проверять парсер.
Событие:
<134>1 2023-11-10T12:20:39Z ts-spb-cpmgmt CheckPoint 29930 - [action:"Accept"; flags:"417028"; ifdir:"inbound"; ifname:"LAN2"; logid:"0"; loguid:"{0x43bbe628,0xf4aa3c4d,0x95451c56,0x64240fa4}"; origin:"91.224.182.20"; originsicname:"CN=tss-moscow-gw,O=ts-spb-cpmgmt.tssolution.local.ai4paf"; sequencenum:"6"; time:"1699618839"; version:"5"; __policy_id_tag:"product=VPN-1 & FireWall-1[db_tag={7A6D3D54-2DD2-644B-BED6-E09B908ED1A9};mgmt=ts-spb-cpmgmt;date=1699539248;policy_name=TS-Moscow\]"; dst:"8.8.8.8"; inzone:"Internal"; layer_name:"TS-Moscow Network"; layer_uuid:"bf74c75d-192f-463a-8e7d-be40dcf3c917"; match_id:"12"; parent_rule:"0"; rule_action:"Accept"; rule_name:"Acces for class, GUEST Wi-FI, servers"; rule_uid:"8afbc9b8-38cc-48a3-a805-57b0d702d9d0"; nat_addtnl_rulenum:"0"; nat_rulenum:"67"; outzone:"External"; product:"VPN-1 & FireWall-1"; proto:"17"; s_port:"39300"; service:"53"; service_id:"domain-udp"; src:"10.77.128.10"; xlatedport:"0"; xlatedst:"0.0.0.0"; xlatesport:"51809"; xlatesrc:"91.224.182.20"]
Событие ставим в первый бокс парсера и смотрим что оно выдаст.
Ошибка, есть проблема! Путем различных проверок обнаруживаем, что правильному парсеру мешают квадратные скобки (отмечены в примере выше красным цветом).
Ниже представлен пример: что будет, если убрать скобочки в теле сообщения. Видим что все разбирается и работает.
Ниже представлен пример: что будет, если убрать скобочки в теле сообщения. Видим что все разбирается и работает.
Что с этим можно сделать?
Есть 2 варианта: либо мы меняем парсер на regex и там отсеиваем эти скобки, либо меняем в источнике настройки отправления, чтобы убрать эти скобки.
Второй вариант проще - давайте попробуем это сделать.
Находим в документации формат syslog сообщений по ссылке:
https://support.checkpoint.com/results/sk/sk122323
$EXPORTERDIR/targets/<Name of Log Exporter Configuration>/conf/*FormatDefinition.xml
Находим этот конфиг:
Есть 2 варианта: либо мы меняем парсер на regex и там отсеиваем эти скобки, либо меняем в источнике настройки отправления, чтобы убрать эти скобки.
Второй вариант проще - давайте попробуем это сделать.
Находим в документации формат syslog сообщений по ссылке:
https://support.checkpoint.com/results/sk/sk122323
$EXPORTERDIR/targets/<Name of Log Exporter Configuration>/conf/*FormatDefinition.xml
Находим этот конфиг:
И убираем в нем квадратные скобочки в <start_message_body></start_message_body> и в<end_message_body></end_message_body> , сохраняем файл и рестартуем сервис отправки логов.
Успех!
Успех!
Здесь обращаем внимание, что запрос к логам идет через SQL запрос в базу данных. Причем при запросе можно использовать различные функции Clickhouse.
Все логи разбираются. Итак: мы успешно рассмотрели пример для CheckPoint!
И с одной стороны в вышеописанном нет ничего сложного, но для того, чтобы быстро понять и сообразить в чем проблема и как её нужно решить требуется определенный опыт работы.
В следующей статье мы рассмотрим заведение логов с AD. Оставайтесь с нами!
Автор статьи: Глеб Ряскин, Инженер отдела интеграций TS Solution
Все логи разбираются. Итак: мы успешно рассмотрели пример для CheckPoint!
И с одной стороны в вышеописанном нет ничего сложного, но для того, чтобы быстро понять и сообразить в чем проблема и как её нужно решить требуется определенный опыт работы.
В следующей статье мы рассмотрим заведение логов с AD. Оставайтесь с нами!
Автор статьи: Глеб Ряскин, Инженер отдела интеграций TS Solution