📚 课程目录第3章安全数据采集与接入

3. 安全数据采集与接入

Beats 是 Elastic 生态中一组轻量级数据采集器，部署在被观测对象附近，负责把原始事件转换为带统一字段的 JSON 文档并送入 Elasticsearch 或 Logstash。理解 Beats 的关键不在于“装一个采集器”，而在于三件事：采集对象是什么、原始数据长什么样、字段如何映射到 ECS（Elastic Common Schema）。本节围绕 Filebeat、Winlogbeat、Auditbeat、Packetbeat 四类采集器，说明它们在终端、网络、审计场景中的配置要点与字段映射逻辑。

一、四类 Beats 的定位与数据来源

Filebeat 面向文件型日志，通过 prospector/input 跟踪文件偏移量，适合应用日志、Web 访问日志、系统文本日志。Winlogbeat 面向 Windows 事件日志，直接读取 Event Log 通道（如 Security、System、Application、Sysmon），天然带 EventID、Provider、Channel 等结构化字段。Auditbeat 面向主机审计与完整性，包含 auditd 模块（Linux 系统调用审计）、file_integrity 模块（文件哈希变化）和 system 模块（进程、登录、套接字等周期性指标）。Packetbeat 面向网络流量，通过抓包解析应用层协议（HTTP、DNS、TLS、MySQL 等），输出事务级记录而非原始报文。

四者的共同点是：都输出 JSON 事件，都支持 processors 做字段加工，都建议开启 ECS 兼容模式。差异在于数据源形态——文件是字节流，Windows 事件是结构化记录，审计是内核事件，网络是协议事务。这决定了它们的配置项和字段映射方式完全不同。

二、Filebeat：文件日志的偏移跟踪与多行合并

Filebeat 的核心配置是 input 与 output。以采集 Nginx 访问日志为例，典型配置如下：

filebeat.inputs:
- type: filestream
  id: nginx-access
  paths:
    - /var/log/nginx/access.log
  fields:
    event.dataset: nginx.access
  fields_under_root: true
  parsers:
    - ndjson:
        target: ""
        overwrite_keys: true

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

output.elasticsearch:
  hosts: ["https://es-node1:9200"]
  username: "beats_writer"
  password: "${ES_PWD}"
  index: "beats-%{[event.dataset]}-%{+yyyy.MM.dd}"

这里有两个关键点。第一，filestream 使用 id 作为状态标识，偏移量记录在 registry 中，重启后不会重复采集；若同一文件被多个 input 匹配，需用 id 区分。第二，fields_under_root: true 让自定义字段直接落在文档根层，而不是嵌套在 fields 下，这样 event.dataset 才能被索引模板正确识别。

对于 Java 异常栈这类多行日志，必须配置多行合并，否则一条异常会被拆成几十条事件：

parsers:
  - multiline:
      type: pattern
      pattern: '^\d{4}-\d{2}-\d{2}'
      negate: true
      match: after
      max_lines: 500

含义是：不以日期开头的行，追加到上一行之后。判断合并是否生效，可在 Kibana 中查看单条文档的 message 是否包含完整堆栈，并观察 log.flags 是否出现 multiline。

三、Winlogbeat：EventID 与 ECS 的双向映射

Winlogbeat 的配置重点是选择事件通道和按 EventID 过滤。安全分析最常用的是 Security 通道，其中 4624（登录成功）、4625（登录失败）、4688（进程创建）、4720（创建用户）是高频关注对象。示例：

winlogbeat.event_logs:
  - name: Security
    event_id: 4624, 4625, 4688, 4720
    ignore_older: 72h
  - name: Microsoft-Windows-Sysmon/Operational
    event_id: 1, 3, 11, 22

processors:
  - drop_event.when.equals.winlog.event_id: 4634
  - add_fields:
      target: event
      fields:
        dataset: windows.security

字段映射上，Winlogbeat 会把原始 EventData 展开为 winlog.event_data.*，同时把常用字段提升到 ECS 位置：event.code 对应 EventID，user.name 对应目标账户，source.ip 对应登录源地址，process.name 对应进程名。需要注意，4624 的登录类型（LogonType）在 winlog.event_data.LogonType 中，值为 3 表示网络登录、10 表示远程桌面，检测规则常以此区分横向移动。

若发现 user.name 为空，通常是事件中只有 SubjectUserName 而无 TargetUserName，应在 processor 中用 rename 或 copy_fields 显式映射，而不是依赖默认行为。

四、Auditbeat：系统调用与文件完整性

Auditbeat 的 auditd 模块依赖 Linux audit 框架，配置分为规则与采集两部分。例如监控敏感文件写入：

- module: auditd
  audit_rules: |
    -w /etc/passwd -p wa -k identity_change
    -w /etc/sudoers -p wa -k privilege_change
    -a always,exit -F arch=b64 -S execve -k process_exec

采集到的事件中，auditd.syscall 表示系统调用名，auditd.key 对应规则中的 -k 标签，process.name 与 process.args 记录执行程序及参数，user.name 记录触发用户。file_integrity 模块则周期性计算文件哈希，输出 file.path、file.hash.sha256、event.action（created/updated/deleted）。判断完整性告警是否可信，应比对 file.hash.sha256 与基线值，而不是只看文件被修改这一事实。

五、Packetbeat：协议事务与网络字段

Packetbeat 需要指定网卡和协议端口。示例：

packetbeat.interfaces.device: eth0
packetbeat.flows:
  timeout: 30s
  period: 10s
packetbeat.protocols:
  - type: http
    ports: [80, 8080]
  - type: dns
    ports: [53]
  - type: tls
    ports: [443]

输出字段中，network.protocol 标识协议，source.ip/destination.ip 与端口构成五元组，http.request.method、http.response.status_code、dns.question.name、tls.client.server_name 是检测规则最常引用的字段。Packetbeat 默认不解析报文载荷内容，只输出事务摘要，因此适合做流量画像和异常连接发现，不适合做完整内容审计。

六、接入后的字段验证清单

Beats 接入完成后，不能只看“有没有数据”，而要验证字段是否可用。建议按以下顺序检查：

在 Kibana Discover 中确认 @timestamp 为事件时间而非采集时间，避免时区错位。
确认 event.dataset 与索引名一致，便于按来源检索与设置生命周期策略。
检查关键字段类型：source.ip 应为 ip 类型，event.code 应为 keyword，否则聚合与过滤会异常。
用 GET beats-*/_mapping 查看实际映射，确认没有字段被动态映射成 text 导致无法精确匹配。
对多行日志，抽查单条文档的 message 是否完整；对 Windows 事件，抽查 winlog.event_data 是否包含预期键。

只有字段映射正确，后续的检测规则、关联分析和可视化才有可靠基础。Beats 的配置量不大，但字段层面的偏差往往在检测阶段才暴露，因此接入阶段就应把映射验证作为交付标准。