Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье содержатся рекомендации по устранению неполадок при сборе данных common Event Format (CEF) и системного журнала с помощью агента Azure Monitor Agent (AMA) в Microsoft Sentinel. Используйте это руководство для диагностики и устранения проблем с приемом на компьютерах сервера пересылки журналов. Команды и конфигурации должны выполняться на компьютерах переадресации журналов, на которых установлены AMA и RSyslog/Syslog-ng.
Прежде чем приступить к устранению неполадок, ознакомьтесь со следующими статьями:
- Прием сообщений системного журнала и CEF для Microsoft Sentinel с помощью агента мониторинга Azure
- CEF через соединитель данных AMA — настройка конкретного аппаратного или другого устройства
- Общие сведения об агенте мониторинга Azure
Обзор архитектуры
На следующей схеме показан поток данных из источников журналов в рабочие области Microsoft Sentinel/log analytics через RSyslog и агент мониторинга Azure.
Ключевые компоненты:
- RSyslog/Syslog-ng: получает журналы через порт 514 и пересылает их в AMA.
- Агент мониторинга Azure: обрабатывает журналы в соответствии с правилами сбора данных (DCR)
- Правило сбора данных: определяет, какие журналы собирать и куда их отправлять.
Начальные шаги проверки
Проверьте, что логи поступают
После настройки журналы могут появиться в Microsoft Sentinel в течение 20 минут.
Запустите tcpdump, чтобы убедиться, что журналы поступают в сервер пересылки:
sudo tcpdump -i any port 514 -A -vvУбедитесь, что источник журнала настроен для отправки сообщений на правильный IP-адрес сервера пересылки.
Проверьте наличие компонентов инфраструктуры, которые могут повлиять на подключение:
- Брандмауэры
- Подсистемы балансировки нагрузки
- Группы безопасности сети
Проверка состояния расширения агента мониторинга Azure
- На портале Azure перейдите к виртуальной машине для пересылки журналов.
- Выберите Расширения и приложения.
- Выберите расширение AzureMonitorLinuxAgent .
- Убедитесь, что состояние показывает, что подготовка выполнена успешно.
Проверка версии агента
- На панели расширения AzureMonitorLinuxAgent проверьте поле Версия.
- Убедитесь, что версия относится к числу 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/.
Проверьте конфигурацию порта:
grep -E 'imudp|imtcp' /etc/rsyslog.confОжидаемые выходные данные:
module(load="imudp") input(type="imudp" port="514") module(load="imtcp") input(type="imtcp" port="514")Убедитесь, что конфигурация переадресации 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
Настройка правила сбора данных
Включение всех средств для устранения неполадок
Для первоначального устранения неполадок:
- В портале Azure перейдите к вашему правилу сбора данных.
- Включите все средства системного журнала.
- Выберите все уровни журнала.
- Если доступно, включите сбор сообщений без объекта или уровня важности.
Дополнительные сведения см. в разделе Выбор объектов и уровней серьезности.
Проверка общего формата событий (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| - Все поля заголовка должны присутствовать и быть разделены символом вертикальной черты (|)
Неправильное экранирование символов
- Символы вертикальной черты (|) в значениях заголовков должны быть экранированы:
\| - Обратные косые черты () должны быть экранированы:
\\ - Знаки равенства (=) в расширениях должны быть экранированы:
\=
Отсутствующие или несопоставленные значения
- Если значение не удается сопоставить со стандартным полем, оно сохраняется в столбце
AdditionalExtensions - Сопоставление полей CEF и CommonSecurityLog см. в статье Сопоставление полей CEF и CommonSecurityLog .
Чтобы найти полную спецификацию CEF, выполните поиск по документации по реализации общего формата событий ArcSight (CEF).
Дополнительные способы устранения неполадок
Включить трассировку диагностики
Предупреждение
Включите флаги трассировки только для сеансов устранения неполадок. Флаги трассировки генерируют большой объём журналов, из-за чего место на диске может быстро закончиться.
Измените файл конфигурации AMA:
sudo vim /etc/default/azuremonitoragentДобавьте флаги трассировки в строку 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"Перезапустите агент:
sudo systemctl restart azuremonitoragentВоспроизведите проблему и подождите несколько минут.
Просмотрите сведения об отладке в
/var/opt/microsoft/azuremonitoragent/log/mdsd.info.Удалите флаг трассировки и перезапустите агент после устранения неполадок.
Мониторинг обработки журналов в режиме реального времени
Просматривайте входящие журналы по мере их обработки:
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]