Перейти к содержанию

Руководство по настройке лог-коллектора. Активные источники событий

Радар лог-коллектор. Описание.

Радар лог-коллектор (RADAR LOG-COLLECTOR), далее лог-коллектор, предназначен для организации активного сбора событий от активов, не имеющих возможности отправки данных в сторонние системы. Лог-коллектор позволяет организовать различные схемы сбора событий от любых активов, участвующих в сетевом взаимодействии, создающих журналы событий.

Основные функции:

  • сбор, локально и удалённо по различным протоколам;
  • отправка событий в другие системы;
  • обработка событий перед отправкой;
  • пересылка событий в зашифрованном виде и со сжатием;
  • отправка по расписанию;
  • накопление событий при разрыве соединения и отправка после восстановления.

Поддерживаемые операционные системы следующих семейств:

  • Windows Vista, Windows 10, Windows 11;
  • Windows Server 2008, Windows Server 2011, Windows Server 2016, Windows Server 2019, Windows Server 2022;
  • Linux Debian;
  • Linux CentOS;
  • Linux RedHat.

Поддерживаемые способы и протоколы отправки:

  • TCP;
  • SSL/TLS;
  • UDP;
  • Kafka;
  • Запись в локальный файл.

Сбор событий

  1. Локальный:

    • Event Tracing for Windows (ETW);
    • File Read;
    • Windows Event Log;
    • Результаты работы скрипта (Python/CMD/PowerShell/Bash/Perl).
  2. Удалённый:

    • Windows Event Log via RPC;
    • WMI;
    • ODBC;
    • File via SMB;
    • File via SSH;
    • File via FTP;
    • File via SFTP;
    • File via HTTP(S);
    • Checkpoint OPSEC LEA.
  3. Пассивный:

    • TCP;
    • UDP;
    • Netflow v5, v9;
    • Syslog;
    • SNMP Trap;
    • HTTP.

Основные характеристики

Программное обеспечение Лог-коллектор обеспечивает решение перечисленных ниже основных задач:

  • сбор/прием событий;
  • обработка событий;
  • отправка событий;
  • временное хранение событий.

Сбор/прием событий может осуществляться в любом из трех режимов:

  • Локальный. Лог-коллектор устанавливается в системе в виде агента, производит чтение файлов etw, eventlog, wmi, получение результатов выполнения скриптов (bash, perl, python, PowerShell) и их отправку в Платформу (либо в промежуточный агент).

  • Пассивный. Лог-коллектор осуществляет прием событий от систем, которые могут самостоятельно отправлять данные.

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

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

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

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

С учётной записью/без учётной записи. Лог-коллектор имеет возможность сбора событий как с использованием указанной служебной учетной записи для доступа к событиям, так и без учётной записи (для транспортов, где это технически возможно).

Архитектура

Лог-коллектор имеет компонентную архитектуру и включает в себя следующие программные компоненты:

  • Контроллер (controller)— осуществляет управление всеми компонентами лог-коллектора
  • Компонент сбора метрик (metric_server)— осуществляет сбор статистики по работе лог-коллектора
  • Компонент API управления (api_server)— предоставляет возможность удаленного управления лог-коллектором и мониторинга
  • Компонент журналирования (journal)— осуществляет ведение журнала работы лог-коллектора
  • Компоненты сбора/приема событий (inputs) — осуществляют сбор событий
  • Компоненты отправки событий (outputs) — осуществляют оправку событий

Управление настройками лог-коллектора и его компонентов может осуществляться как через основной конфигурационный файл на сервере, где установлен экземпляр Лог-коллектора, так и централизовано, из веб-интерфейса Платформы Радар Управление Лог-коллектором.

Установка лог-коллектора

Требования к техническому и программному обеспечению

Минимальные требования к ресурсам:

  • 4 Core
  • 4 GB RAM
  • 60 GB HDD

Минимальные требования к ресурсам при установке в системе с настроенным сервисом Windows Event Collector:

  • 4 Core
  • 8 GB RAM
  • 500 GB HDD

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

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

  • Windows Vista, Windows 10, Windows 11;
  • Windows Server 2008, Windows Server 2011, Windows Server 2016, Windows Server 2019, Windows Server 2022;
  • Linux Debian;
  • Linux CentOS;
  • Linux RedHat.

На приведенных выше минимальных требованиях к ресурсам лог-коллектор обеспечивает обработку потока 5000 событий в секунду.

Возможные схемы развертывания

  • Установка на источнике для организации локального сбора событий с последующей передачей в Платформу или в промежуточный лог-коллектор.
  • Установка на выделенный сервер для организации удаленного сбора и пересылки событий.
  • Установка цепочки лог-коллекторов для передачи событий в зашифрованном виде.

Установка лог-коллектора на различных ОС

Важно! Установка лог-коллектора осуществляется под учетной записью с правами администратора.

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

Установка в ОС Windows

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

После распаковки в папке должны быть следующие файлы: - log-collector.exe (дистрибутив лог-коллектора) - config.yaml (файл конфигурации с минимально необходимыми для подключения настройками) - example.yaml (пример общего файла конфигурации)

Необходимо запустить терминал от имени администратора и перейти в раздел, куда предварительно была распакована папка с дистрибутивом Лог-коллектора.

cd c:\log-collector
Выполнить установку с помощью команды:
log-collector-<версия релиза>-<тип архитектур>.exe winsvc
Данная команда установит лог-коллектор в качестве сервиса ОС.

Запуск сервиса

net start PangeoRadarLogCollector
Остановка сервиса
net stop PangeoRadarLogCollector
Также можно выполнить запуск/остановку/перезапуск сервиса из оснастки «Сервисы»

Сервисы

Рисунок 1 -- Управление службой лог-коллектор в оснастке «Сервисы»

Если при запуске/перезапуске сервиса выводится ошибка, причину следует определять просмотром записей в журнале неудачных запусков Лог-коллектора logcollector.crash.log в папке, из которой была выполнена установка сервиса.

Конфигурационный файл лог-коллектора config.yaml находится в папке, откуда была выполнена установка сервиса.

Установка в ОС Linux Debian

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

openssl enc -aes-256-cbc -d -in log-collector-<версия релиза>-<тип архитектур>.tar.gz.enc | tar xz
Далее выполнить установку командой:
dpkg -iR ./
Проверка состояния сервиса
systemctl status log-collector
Перезапуск сервиса
systemctl restart log-collector

Основные настройки лог-коллектора

Важно! Для успешного запуска лог-коллектора необходимо выполнить основные настройки в конфигурационном файле config.yaml

Настройка централизованного управления

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

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

# Централизованное управление
cluster:
  url: "http://<ip адрес Платформы Радар>:9000/cm/api/agent/"
  api_key: "<API ключ>"

где:
- ключ доступа к API, сгенерированный в веб-интерфейсе Платформы

Более подробное описание по настройке централизованного управления приведено в Управление лог-коллектором.

Настройка контроллера

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

controller:
  # Порт компонента, обязательный параметр
  port: 48000

Настройка компонента сбора метрик

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

metric_server:
  # Порт компонента, обязательный параметр
  port: 48005
  log_level: "ERROR"

Настройка размещения защищенного хранилища

Защищенное хранилище используется для хранения чувствительных данных, которые не должны храниться в открытом виде.

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

# Путь к файлу с секретом
secret_file: "C:\\log-collector\\secret"
# Путь к хранилищу секретов
secret_storage: "C:\\log-collector\\secret.storage"

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

# <путь>log-collector secrets set <ключ> <значение> --config <путь до конфигурационного файла>

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

После создания секрета его можно подставить в виде конструкции - {{.ключ}}, вместо любой строки в конфигурационном файле. Таким образом, все учетные данные могут быть скрыты.

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

log-collector secrets set user User --config /etc/log-collector/config.yaml
log-collector secrets set user_password $ecure_P@ssw0rd --config /etc/log-collector/config.yaml
Пример использования в конфигурационном файле:
ssh_collector: &ssh_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "ssh_collector"
  # Имя пользователя для удаленного подключения, обязательный параметр\
  user: "{{.user}}"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт для подключения (default: 22)
  port: 22
  # Путь к файлу с ssh ключами, обязательный параметр
  rsa: "./ssh"
  # Пароль от файла с ключами
  password: "{{.user_password}}"
  # Команда для выполнения по ssh, обязательный параметр
  command: "tail -F -n +$$$line$$$ /var/log/sshfile.txt"
  # Если установлено - файл будет читаться с последней позиции в следующем тике
  # или после перезапуска
  read_from_last: true
  # Интервал между выполнением команд (в секундах)
  ticker: 30
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

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

# <путь>log-collector secrets list --config <путь до конфигурационногофайла>

где:
<путь> - путь до каталога, в котором находится исполняемый файл лог-коллектора

Для удаления ключей используется команда:

<путь>log-collector secrets remove <ключ> - -config <путь до конфигурационного файла>

где:
<путь> - путь до каталога, в котором находится исполняемый файл лог-коллектора
<ключ> - имя значения, которое нужно удалить.

Важно! Прописывать ключи в файле конфигурации нужно в кавычках, как в примере выше "{{.ключ}}", иначе при запуске приложения упадет с ошибкой из-за того что не сможет прочитать файл конфигурации. Соответствующее сообщение будет в журнале неудачных запусков Лог-коллектора logcollector.crash.log.

Настройка API

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

api_server:
  # ip адрес, на котором будем слушать http сервер
  address: "<Внещний ip адрес сервера, на котором установлен лог-коллектор>"
  # порт, на котором будем слушать http сервер, обязательный параметр
  port: 8080
  # Таймаут чтения (получение запроса), обязательный параметр
  read_timeout: 60
  # Таймаут записи (отправка запроса), обязательный параметр
  write_timeout: 60
  # Время ожидания окончания обработки запроса при получении сигнала на остановку приложения
  # Обязательный параметр
  wait: 5
  # Включение https (защищенное соединение)
  enable_tls: false
  # Путь для файла сертификатов, если enable_tls: false параметр не обязательный
  cert_file: "certs/server.crt"
  # Путь для файла ключей, если enable_tls: false параметр не обязательный
  key_file: "certs/server.key"
  # Пароль для расшифровки файла ключей, если не указан считаем, что файл не зашифрован
  cert_key_pass: ""
  # Включение проверки клиентского сертификата, обязательный параметр
  require_client_cert: true
  # Путь до корневого сертификата, обязательный параметр
  ca_file: "certs/ca.crt"
  # Уровень логирования, если не указан используется указанный в компоненте журналирования
  log_level: "INFO"

Настройка журналирования

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

Важно! Уровень логирования DEBUG используется только для отладки работы компонентов. В промышленной эксплуатации рекомендуется использовать уровень INFO.

journal:
  # Порт компонента, обязательный параметр
  port: 48004
  # Eровень логирования по умолчанию. Возможные значения - DEBUG, INFO, WARN, ERROR.
  # Обязательный параметр
  log_level: "INFO"
  # Путь к файлу журнала, обязательный параметр
  log_path: "C:\\log-collector\\journal.log"
  # Порог ротации файла логов, указывается в мегабайтах, обязательный параметр
  rotation_size: 30
  # Порог количества файлов истории, если не указано файлы удаляться не будут
  max_backups: 7
  # Максимальное количество дней для хранения старых файлов журнала на основе метки времени
  # Если не указано, файлы удаляться не будут (в днях).
  max_age: 7

Фильтрация событий

Структурированные данные

Фильтрация в компонентах сбора со структурированными данными работает как blacklist и применима к коллекторам wmi, eventlog, odbc, etw.

Неструктурированные данные

Фильтры можно указать для каждого коллектора с неструктурированными данными. Фильтры содержат белый список (whitelist) и черный список (blacklist) с массивом регулярных выражений. Все регулярные выражения проверяются перед запуском приложения. Сначала проверяется белый список, а затем черный.
Фильтрация по регулярным выражениям может быть включена в любом коллекторе с неструктурированными данными (кроме odbc, wmi, etw, eventlog). Включается путем добавления секции filters. В данной секции указываются два массива — whitelist, blacklist. Все события сначала проходят фильтры указанные в whitelist, т.к. его приоритет выше. Затем события проверяются фильтрами, указанными в blacklist.
Whitelist — события, которые соответствуют регулярному выражению, попадают в очередь на отправку.
Blacklist — события, которые соответствуют регулярному выражению, блокируются и не попадают в очередь на отправку.

ssh_collector: &ssh_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "ssh_collector"
  # Имя пользователя для удаленного подключения, обязательный параметр
  user: "user"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт для подключения (default: 22)
  port: 22
  # Путь к файлу с ssh ключами, обязательный параметр
  rsa: "./ssh"
  # Пароль от файла с ключами
  password: "password"
  # Команда для выполнения по ssh, обязательный параметр
  command: "tail -F -n +$$$line$$$ /var/log/sshfile.txt"
  # Если установлено - файл будет читаться с последней позиции в следующем тике
  # или после перезапуска
  read_from_last: true
  # Интервал между выполнением команд (в секундах)
  ticker: 30
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  filters:
    whitelist:
      - "^localhost.*$"
    blacklist:
      - "^.*[0-9]$"

Настройка очереди отправки событий

Применимо к компонентам отправки событий TCP и KAFKA

# Максимальное количество сообщений в буфере
queue_length_limit: 1500
# максимальное время жизни событий в очереди (в секундах)
queue_time_limit: 300

Формат отправки данных

Применим ко всем неструктурированным компонентам сбора событий (кроме eventlog, wmi, odbc, etw)

# Формат отправки сообщения - как есть(raw), с обогащением(json)
format: "raw"

raw - данные отправляются в том виде, в котором пришли
json - пришедшие данные обогащаются дополнительной технической информацией и упаковываются в пакет json

Кодировка

Данная секция позволяет изменить кодировку входящих данных. Если не указывать original_encoding, лог-коллектор сам попытается определить кодировку.

# Опции смены кодировки
encoding:
  # Использовать кодировку в UTF-8
  change_to_utf8: false
  # Кодировка оригинала
  original_encoding: "cp1251"

Описание хранилища приложения

Хранилище ключей значений в файловой системе ОС (LevelDB). Используется для хранения ссылок и буферизации событий. Не предусмотрено стороннее редактирование.
Папка с файлами хранилища (.storage) располагается в рабочей директории лог-коллектора.

Компоненты лог-коллектора

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

Важно! При настройке не использовать повторяющихся названий настроек компонентов, ссылок на них и уникальных идентификаторов.

Пример:

# Название конфигурации компонента и ссылка на него для запуска
<наименование настройки компонента>: &<уникальная ссылка на настройку>
# Уникальный идентификатор компонента, отображается в логах и метриках. Обязательный параметр
  id: "<уникальный идентификатор>"

Компоненты сбора событий (inputs)

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

Компонент Eventlog

Важно! Работает только на ОС Windows.

Позволяет выполнить локальный или удаленный сбор событий Windows.

Пример настроек по умолчанию:

# Название конфигурации компонента и ссылка на него для запуска
eventlog_collector: &eventlog_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "eventlog_collector"
  # Имя канала (Security, Application, System, ForwardedEvents)
  # Используется если не указан путь к файлу
  channel: ['Security']
  # Запрос описывающий тип получаемого события. Может быть в формате
  # XPath 1.0 или структурированный XML запрос. Если XPath содержит более 20 параметров,
  # следует использовать структурированный XML запрос.
  # Чтобы получить все параметры укажите "*"
  query: "*"
  # Полный путь к файлу журналов событий
  # Поддерживаемые форматы: .evt, .evtx, .etl
  file: ""
  # Размер запроса
  batch_size: 50
  # Таймаут запроса в секундах
  timeout: 5
  # Интервал между запуском запроса в секундах
  poll_interval: 30
  # Чтение с последней сохраненной позиции
  read_from_last: true
  # Конвертировать SID в имя
  resolve_sid: false
  # формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования. Если не указан используется уровень компонента журналирования
  log_level: "INFO"
  # количество параллельных воркеров (по умолчанию 1), 2 и более позволяет распараллелить сбор событий
  worker_count: 1
  # Параметры удаленного подключения
  remote:
    # Включение удаленного соединения
    enabled: false
    # Имя пользователя, обязательно если enabled: true
    user: ""
    # Пароль пользователя, обязательно если enabled: true
    password: ""
    # Домен пользователя
    domain: "."
    # Адрес удаленного сервера
    remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
    # Доступные методы авторизации: Negotiate, Kerberos, NTLM
    auth_method: "Negotiate"
    # Фильтрация по полям события, регулярные выражения
  filters:
    # Время
    # формат 2020-08-13 10:02:55.9689259 +0000 UTC
    created: ''
    # Числовые фильтры
    # Пример для числовых фильтров - ^([5-9]\d|\d{3,})$
    event_id: ''
    qualifiers: ''
    record_id: ''
    process_id: ''
    thread_id: ''
    version: ''
    # Строковые фильтры
    # пример: DESKTOP-IDCMV6G
    computer_name: ''
    msg: ''
    # Возможные значения: Information, Warning, Error
    level_text: ''
    # Пример: Service State Event
    task_text: ''
    # Пример: ServiceShutdown
    opcode_text: ''
    # Пример: System
    channel_text: ''
    # Пример: System
    provider_text: ''

    # Возможно применение опций смены кодировки

Компонент MS-EVEN6

mseven6: &mseven6
  # названия модуля, отображается в логах и метриках, уникальный обязательный параметр
  id: "test_mseven6"
  # Список источников для сбора событий
  sources:
    -
      # Адрес удаленного сервера, с которого будут собираться события
      host: "192.168.56.6"
      # домен
      domain: ""
      #  Имя пользователя
      user: "user"
        # Пароль пользователя
      password: "0000"
      # Список каналов
      channel: ["Application"]
      # Запрос описывающий тип получаемого события. есть возможность указать
      # XPath 1.0 или структурированный XML запрос. Если XPath содержит более 20 параметров, следует
      # использовать структурированный XML запрос. Чтобы получить все параметры укажите "*"
      query: "*"
  # Размер запроса
  batch_size: 20
  # интервал между запуском запроса в секундах (default: 1)
  poll_interval: 1
  # Чтение с последней сохраненной позиции, (default: false)
  read_from_last: true
  # уровень логирования, если не указан используется уровень модуля журналирования
  log_level: "DEBUG"
  # путь для запуска python (лучше использовать venv, создается командой make mseven6venv)
  python_path: "./bin/mseven6venv/bin/python"
  # порт для взаимодействия с python сервисом-прослойкой
  python_service_port: 9999
  # Фильтрация по полям события, регулярные выражения (блэклист)
  filters:
    # Время
    # формат 2020-08-13 10:02:55.9689259 +0000 UTC
    created: ''
    # Числовые фильтры
    # Пример для числовых фильтров - ^([5-9]\d|\d{3,})$
    event_id: ''
    qualifiers: ''
    record_id: ''
    process_id: ''
    thread_id: ''
    version: ''
    # Строковые фильтры
    # пример: DESKTOP-IDCMV6G
    computer_name: ''
    msg: ''
    # Возможные значения: Information, Warning, Error
    level_text: ''
    # Пример: Service State Event
    task_text: ''
    # Пример: ServiceShutdown
    opcode_text: ''
    # Пример: System
    channel_text: ''
    # Пример: System
    provider_text: 'System'
  # Опции смены кодировки
  encoding:
    # Использовать кодировку в UTF-8
    change_to_utf8: false
    # Кодировка оригинала
    original_encoding: "cp1251"

Компонент ODBC

Позволяет осуществлять сбор событий из баз данных.

odbc_collector: &odbc_collector
  # Уникальный идентификатор компонента, отображается в журналах иметриках.
  # Обязательный параметр
  id: "odbc_collector"
  # Интервал между запуском запроса в секундах
  poll_interval: 5
  # Чтение с последней сохраненной позиции
  read_from_last: true
  # Строка подключения, обязательный параметр
  connection_string: "server=<ip адрес удаленного узла> или <имя удаленного узла>;port=<порт>;driver=<название драйвера>;database=<название базы данных>;Uid=<пользователь>;Pwd=<пароль>"
  # SQL запрос, обязательный параметр
  sql: >
    SELECT id, name, dsc
    FROM test WHERE id > ?;
  # Поле, которое будет использоваться как закладка для сохранения позиции, обязательный параметр
  # Поле должно быть целочисленным
  # Поле должно быть указано в операторе SELECT
  bookmark_field: "id"

Примеры строк подключения:

PostgreSQL:
Driver={PostgreSQL};Server=IP address;Port=5432;Database=myDataBase;Uid=myUsername;Pwd=myPassword;

MSSQL:
Driver={ODBC Driver 17 for SQL Server};Server=myServerAddress;Database=myDataBase;UID=myUsername;PWD=myPassword;Driver={ODBC Driver 17 for SQL Server};Server=myServerAddress;Database=myDataBase;Trusted_Connection=yes;

Oracle:
Driver={Oracle ODBC Driver};UID=Kotzwinkle;PWD=whatever;DBQ=instl_alias;DBA=W;

Компонент WMI

Важно! Работает только на ОС Windows

wmi_collector: &wmi_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "wmi_collector"
  # Интервал между запуском запроса в секундах
  poll_interval: 5
  # Список серверов к которым уйдет wmi запрос, обязательный параметр
  remote_servers:
    - "localhost"
    - "имя удаленного узла"
    - "ip адрес удаленного узла"
  # Имя пользователя, обязательно если это не локальный сбор
  # Для сбора в домене "domain\\user"
  user: "user"
  # Пароль пользователя, обязательно если это не локальный сбор
  password: ""
  # Чтение с последней сохраненной позиции
  read_from_last: true
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"
  # изменение кодировки входящего события, может быть прописана у любого коллектора
  encoding:
    # включение изменения кодировки
    change_to_utf8: false
    # оригинальная кодировка события, если оставить пустым, произойдет попытка определить кодировку
    # нет 100% гарантии определения
    original_encoding: "cp1251"
  # Собирать события начиная с заданного момента
  start_from_date: "2022-03-24T00:00:00+03:00"
  # Список журналов, из которых собираются события (Application, System и т.п.). Если пустой или не указан, собираются все события
  logfiles: ["Application"]
  # Блэклист фильтры по полям события, используются регулярные выражения
  wmi_filters:
    # Числовые поля
    category: ''
    event_code: ''
    event_identifier: ''
    event_type: ''
    record_number: ''
    # Строковые поля
    computer_name: ''
    message: ''
    source_name: ''
    type: ''
    user: ''
    time_generated: ''
    time_written: ''

  # Возможно применение опций смены кодировки

Компонент ETW

Важно! Работает только на ОС Windows

etw_collector: &etw_collector
  # Имя провайдера или GUID
  # Формат GUID должен быть "{9E814AAD-3204-11D2-9A82-006008A86939}"
  id: "etw_collector"
  provider: "{A68CA8B7-004F-D7B6-A698-07E2DE0F1F5D}"
  kernel_args: [ "ALPC", "CSWITCH", "DBGPRINT", "DISK_FILE_IO", "DISK_IO", "DISK_IO_INIT", "DISPATCHER", "DPC", "DRIVER", "FILE_IO", "FILE_IO_INIT", "IMAGE_LOAD", "INTERRUPT", "MEMORY_HARD_FAULTS", "MEMORY_PAGE_FAULTS", "NETWORK_TCPIP", "NO_SYSCONFIG", "PROCESS", "PROCESS_COUNTERS", "PROFILE", "REGISTRY", "SPLIT_IO", "SYSTEMCALL", "THREAD", "VAMAP", "VIRTUAL_ALLOC" ]
  provider_level: "Information"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент OPSEC LEA

Важно! Работает только на ОС Linux

opsec_lea_collector: &opsec_lea_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "opsec_lea_collector"
  # Директория расположения утилиты lea_client
  exec_path: "opsec"
  # Периодичность проверки наличия новых записей в журналах
  poll_interval: 5
  # Сохранение позиции последнего чтения из журнала (сохранение на диск), возобновление чтения с последней сохраненной позиции.
  read_from_last: false
  # Сервер для сбора событий.
  remote_server: "<ip адрес или имя удаленного узла>"
  # Порт для аутентификации.
  auth_port: 18184
  # Аутентификация для OPSEC
  auth_type: "sslca"
  # Параметры авторизации
  opsec_sic_name: "CN=lea_logger,O=vmfw..ktz7qd"
  opsec_sslca_file: "/home/lea/lea_client/opsec.p12"
  opsec_entity_sic_name: "cn=cp_mgmt,o=vmfw..ktz7qd"
  opsec_sic_policy_file: ""
  # Название собираемого журнала.
  log_filename: "fw.log"
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

Компонент SSH

ssh_collector: &ssh_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "ssh_collector"
  # Имя пользователя для удаленного подключения, обязательный параметр
  user: "user"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт для подключения (default: 22)
  port: 22
  # Путь к файлу с ssh ключами, обязательный параметр
  rsa: "./ssh"
  # Пароль от файла с ключами
  password: ""
  # Команда для выполнения по ssh, обязательный параметр
  command: "tail -F -n +$$$line$$$ /var/log/sshfile.txt"
  # Если установлено - файл будет читаться с последней позиции в следующем тике или после перезапуска
  read_from_last: true
  # Интервал между выполнением команд (в секундах)
  ticker: 30
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент SMB

smb_collector: &smb_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "smb_collector"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт подключения
  port: 445
  # SMB share. sharename должен соответсвовать формату `<share>` или `\\\\<server>\\<share>`, обязательный параметр
  share: "<путь к общему ресурсу>"
  # Домен
  domain: "."
  # NTLMv2 пользователь, обязательный параметр
  user: "user"
  # NTLMv2 пароль(или hash), обязательный параметр
  password: "password"
  # настройки аутентификации kerberos
  kerberos:
    # включение авторизации kerberos
    enabled: false
    # имя целевого сервиса (service principal name)
    target_spn: "pdc"
    # kerberos realm
    realm: "TEST.TEST"
    # путь до конфигурации kerberos
    config_path: "assets/krb5/krb5.conf"
  # Интервал между запуском сканирования файлов в секундах
  poll_interval: 5
  # Список файлов для чтения, обязательный параметр
  files: [ "smbfile.txt" ]
  # Если установлено - использовать регулярное выражение для поиска файлов
  using_regexp: true
  # Начальный каталог для поиска файлов
  regexp_starting_dir: "."
  # Регулярное выражение для поиска файлов
  regexp_expression: ".(?:txt|log)$"
  # Интервал проверки файлов (в секундах) в дереве каталогов
  dir_check_interval: 5
  # Если установлено - файл будет читаться с последней позиции в следующем тике
  # или после перезапуска
  read_from_last: true
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент FTP

ftp_collector: &ftp_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "ftp_collector"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт для ftp запросов, обязательный параметр
  port: 21
  # ftp пользователь, обязательный параметр
  user: ""
  # ftp пароль, обязательный параметр
  password: ""
  # Интервал между сканированием файла в секундах
  poll_interval: 5
  # Список файлов для чтения, обязательный параметр
  files: ["ftpfile.txt"]
  # Если установлено - использовать регулярное выражение для поиска файлов
  using_regexp: true
  # Начальный каталог для поиска файлов
  regexp_starting_dir: "."
  # Регулярное выражение для поиска файлов
  regexp_expression: ".(?:txt|log)$" #"^.*\_logs$"
  # Интервал проверки файлов (в секундах) в дереве каталогов
  dir_check_interval: 5
  # Если установлено - файл будет читаться с последней позиции в следующем тике
  # или после перезапуска
  read_from_last: true
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент SFTP

sftp_collector: &sftp_collector
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "sftp_collector"
  # Список хостов для подключения, обязательный параметр
  remote_servers: ["<ip адрес удаленного узла>", "<имя удаленного узла>"]
  # Порт для sftp запросов, обязательный параметр
  port: 22
  # Пользователь ssh, обязательный параметр
  user: "user"
  # Пароль ssh, обязательный параметр
  password: "password"
  # Интервал между сканированием файла в секундах
  poll_interval: 5
  # Список файлов для чтения, обязательный параметр
  files: ["sftptest.txt"]
  # Если установлено - использовать регулярное выражение для поиска файлов
  using_regexp: false
  # Начальный каталог для поиска файлов
  regexp_starting_dir: "upload"
  # Регулярное выражение для поиска файлов
  regexp_expression: ".(?:txt|log)$" #"^.*_logs$"
  # Интервал проверки файлов (в секундах) в дереве каталогов
  dir_check_interval: 5
  # Если установлено - файл будет читаться с последней позиции при следующем тике или после перезапуска
  read_from_last: true
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент NetFlow

netflow_input: &netflow_input
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "netflow_input"
  # Хост на каком запустится сервер (default: localhost)
  host: "<ip адрес лог-коллектора>"
  # Порт на каком запустится сервер (обязательное)
  port: 2162
  # Размер буфера сообщений (если не задано то берется из SO_RCVBUF)
  sock_buf_size: 0
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень сообщений в логах, могут быть значения - DEBUG, INFO, WARN, ERROR
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент TCP

tcp_input: &tcp_input\
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "tcp_input"
  # Хост на каком запустится сервер
  host: "<ip адрес лог-коллектора>"
  # Порт на каком запустится сервер
  port: <порт для приема соединений>
  # Включение TLS соединения на сервере
  enable_tls: false
  # Файл с приватным ключом (обязательное поле при включенном TLS)
  key_file: "certs/server.key"
  # Файл с сертификатом должно быть подписанным сертификатом CA (обязательное поле при включенном TLS)
  cert_file: "certs/server.crt"
  # Файл с паролем если сертификат подписывался с паролем
  cert_key_pass: ""
  # Файл с сертификатом CA (обязательное поле при включенном TLS)
  ca_file: "certs/ca.crt"
  # Проверять ли сертификаты клиента
  require_client_cert: false
  # Нужна ли распаковка тела запроса, ожидается, что клиент упаковал тело запроса в архив (default: false)
  compression_enabled: false
  # Количество соединений, которые может принять сервер
  connections_limit: 10
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент UDP

udp_input: &udp_input
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "udp_input"
  # Хост на каком запустится сервер
  host: "<ip адрес лог-коллектора>"
  # Порт на каком запустится сервер
  port: <порт для приема соединений>
  # Размер буфера сообщений (если незаданно то берется из SO_RCVBUF)
  sock_buf_size: 0
  # формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент HTTP приемник

http_input: &http_input
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "http_input" 
  # Хост на каком запустится сервер (default: localhost)
  host: "<ip адрес лог-коллектора>"
  # Порт на каком запустится сервер (обязательное)
  port: <порт для приема соединений>
  # Включение TLS соединения на сервере (default: false)
  enable_tls: false
  # Файл с приватным ключом (обязательное поле при включенном TLS)
  key_file: "certs/server.key"
  # Файл с сертификатом должно быть подписанным сертификатом CA (обязательное поле при ключенном TLS)
  cert_file: "certs/server.crt"
  # Файл с паролем если сертификат подписывался с паролем
  cert_key_pass: ""
  # Файл с сертификатом CA (обязательное поле при включенном TLS)
  ca_file: "certs/ca.crt"
  # Проверять ли сертификаты клиента (default: false)
  require_client_cert: false
  # Количество соединений, которые может принять сервер
  connections_limit: 10
  # формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент HTTP сборщик

http_collector: &http_collector\
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "http_collector"
  # Удаленный адрес для вызовов http (обязательное)
  remote_server: "<ip адрес или имя удаленного узла>"
  # Удаленный порт (default: 80)
  port: <порт на целевой системе>
  # Имя пользователя для базовой авторизации, если пустое, считаем, что авторизация выключена
  basic_auth_user: ""
  # Пароль для базовой авторизации
  basic_auth_password: ""
  # Ограничение по времени для запросов, сделанных http-клиентом в секундах (default: 10)\
  timeout: 10
  # Если установлено - будет использоваться tls клиент
  enable_tls: false
  # Путь к .key файлу, обязательно если enable_tls: true
  key_file: "certs/server.key"
  # Путь к .crt файлу, обязательно если enable_tls: true
  cert_file: "certs/server.crt"
  # Пароль к файлу сертификатов
  cert_key_pass: ""
  # Путь к файлу с набором корневых центров сертификации, обязательно
  если enable_tls: true
  ca_file: "certs/ca.crt"
  # Имя файла для получения по http
  file: "httptest.txt"
  # Если установлено - файл будет читаться с последней позиции в следующем тике или после перезапуска (default: false)
  read_from_last: true
  # Интервал между http-вызовами в секундах
  poll_interval: 5
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент File

file_input: &file_input
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "file_input"
  # Интервал между чтениями файла, в секундах)
  poll_interval: 5
  # Список файлов для чтения
  files: ["logfile.txt"]
  # Использовать regexp для поиска файлов
  using_regexp: false
  # Начальный каталог для поиска файлов
  regexp_starting_dir: "."
  # regexp для поиска файлов
  regexp_expression: "^.*_logs$"
  # Интервал поиска файлов в секундах, в дереве каталогов
  dir_check_interval: 5
  # Если установлено - файл будет читаться с последней позиции в следующем тике или после перезапуска\
  read_from_last: true
  # Создает file watchers для всех файлов
  enable_watcher: true
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент External Command

external_command_input: &external_command_input
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "external_command_input"
  # Интервал между выполнениями команд
  poll_interval: 5
  # Команда bash/cmd
  command: "<команда выполнения скрипта>"
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компонент SNMP Trap

snmp_trap: &snmp_trap
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "snmp_trap"
  # Адресс snmp менеджера
  host: "<ip адрес лог-коллектора>"
  # Порт для запуска snmp менеджера
  port: 162
  # Принимать только аутентифицированные SNMP v3 Traps
  allow_authenticated_only: false
  # Список директорий с .mib файлами для конвертации oid
  # Если не указаны, oid будут передаваться в сыром виде
  mib_dirs:
    - dir1
    - dir2
    - dir3
  # Параметры безопасности
  # Методы аутентификации. Возможные значения:
  # - MD5
  # - SHA
  auth_proto: "SHA"
  # Методы шифрования. Поддерживается только DES.
  encrypt_proto: "DES"
  # Имя SNMP пользователя
  user_name: "user"
  # Пароль аутентификации. Используется с MD5 или SHA
  authentication_passphrase: "user_pass"
  # Пароль шифрования для DES
  privacy_passphrase: "priv_user_pass"
  # Используется в SNMPv3 для идентификации сущностей.
  authoritative_engine_id: "880000009fe71969bdd782bbc691c06b524d70324abe96c0755"
  # Формат отправки сообщения - как есть(raw), с обогащением(json)
  format: "raw"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

  # Возможно применение опций смены кодировки

Компоненты отправки событий (outputs)

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

Компонент отправки событий по протоколу TCP

Позволяет отправлять данные по протоколу TCP. Также есть возможность отправки в зашифрованном виде, со сжатием, с настройкой буферизации.

tcp_output: &tcp_output
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "tcp_output"
  # Адрес куда отправлять события, обязательный параметр
  target_host: "<ip адрес или имя удаленного узла>"
  # Порт куда отправлять события, обязательный параметр
  port: <порт на целевой системе>
  # Включение batch режима
  batch_mode_enable: false
  # Период отправки пакета в секунундах при включенном batch режиме
  batch_flush_interval: 5
  # Количество сообщений, которые попадут в пакет при включенном batch режиме
  batch_flush_limit: 500
  # Включение сжатия, включение при выключенном batch режиме ощутимо замедляет отправку
  ssl_compression: false
  # Включение проверки сертификата
  require_cert: false
  # Включение ssl\
  ssl_enable: false
  # Путь для файла сертификатов, если enable_tls: false параметр не обязательный
  cert_file: "client-cert.pem"
  # Путь для файла ключей, если enable_tls: false параметр не обязательный
  key_file: "client-key.pem"
  # Пароль для расшифровки файла ключей, если не указан считаем, что файл не зашифрован
  cert_key_pass: ""
  # Путь до корневого сертификата, если enable_tls: false не обязательный параметр
  ca_file: "ca.pem"
  # уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"
  # максимальное количество сообщений в буфере
  #queue_length_limit: 1500
  # максимальное время жизни событий в очереди. в секундах
  #queue_time_limit: 300

Компонент отправки событий по протоколу UDP

Позволяет отправлять данные по протоколу UDP.

udp_output: &udp_output
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "udp_output"
  # Адрес куда отправлять события
  target_host: "<ip адрес или имя удаленного узла>"
  # Порт, на который отправлять события. Обязательный параметр
  port: <порт на целевой системе>
  # Размер буфера для отправки, если не указан или равен нулю используется системное значение
  sock_buf_size: 0
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

Компонент отправки событий в KAFKA

Позволяет отправлять данные в KAFKA.

kafka_output: &kafka_output
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "kafka_output"
  # Включение проверки сертификата (default: false)
  require_cert: false
  # Включение ssl (default: false)
  ssl_enable: false
  # Путь для файла сертификатов, если ssl_enable: false параметр не обязательный
  cert_file: "certs/server.crt"
  # Путь для файла ключей, если ssl_enable: false параметр не обязательный
  key_file: "certs/server.key"
  # Пароль для расшифровки файла ключей, если не указан считаем, что файл не зашифрован
  cert_key_pass: ""
  # Путь до корневого сертификата, если ssl_enable: false параметр не обязательный
  ca_file: "certs/ca.crt"
  # Таймауту отправки события в секундах, обязательный параметр
  timeout: 10
  # Топик в который попадет событие, обязательный параметр
  topic: "<наименование топика>"
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"
  # Кafka брокеры, обязательный параметр
  brokers:
    - "<ip адрес или имя удаленного узла>:9092"
  # Максимальное количество сообщений в буфере
  #queue_length_limit: 1500
  # Максимальное время жизни событий в очереди (в секундах)
  #queue_time_limit: 300

Компонент записи событий в локальный файл

Позволяет записать входящие события в локальный файл.

out_file: &out_file
  # Уникальный идентификатор компонента, отображается в журналах и метриках.
  # Обязательный параметр
  id: "file_output"
  # Путь до файла куда будут записываться события, обязательный параметр
  file: "ouput_file.txt"
  # Порог ротации в мегабайтах, если указан ноль ил не указан совсем ротация не происходит
  rotation_size: 10
  # Уровень логирования, если не указан используется уровень компонента журналирования
  log_level: "INFO"

Включение компонентов

Для того, чтобы включить компоненты сбора или отправки, необходимо добавить их в разделах настроек collectors для компонентов сбора или senders для компонентов отправки в конфигурационном файле Лог-коллектора.

Включение компонентов сбора (collectors)

В разделе collectors необходимо прописать следующие настройки (пример для компонента сбора eventlog):

collectors:
  # Уровень логирования, если не указан используется уровень логирования компонента журналирования\
  log_level: "INFO"
  # eventlog коллектор, работает только на windows vista и старше
  event_log:
  - <<: *eventlog_collector

Включение компонентов отправки (senders)

В разделе senders необходимо прописать следующие настройки (пример для компонента отправки по TCP):

senders:
  # Порт компонента, обязательный параметр
  port: 48002
  # Уровень логирования, если не указан используется уровень логирования компонента журналирования
  log_level: "INFO"
  # Отправка по протоколу tcp
  tcp:
    - <<: *tcp_output

Маршрутизация событий

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

  1. Настроить маршруты взаимодействия между компонентами сбора событий и компонентами отправки событий.

    Пример настройки маршрута:

    route_1: &route_1
    collector_id:
        - "eventlog_collector"
        - "tcp_input"
    sender_id:
        - "tcp_output"
    

  2. Включить маршрут в разделе конфигурационного файла routers.

    Пример включения маршрута:

    routers:
    - <<: *route_1
    

Важно! Компоненты, используемые в маршрутах, обязательно должны быть включены в разделах collectors и senders и настроены.

Инструкция по настройке AppLocker

  1. Проверить статусы и при необходимости запустить службы Application Management и Application Identity.
  2. Зайти в secpol.msc -> Application Control Policies -> AppLocker -> Configure rule enforcement.

  3. Включить все наборы правил и выставить тип работы «Audit only», кроме правил типа «Executable rules» (enforce - для получения события 8004).

  4. Наполнить наборы правилами. «Automatically Generate Rules» - автоматически, «Create New Rule» - вручную.

    • Автоматически.

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

      Указать, как будут анализироваться файлы: по сертификату, по хэшу или по пути.

      Проверить правило и нажать «Create».

    • Вручную.

      Указать действие (разрешить или запретить запуск) и пользователя (группу пользователей), на кого применится правило.

      Выбрать тип проверки файла: по сертификату, либо по пути, либо по хэшу.

      В зависимости от типа проверки файлов добавить условие (путь, либо хэш, либо сертификат).

      При необходимости добавить исключение из правила.

      Добавить имя правила и нажать «Create».

  5. Применить политику, запустив в командной консоли:

    gpupdate /force

  6. Проверить наличие событий AppLocker: EventViewer.msc -> Application and Service Log -> Microsoft -> Windows -> AppLocker

  7. Добавить в конфигурационный файл лог-коллектора канал сбора событий AppLocker и перезапустить лог-коллектор (на примере Linux).

    $ vi /opt/pangeoradar/configs/logcollector/config.yaml
    .....
    channel: ["Security", "System", "Windows PowerShell", "Microsoft-Windows-AppLocker/EXE and DLL", "Microsoft-Windows-AppLocker/MSI and Script"]
    .....
    $ systemctl restart pangeoradar-logcollector-agent.service