Устранение неполадок CEF и системного журнала с помощью соединителей AMA

В этой статье содержатся рекомендации по устранению неполадок при сборе данных common Event Format (CEF) и системного журнала с помощью агента Azure Monitor Agent (AMA) в Microsoft Sentinel. Используйте это руководство для диагностики и устранения проблем с приемом на компьютерах сервера пересылки журналов. Команды и конфигурации должны выполняться на компьютерах переадресации журналов, на которых установлены AMA и RSyslog/Syslog-ng.

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

Обзор архитектуры

На следующей схеме показан поток данных из источников журналов в рабочие области Microsoft Sentinel/log analytics через RSyslog и агент мониторинга Azure.

Схема, показывающая поток данных из источника в Log Analytics через RSyslog и AMA.

Ключевые компоненты:

  • RSyslog/Syslog-ng: получает журналы через порт 514 и пересылает их в AMA.
  • Агент мониторинга Azure: обрабатывает журналы в соответствии с правилами сбора данных (DCR)
  • Правило сбора данных: определяет, какие журналы собирать и куда их отправлять.

Начальные шаги проверки

Проверка получения журналов

После настройки журналы могут отображаться в Microsoft Sentinel до 20 минут.

  1. Запустите tcpdump, чтобы убедиться, что журналы поступают в сервер пересылки:

    sudo tcpdump -i any port 514 -A -vv

  2. Убедитесь, что источник журнала настроен для отправки сообщений на правильный IP-адрес сервера пересылки.

  3. Проверьте наличие компонентов инфраструктуры, которые могут повлиять на подключение:

    • Брандмауэры
    • Подсистемы балансировки нагрузки
    • Группы безопасности сети

Проверка состояния расширения агента мониторинга Azure

  1. В портал Azure перейдите к виртуальной машине пересылки журналов.
  2. Выберите Расширения и приложения.
  3. Выберите расширение AzureMonitorLinuxAgent .
  4. Убедитесь, что состояние показывает, что подготовка выполнена успешно.

Проверка версии агента

  1. В колонке расширения AzureMonitorLinuxAgent проверка поле Версия.
  2. Убедитесь, что версия является одной из последних выпусков 2–3. Последние версии см. в разделе Сведения о версии AMA .

Примечание.

Развертывание новых версий может занять до 5 недель после первоначального выпуска.

Устранение неполадок на уровне агента

Убедитесь, что агент и службы RSyslog запущены.

sudo systemctl status azuremonitoragent
sudo systemctl status rsyslog
sudo systemctl status syslog-ng.service # If using Syslog-ng

Проверка конфигурации RSyslog

Конфигурация RSyslog состоит из /etc/rsyslog.conf файлов и в /etc/rsyslog.d/.

  1. Проверьте конфигурацию порта:

    grep -E 'imudp|imtcp' /etc/rsyslog.conf

    Ожидаемые выходные данные:

    module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

  2. Убедитесь, что конфигурация переадресации AMA существует:

    cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf

    Файл должен начинаться с:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Проверка состояния порта

Убедитесь, что необходимые порты прослушивают:

sudo ss -lnp | grep -E "28330|514"

Ожидаемые выходные данные:

udp   UNCONN 0      0      0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=5))
tcp   LISTEN 0      10     127.0.0.1:28330     0.0.0.0:*    users:(("mdsd",pid=1424,fd=1363))
tcp   LISTEN 0      25     0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=7))

Это подтверждает следующее:

  • RSyslog прослушивает порт 514 (TCP и UDP)
  • MDSD (компонент AMA) прослушивает порт 28330 (TCP)

Проверка конфигурации правила сбора данных

Проверьте, правильно ли настроен DCR в агенте.

Для журналов CEF:

sudo grep -i -r "SECURITY_CEF_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Для журналов Cisco ASA:

sudo grep -i -r "SECURITY_CISCO_ASA_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

В выходных данных должна отображаться строка JSON, содержащая конфигурацию DCR.

Проверка правил брандмауэра

Убедитесь, что правила брандмауэра разрешают обмен данными между:

  • Источник журнала и RSyslog (порт 514)
  • RSyslog и AMA (порт 28330)
  • Конечные точки AMA и Azure

Настройка правила сбора данных

Включение всех средств для устранения неполадок

Для первоначального устранения неполадок:

  1. В портал Azure перейдите к правилу сбора данных.
  2. Включите все средства системного журнала.
  3. Выберите все уровни журнала.
  4. Если это возможно, включите сбор сообщений без возможности или серьезности.

Дополнительные сведения см. в разделе Выбор средств и серьезности.

Проверка общего формата событий (CEF)

Требования к формату CEF

CEF использует syslog в качестве транспортного механизма со следующей структурой:

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

Пример:

Jan 18 11:07:53 host CEF:0|Vendor|Product|1.0|100|EventName|5|src=10.0.0.1 dst=10.0.0.2

Распространенные проблемы с форматированием CEF

Неправильный формат заголовка

  • Убедитесь, что версия CEF присутствует: CEF:0|
  • Все поля заголовка должны присутствовать и разделяться по символам (|)

Неправильное экранирование символов

  • Символы канала (|) в значениях заголовка должны быть экранированы: \|
  • Обратная косая черта () должна быть экранирована: \\
  • Знаки равенства (=) в расширениях должны быть экранированы: \=

Отсутствующие или несопоставленные значения

Чтобы найти полную спецификацию CEF, выполните поиск по документации по реализации общего формата событий ArcSight (CEF).

Дополнительные способы устранения неполадок

Включение трассировки диагностики

Предупреждение

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

  1. Измените файл конфигурации AMA:

    sudo vim /etc/default/azuremonitoragent

  2. Добавьте флаги трассировки в строку MDSD_OPTIONS:

    export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"

  3. Перезапустите агент:

    sudo systemctl restart azuremonitoragent

  4. Воспроизведите проблему и подождите несколько минут.

  5. Просмотрите сведения об отладке в /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Удалите флаг трассировки и перезапустите агент после устранения неполадок.

Мониторинг обработки журналов в режиме реального времени

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

tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Фильтрация по определенным типам журналов:

sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.* | grep -a "CEF"

Просмотрите журналы конкретных объектов:

grep local0.info /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Проверка успешной обработки журнала

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

Пример приема журналов ASA

Для журналов Cisco ASA успешная обработка отображается в журналах следующим образом:

2022-01-18T22:00:14.8650520Z: virtual bool Pipe::SyslogCiscoASAPipeStage::PreProcess(std::shared_ptr<CanonicalEntity>) (.../mdsd/PipeStages.cc +604) [PipeStage] Processing CiscoASA event '%ASA-1-105003: (Primary) Monitoring on 123'

2022-01-18T22:00:14.8651330Z: virtual void ODSUploader::execute(const MdsTime&) (.../mdsd/ODSUploader.cc +325) Uploading 1 SECURITY_CISCO_ASA_BLOB rows to ODS.

2022-01-18T22:00:14.8653090Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CISCO_ASA_BLOB. Payload: {"DataType":"SECURITY_CISCO_ASA_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:28:49.775619Z","HostIP":"127.0.0.1","Message":" (Primary) Monitoring on 123","ProcessId":"","Severity":"info","Host":"localhost","ident":"%ASA-1-105003"}]}. Uncompressed size: 443. Request size: 322

Ключевые показатели успешной обработки:

  • Событие распознается как событие CiscoASA.
  • Журнал передается в ODS (Operations Data Service)
  • Создается идентификатор запроса для отслеживания.
  • Полезные данные содержат правильно отформатированные данные JSON

Пример приема журналов CEF

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

2022-01-14T23:09:13.9087860Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CEF_BLOB. Payload: {"DataType":"SECURITY_CEF_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:08:49.731862Z","HostIP":"127.0.0.1","Message":"0|device1|PAN-OS|8.0.0|general|SYSTEM|3|rt=Nov 04 2018 07:15:46 GMTcs3Label=Virtual","ProcessId":"","Severity":"info","Host":"localhost","ident":"CEF"}]}. Uncompressed size: 482. Request size: 350

Ключевые показатели успешной обработки CEF:

  • Тип данных SECURITY_CEF_BLOB
  • Запрос на отправку включает допустимую конечную точку.
  • Структура сообщений CEF сохраняется в полезных данных
  • Метрики сжатия показывают, что данные оптимизированы для передачи

Важно!

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

Сбор диагностических сведений

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

Запуск средства устранения неполадок AMA

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

  • --cef: для журналов общего формата событий.
  • --asa: для журналов Cisco ASA
  • --ftd: для журналов Cisco Firepower Threat Defense

Выходные данные сохраняются в /tmp/troubleshooter_output_file.log.

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py && sudo python3 Sentinel_AMA_troubleshoot.py [--cef | --asa | --ftd]

Связанные материалы

  • Last updated on