Compartir a través de

通过 AMA 连接器排查 CEF 和 Syslog 问题

本文提供有关在 Microsoft Sentinel 中使用 Azure Monitor 代理（AMA）收集通用事件格式（CEF）和 Syslog 数据收集的故障排除指南。 使用本指南诊断和解决日志转发器计算机的引入问题。 应在安装了 AMA 和 RSyslog/Syslog-ng 的日志转发器计算机上运行命令和配置。

在开始故障排除之前，请熟悉以下文章：

体系结构概述

下图演示了从日志源到通过 RSyslog 和 Azure Monitor 代理Microsoft Sentinel/log Analytics 工作区的数据流。

显示通过 RSyslog 和 AMA 从源流到 Log Analytics 的数据流的关系图。

关键组件：

  • RSyslog/Syslog-ng：接收端口 514 上的日志并将其转发到 AMA
  • Azure Monitor 代理：根据数据收集规则处理日志（DCR）
  • 数据收集规则：定义要收集和发送日志的位置

初始验证步骤

验证是否收到日志

配置后，日志最多可能需要 20 分钟才会显示在 Microsoft Sentinel 中。

  1. 运行 tcpdump 验证日志是否到达转发器：

    sudo tcpdump -i any port 514 -A -vv

  2. 验证日志源是否已配置为将消息发送到正确的转发器 IP 地址。

  3. 检查可能影响连接的基础结构组件：

    • Firewalls
    • 负载均衡器
    • 网络安全组

检查 Azure Monitor 代理扩展状态

  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

输出应显示包含 DCR 配置的 JSON 字符串。

查看防火墙规则

确保防火墙规则允许在两者之间进行通信：

  • 日志源和 RSyslog （端口 514）
  • RSyslog 和 AMA （端口 28330）
  • AMA 和 Azure 终结点

数据收集规则配置

启用所有设施进行故障排除

对于初始故障排除：

  1. 在 Azure 门户中，导航到数据收集规则。
  2. 启用所有 syslog 设施。
  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.cn 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）
  • 生成用于跟踪的请求 ID
  • 载荷包含格式正确的 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.cn 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 威胁防御日志的相关内容

输出保存到 /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