4. 日志采集与标准化：Syslog、Windows Event Log、JSON 格式

日志是安全运营的「原材料」。这句话我反复跟团队讲。你想想看，如果原材料质量不行，后面再好的分析引擎也白搭。过了这么些年，我越来越确定一件事：与其把精力都花在搞复杂的检测规则上，不如先把日志采集和标准化夯实了。

4.1 为什么标准化这么重要

说白了，安全日志的「方言」太多了。防火墙的日志格式跟操作系统不一样，应用系统的日志又自成一派。我早年在某金融客户现场做项目，他们接了36种不同设备，日志格式五花八门。有的用竖线分隔，有的用逗号，有的干脆是自由文本。结果一个简单的暴力破解检测，要写6套不同的解析规则。这就是典型的「采集一时爽，分析火葬场」。

标准化的核心目标就三个：

• 统一字段：不管来源是什么，关键字段（时间、源IP、目的IP、事件类型等）都用同样的名字和格式
• 统一编码：所有日志都转成 UTF-8，避免中文乱码
• 统一时间：全部使用 UTC+8 或者 UTC 0，带时区信息

4.2 Syslog：最通用的日志运输协议

Syslog 是 Unix/Linux 世界的标准日志协议。实际上它已经变成了整个安全设备界的通用语言。我见过的大多数网络设备、安全设备都支持 Syslog 输出。

Syslog 的标准格式由两部分组成：

<优先级>时间戳 主机名 进程[进程ID]: 消息内容

举个例子：

<134>Oct 11 10:15:30 fw-01 sshd[12345]: Failed password for root from 10.0.0.5 port 22

这里 <134> 是优先级，它其实是设施代码和严重级别的组合值。计算方式我一般不让人记，但有个关键点你得分清：

严重级别	代码	说明
Emergency	0	系统不可用
Alert	1	需要立即处理
Critical	2	严重状态
Error	3	错误
Warning	4	警告
Notice	5	正常但重要
Info	6	信息
Debug	7	调试

实际案例：我在攻防演练时遇到过一台防火墙，它把所有的日志都标成了 Informational（级别6）。这就导致我们的告警阈值怎么调都不准，因为无法按严重级别做筛选。排查了半天才发现是配置问题。

Syslog 采集的常见问题

• UDP 丢包：默认用 UDP 514 端口，网络抖动时日志就丢了。我建议关键设备改用 TCP 或者 RELP
• 消息截断：老版本 Syslog 限 1024 字节。遇到大日志直接截断，信息不完整。我遇到过一个奇葩案例，日志最后被截断在「password: 」，导致找不到具体账户名
• 时间不准：设备系统时间如果不做 NTP 同步，日志时间戳就是错的。猎杀的时候你根本没法关联

4.3 Windows Event Log：微软世界的日志体系

Windows 的日志体系比 Syslog 复杂得多。它不只是一个文件，而是一个完整的日志服务（EventLog）。

Windows 日志主要分布在三个日志文件中：

• System：系统级别事件，驱动、服务启停
• Security：安全审计事件，登录、权限、策略
• Application：应用程序日志

每一个事件都有一个唯一的 Event ID。威胁狩猎时，你会频繁遇到这些 ID：

Event ID	说明	典型场景
4624	登录成功	正常登录 / 横向移动后登录
4625	登录失败	暴力破解
4688	进程创建	执行可疑程序
7045	服务安装	后门持久化
5156	网络连接	C2 通信检测
1102	安全日志清除	攻击者清理痕迹

Windows Event Log 的标准化难点在于，它原生是 XML 结构。你如果直接转成文本，字段会丢失。我推荐的做法是使用 Windows Event Collector（WEC）或者第三方 Agent，把 XML 结构完整保留，再按统一 Schema 解析。

举一个实际的例子，一个 4624 登录事件的原始内容片段：

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <EventID>4624</EventID>
    <TimeCreated SystemTime="2024-03-15T08:23:45.123Z"/>
  </System>
  <EventData>
    <Data Name="TargetUserName">Administrator</Data>
    <Data Name="IpAddress">192.168.1.100</Data>
    <Data Name="LogonType">3</Data>
  </EventData>
</Event>

标准化后，你应该提取成：

{
  "event_id": 4624,
  "timestamp": "2024-03-15T08:23:45.123Z",
  "user": "Administrator",
  "src_ip": "192.168.1.100",
  "logon_type": 3
}

4.4 JSON：我推荐的标准格式

把 Syslog 和 Windows Event Log 都标准化成 JSON，是目前业界公认的最佳实践。原因很简单：JSON 是结构化数据，机器解析方便，字段扩展灵活。我接手过的所有 SIEM 平台，最终都会把日志转成 JSON 存储。

一个标准化的 JSON 日志字段设计可以参考下面：

{
  "source": "firewall-01",       // 来源设备
  "timestamp": "2024-11-11T14:30:00.000Z",  // 统一时间格式
  "event_type": "auth_failed",   // 事件类型
  "severity": "high",            // 严重程度
  "src_ip": "10.0.0.5",         // 源IP
  "dst_ip": "10.0.0.1",         // 目的IP
  "user": "root",               // 用户
  "message": "Failed password for root from 10.0.0.5 port 22",
  "raw_log": "<134>Nov 11 14:30:00 fw-01 sshd[12345]: Failed password..."
}

这里有几个标准化的要点：

• timestamp 统一用 ISO 8601：包括时区信息，避免不同系统之间的时间歧义
• severity 统一用枚举：critical、high、medium、low、info。不要混合使用数字和文字
• 保留 raw_log：标准化后的字段虽然便于分析，但原始日志在某些取证场景下仍有价值。我一般会保留 raw_log 字段
• event_type 做分类：用英文短词让事件可自动分类，比如 auth_failed、file_create、process_start 等

4.5 本章知识体系结构

下面这张图概括了日志采集与标准化的完整链路：

这张图清晰地展示了从日志源到标准化输出的完整链路。日志从不同来源采集后，分别经过 Syslog 协议、Windows Event Log 原生格式或者直接输出 JSON。每一类都有各自的特点和风险点。最终所有日志都归一到 JSON 标准格式，统一了字段命名、时间格式和严重级别，为后续的威胁狩猎和告警分析打下基础。

4.6 实操要点

我整理了几个你在搭建日志采集系统时一定会用到的检查点：

1. 先摸底：梳理所有日志源，明确日志格式、传输协议、数据量级
2. 定 Schema：编写统一的字段映射表，定义必须字段和可选字段
3. 验证时间：观察连续几天的日志，确认所有设备时间一致，没有偏移
4. 小流量试点：先用少量设备跑通链路，观察日志是否完整、字段是否正常
5. 建立基准：运行一周了解正常基线，然后设置异常告警（比如某个设备突然不发了）