收集 Infoblox DNS 日志

支持的平台：

Google SecOps SIEM

本文档介绍了如何使用 Bindplane 将 Infoblox DNS 日志注入到 Google Security Operations。

解析器从 Infoblox DNS SYSLOG 和 CEF 格式的日志中提取字段。它使用 grok 和/或 kv 来解析日志消息，然后将这些值映射到统一数据模型 (UDM)。它还会为事件来源和类型设置默认元数据值。

准备工作

请确保满足以下前提条件：

Google SecOps 实例
Windows Server 2016 或更高版本，或者具有 systemd 的 Linux 主机
如果通过代理运行，请确保防火墙端口已根据 Bindplane 代理要求打开
对 Infoblox Grid Manager 网页界面的特权访问权限

获取 Google SecOps 注入身份验证文件

登录 Google SecOps 控制台。
依次前往 SIEM 设置 > 收集代理。
下载注入身份验证文件。将文件安全地保存在将要安装 Bindplane 的系统上。

获取 Google SecOps 客户 ID

登录 Google SecOps 控制台。
依次前往 SIEM 设置 > 配置文件。
复制并保存组织详细信息部分中的客户 ID。

安装 Bindplane 代理

按照以下说明在 Windows 或 Linux 操作系统上安装 Bindplane 代理。

Windows 安装

以管理员身份打开命令提示符或 PowerShell。

运行以下命令：

msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet

等待安装完成。
运行以下命令来验证安装：
```
sc query observiq-otel-collector
```

该服务应显示为 RUNNING。

Linux 安装

打开具有 root 或 sudo 权限的终端。

运行以下命令：

sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh

等待安装完成。

运行以下命令来验证安装：

sudo systemctl status observiq-otel-collector

该服务应显示为有效（正在运行）。

其他安装资源

如需了解其他安装选项和问题排查信息，请参阅 Bindplane 代理安装指南。

配置 Bindplane 代理以注入 syslog 并将其发送到 Google SecOps

找到配置文件

Linux：

sudo nano /etc/bindplane-agent/config.yaml

Windows：

notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"

修改配置文件

将 config.yaml 的全部内容替换为以下配置：

receivers:
    udplog:
        listen_address: "0.0.0.0:514"

exporters:
    chronicle/chronicle_w_labels:
        compression: gzip
        creds_file_path: '/path/to/ingestion-authentication-file.json'
        customer_id: 'YOUR_CUSTOMER_ID'
        endpoint: malachiteingestion-pa.googleapis.com
        log_type: 'INFOBLOX_DNS'
        raw_log_field: body
        ingestion_labels:

service:
    pipelines:
        logs/source0__chronicle_w_labels-0:
            receivers:
                - udplog
            exporters:
                - chronicle/chronicle_w_labels

配置参数

替换以下占位符：
- 接收器配置：
  - udplog：使用 udplog 表示 UDP syslog，使用 tcplog 表示 TCP syslog
  - 0.0.0.0：要监听的 IP 地址（0.0.0.0 表示监听所有接口）
  - 514：要监听的端口号（标准 syslog 端口）
- 导出器配置：
  - creds_file_path：提取身份验证文件的完整路径：
    - Linux：/etc/bindplane-agent/ingestion-auth.json
    - Windows：C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json
  - YOUR_CUSTOMER_ID：从“获取客户 ID”部分获取的客户 ID
  - endpoint：区域端点网址：
    - 美国：malachiteingestion-pa.googleapis.com
    - 欧洲：europe-malachiteingestion-pa.googleapis.com
    - 亚洲：asia-southeast1-malachiteingestion-pa.googleapis.com
    - 如需查看完整列表，请参阅区域级端点
  - log_type：日志类型，与在 Chronicle 中显示的完全一致 (INFOBLOX_DNS)

保存配置文件

修改后，保存文件：
- Linux：依次按 Ctrl+O、Enter 和 Ctrl+X
- Windows：依次点击文件 > 保存

重启 Bindplane 代理以应用更改

如需在 Linux 中重启 Bindplane 代理，请运行以下命令：

sudo systemctl restart observiq-otel-collector

验证服务是否正在运行：

  sudo systemctl status observiq-otel-collector

检查日志是否存在错误：

  sudo journalctl -u observiq-otel-collector -f

如需在 Windows 中重启 Bindplane 代理，请选择以下选项之一：
- 以管理员身份运行命令提示符或 PowerShell：
```
net stop observiq-otel-collector && net start observiq-otel-collector
```
- 服务控制台：
  1. 按 Win+R，输入 services.msc，然后按 Enter 键。
  2. 找到 observIQ OpenTelemetry 收集器。
  3. 右键点击并选择重新启动。
  4. 验证服务是否正在运行：
```
sc query observiq-otel-collector
```
  5. 检查日志是否存在错误：
```
type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
```

在 Infoblox DNS 上配置 Syslog 转发

登录 Infoblox Grid Manager 网页界面。
依次前往网格 > 网格管理器 > 成员。
选择要配置的成员，然后点击修改。
转到监控标签页。
在 Syslog 下，点击添加以添加新的 Syslog 服务器。
提供以下配置详细信息：
- 地址：输入 Bindplane 代理主机 IP 地址。
- 端口：输入 514。
- 传输：选择 UDP。
- 节点 ID：选择 Infoblox 节点（对于 HA 对）。
- 严重程度：选择信息（或您偏好的严重程度）。
- 设备：选择 local0（或您偏好的设备）。
启用以下日志类别：
- DNS 查询：在 Grid DNS 属性 > 日志记录下，选择记录 DNS 查询。
- DNS 响应：选择 Log DNS Responses（记录 DNS 响应）。
- DHCP：在网格 DHCP 属性下启用 DHCP 日志记录。
- 审核：在网格属性 > 监控下启用审核日志记录。
点击保存并关闭。
如有必要，请重启 DNS 服务。
通过检查 Bindplane 代理日志，验证是否正在发送 syslog 消息。

UDM 映射表

日志字段	UDM 映射	逻辑
agent.hostname	principal.hostname	对于 CEF 格式的日志，如果存在 agent.hostname，则会将其映射到 principal.hostname。
client_ip	principal.ip	对于 CEF 格式的日志，如果存在 client_ip，则会映射到 principal.ip。
client_port	principal.port	对于 CEF 格式的日志，如果存在 client_port，则会将其映射到 principal.port。
数据	answers.data	从原始日志的“answers”部分中的“data”字段提取。多次出现的情况会映射为单独的解答对象。
说明	metadata.description	直接从原始日志的说明字段映射，或使用 grok 模式从其他字段（例如 message 和 msg2）提取。
dest_ip1	target.ip	从原始日志中提取并映射到 target.ip。
destinationDnsDomain	dns_question.name	对于 CEF 格式的日志，如果 destinationDnsDomain 存在，则会映射到 dns_question.name。
dns_class	dns_question.class	使用 dns_query_class_mapping.include 查找表进行映射。
dns_domain	dns_question.name	使用 Grok 模式从原始日志的消息字段中提取，并映射到 dns_question.name。
dns_name	dns_question.name	使用 grok 模式从 dns_domain 字段中提取，并映射到 dns_question.name。
dns_records	answers.data	对于 CEF 格式的日志，如果存在 dns_records，则会将其映射到 answers.data。多次出现的情况会映射为单独的解答对象。
dst_ip	target.ip 或 target.hostname	使用 Grok 模式从原始日志的消息字段中提取。如果它是有效的 IP 地址，则会映射到 target.ip；否则，会映射到 target.hostname。
dst_ip1	target.ip 或 target.hostname	使用 Grok 模式从原始日志的消息或 msg2 字段中提取。如果它是有效的 IP 地址，则会映射到 target.ip；否则，会映射到 target.hostname。仅当与 dst_ip 不同时才进行映射。
evt_type	metadata.product_event_type	直接从原始日志的 evt_type 字段映射，该字段使用 grok 模式从消息字段中提取。
InfobloxB1OPHIPAddress	principal.ip	对于 CEF 格式的日志，如果 InfobloxB1OPHIPAddress 存在，则会映射到 principal.ip。
InfobloxB1Region	principal.location.country_or_region	对于 CEF 格式的日志，如果存在 InfobloxB1Region，则会将其映射到 principal.location.country_or_region。
InfobloxDNSQType	dns_question.type	对于 CEF 格式的日志，如果存在 InfobloxDNSQType，则会将其映射到 dns_question.type。
中介	intermediary.ip 或 intermediary.hostname	使用 Grok 模式从原始日志的消息字段中提取。如果它是有效的 IP 地址，则会映射到 intermediary.ip；否则，会映射到 intermediary.hostname。
msg2	metadata.description、dns.response_code、dns_question.name、target.ip、target.hostname、answers.name、answers.ttl、answers.data、answers.class、answers.type、security_result.severity	使用 Grok 模式从原始日志的消息字段中提取。用于提取各种字段，但不会直接映射到 UDM。
name1	answers.name	使用 grok 模式从原始日志的 msg2 字段中提取，并映射到 answers.name。
name2	answers.name	使用 grok 模式从原始日志的 msg2 字段中提取，并映射到 answers.name。
协议	network.ip_protocol	如果与已知协议匹配，则直接从原始日志的协议字段映射。
qclass	dns_question.class	用于将 dns_class 映射到 UDM 的中间字段。
qclass1	answers.class	用于将 dns_class1 映射到 UDM 的中间字段。
qclass2	answers.class	用于将 dns_class2 映射到 UDM 的中间字段。
query_type	dns_question.type	使用 dns_record_type.include 查找表进行映射。
query_type1	answers.type	使用 dns_record_type.include 查找表进行映射。
query_type2	answers.type	使用 dns_record_type.include 查找表进行映射。
recursion_flag	network.dns.recursion_desired	如果 recursion_flag 包含“+”，则将其映射到 network.dns.recursion_desired，值为 true。
record_type	dns_question.type	用于将 query_type 映射到 UDM 的中间字段。
record_type1	answers.type	用于将 query_type1 映射到 UDM 的中间字段。
record_type2	answers.type	用于将 query_type2 映射到 UDM 的中间字段。
res_code	network.dns.response_code	使用 dns_response_code.include 查找表进行映射。
response_code	network.dns.response_code	对于 CEF 格式的日志，如果存在 response_code，则使用 dns_response_code.include 查找表将其映射到 network.dns.response_code。
security_action	security_result.action	派生自状态字段。如果状态为“denied”，则将 security_action 设置为“BLOCK”；否则，将其设置为“ALLOW”。
和程度上减少	security_result.severity	对于 CEF 格式的日志，如果存在严重程度且为“信息性”，则会将其映射到 security_result.severity 为“INFORMATIONAL”。
src_host	principal.hostname	使用 grok 模式从原始日志的说明或消息字段中提取，并映射到 principal.hostname。
src_ip	principal.ip 或 principal.hostname	使用 Grok 模式从原始日志的消息字段中提取。如果它是有效的 IP 地址，则会映射到 principal.ip；否则，会映射到 principal.hostname。
src_port	principal.port	使用 Grok 模式从原始日志的消息字段中提取，并映射到 principal.port。
ttl1	answers.ttl	使用 Grok 模式从原始日志的 msg2 字段中提取，并映射到 answers.ttl。
ttl2	answers.ttl	使用 Grok 模式从原始日志的 msg2 字段中提取，并映射到 answers.ttl。
metadata.event_type	metadata.event_type	派生自各种字段和解析器逻辑。如果未识别出其他事件类型，则默认为 GENERIC_EVENT。可能的值包括 NETWORK_DNS、NETWORK_CONNECTION 和 STATUS_UPDATE。
metadata.log_type	metadata.log_type	由解析器设置为“INFOBLOX_DNS”。
metadata.product_name	metadata.product_name	由解析器设置为“Infoblox DNS”。
metadata.vendor_name	metadata.vendor_name	由解析器设置为“INFOBLOX”。
metadata.product_version	metadata.product_version	从 CEF 消息中提取。
metadata.event_timestamp	metadata.event_timestamp	从时间戳字段复制。
network.application_protocol	network.application_protocol	如果 event_type 不是“GENERIC_EVENT”或“STATUS_UPDATE”，则设置为“DNS”。