Устранение неполадок CEF и Syslog через соединители 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
  • Запрос на загрузку включает корректный конечный URL-адрес.
  • Структура сообщения 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]