📚 课程目录第2章审计日志标准与格式

审计日志标准与格式：常见审计日志格式

聊到审计日志，你最先想到的是什么？

我猜是那种满屏滚动的、看起来毫无头绪的文本字符串。嗯，一开始接触这玩意确实让人头疼。

但说白了，审计日志就是系统、应用、网络设备给你打的「小报告」。记录谁、在什么时间、在哪里、干了什么、结果如何。

不同的设备，习惯用不同的语言写报告。咱们得学会听懂它们的方言。

我个人习惯把常见的审计日志格式分为三大流派：

标准文本流 – 以 Syslog 为代表，老兵不死，只是逐渐凋零
结构化标记 – 以 JSON 为代表，现代 API 和云原生应用的标配
键值对与命名空间 – 以 CEF、LEEF 为代表，安全设备的老江湖

在我做过的项目里，经常是一个企业的 SIEM 里同时喂着三种格式。你得能一眼认出它们，不然解析规则写起来会非常痛苦。

Syslog 格式

Syslog 是互联网最古老的日志协议之一。说它老，但威力不减。Linux 服务器、网络交换机、防火墙，几乎都在用它。

Syslog 消息分为基于 RFC 3164 的「老式」和基于 RFC 5424 的「新式」。

特性	RFC 3164 (BSD Syslog)	RFC 5424 (新式)
时间戳	固定格式，无时区信息	ISO 8601，包含时区
主机名	可选，写法随意	必填，结构清晰
结构化数据	无	支持 [结构化数据块]
应用名称	混入 TAG 字段	独立字段 (APP-NAME)
消息体长度	限制较多	支持更长的消息

来个实际例子。这是我在现场抓到的一条老式 Syslog：

<134>Oct 5 10:15:30 192.168.1.1 sshd[2345]: Failed password for root from 10.0.0.5 port 22 ssh2

解读一下：<134> 是 PRI 值，通过计算可以知道设施和等级。之后是时间、主机名、进程名和消息体。

说实话，这种格式解析起来有点费劲。因为时间戳没有年份，主机名可能还是IP。我踩过这个坑——翻旧日志时，时间根本对不上。

JSON 格式

JSON 现在几乎是日志结构化的事实标准。为什么？因为机器解析起来太方便了。

每个字段名称和值都是自描述的。看看下面这段：

{
  "timestamp": "2024-10-05T10:15:30.123Z",
  "host": "app-server-01",
  "source": "nginx",
  "event_id": 1001,
  "action": "login_attempt",
  "user": "admin",
  "source_ip": "10.0.0.5",
  "result": "failure",
  "message": "Invalid credentials provided"
}

一眼就能看懂。不用去记哪个位置是什么字段。

而且 JSON 支持嵌套。你可以把上下文、子事件、原始请求都塞进去。比如一个 CloudTrail 日志，里面可能嵌套了好几层资源信息。

    我个人强烈建议：如果新上系统，尽量要求输出 JSON 格式的审计日志。它能让你的解析工作量减少一半以上。

CEF 格式 (Common Event Format)

CEF 是 ArcSight 推广开来的格式。现在很多安全设备（比如防火墙、WAF、DLP）都默认支持它。

CEF 是一个扩展的键值对格式。它的基本结构是：

CEF:版本|设备厂商|设备产品|设备版本|事件ID|事件名称|严重级别|扩展字段

来个真实的 CEF 日志看看：

CEF:0|PaloAlto|PAN-OS|10.1.0|4001|THREAT|5|src=10.0.1.100 dst=172.16.0.50 request=http://malware.com dhost=win-client-01 msg=Malware Detected cs1Label=Threat Category cs1=Trojan

你看，竖线之前是固定前缀（前缀字段），竖线之后是键值对格式的扩展字段。

好处在哪里？统一了事件头部的语义。不管你是什么设备，严重级别、事件名称都在固定位置。SIEM 能更快进行关联分析。

我在一个金融客户的环境里见过老旧的 CEF 日志，设备厂商字段写的是乱码。嗯，这就是运维欠下的债。建议大家在采集层就做一次数据清洗。

其他常见格式

除了上面这几种，还有一些格式你在实战中大概率会遇到：

LEEF (Log Event Extended Format) – IBM QRadar 的宠儿。结构类似 CEF，但分隔符是竖线和制表符。
W3C Extended Log Format – IIS 和部分反向代理服务器在用。头部定义了列名，每一行是一列数据。
Windows Event Log (EVTX) – Windows 的审计日志。虽然通过 API 读出来是 XML 结构，但在很多采集器里会被扁平化成 JSON 或 syslog 输出。
GELF (Graylog Extended Log Format) – Graylog 的主打格式。基于 JSON，但要求必须包含 version、host 和 short_message 字段。

我曾经因为没注意 GELF 的 mandatory 字段要求，导致一批日志被 Graylog 直接丢弃。所以一定要仔细阅读每种格式的规范文档，不要想当然。

看到这个图了吗？不管格式怎么变，核心就这三大类。你掌握了解析思路，剩下就是照着规范库写正则或者 JSON 提取器。

有些日志看起来很「自由」，比如思科的 ASA 设备，输出的是纯文本。但仔细看，它们内部依然遵循着固定的字段顺序。这种我一般先基于正则做提取，再映射成标准事件格式存储。

最后说一句：格式是很重要，但千万别过度解析。有些字段对你当前的环境可能没意义，就让它保持原始字符串状态。安全运维讲究的是够用，别追求理论上的完美。