📚 课程目录第3章常见审计日志格式（Syslog, JSON, CEF等）

3. 常见审计日志格式：Syslog、JSON、CEF 等

审计日志格式这事，说大不大，说小不小。我早年接手过一个安全运维项目，接入了十几种设备，日志格式五花八门——有纯文本的，有键值对的，还有厂商自创的奇葩格式。那段时间我光是写解析器就写了一个月。说白了，格式不统一，后面的加密、查询、分析根本无从谈起。

所以这一章，咱们把市面上最常见的几种审计日志格式捋一遍。我挑三个最主流的讲：Syslog、JSON、CEF。你学会了，以后碰到其他格式也能快速上手。

3.1 Syslog 格式

Syslog 是日志界的老祖宗。80 年代就有了，现在仍然是网络设备、Linux 服务器的标配。它的核心思想很简单：一行文本，按固定顺序放几个字段。

3.1.1 标准格式拆解

一个典型的 Syslog 消息长这样：

<34>Oct 11 22:14:15 mymachine su: 'su root' failed for lonvick on /dev/pts/8

我来拆一下：

<34>：优先级（Priority），由设施代码（Facility）乘以8加上严重级别（Severity）算出。34 表示 Facility=4（auth），Severity=2（critical）。
Oct 11 22:14:15：时间戳，本地时间。
mymachine：主机名。
su：进程名。
'su root' failed for lonvick on /dev/pts/8：消息体。

我的一个小习惯：写解析器时，别直接用空格切分。时间戳里的空格和消息体里的引号会让你头疼。建议用正则或带偏移量的方式解析前几个固定字段，剩下的当消息体。

3.1.2 结构化 Syslog（RFC 5424）

传统 Syslog 缺乏结构，查询起来很痛苦。2009 年出了 RFC 5424，增加了结构化数据。格式变成：

<165>1 2003-10-11T22:14:15.003Z mymachine.example.com su 123ID - [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] BOM'su root' failed for lonvick on /dev/pts/8

看到了吗？多了版本号（1）、时间戳（带时区）、结构化数据段（方括号里）。这种方式对加密查询更友好——因为结构化字段可以直接映射到数据库列。

避坑指南：我曾经在一个集成项目中，设备声称支持 RFC 5424，实际发出来的日志版本号写的是“0”。后来查手册才知道，厂商把私有扩展塞进了保留字段。嗯，标准归标准，现实归现实。对接前最好先抓一段真实日志看看。

3.2 JSON 格式

JSON 日志现在几乎是现代应用的标准输出。原因很简单：可读性强，结构灵活，解析工具成熟。我做过统计，近五年新出的系统，80% 以上都用 JSON 输出审计日志。

3.2.1 典型结构

一个 JSON 审计日志条目大致长这样：

{
  "timestamp": "2025-03-21T08:45:30.123Z",
  "source": "api-gateway",
  "user": "zhangsan",
  "action": "DELETE",
  "resource": "/api/v2/users/10086",
  "status": 403,
  "message": "Attempt to delete admin account",
  "sessionId": "sess_abc123xyz"
}

每个字段含义清晰。而且 JSON 天生支持嵌套——比如可以把请求体和响应体塞进去。加密查询时，直接对 user 字段做哈希或加密，拿到密文也能快速定位。

3.2.2 JSON 日志的优劣

优势	劣势
人类可读，调试方便	体积大，传输带宽消耗高（比文本格式大 30%~50%）
Schema 灵活，字段可增可减	缺少强制校验，容易拼错字段名
解析性能好，主流语言都有库	数据量大时，全量解析内存开销高
配合 Logstash、Fluentd 等工具直接消费	不支持二进制，无法直接嵌入证书或加密块

我建议：生产环境用 JSON 时，一定要定义一个明确的最小字段集合。别让开发者随意加自定义字段，否则解析器会越来越臃肿。我们团队就用过一个 JSON Schema 校验层，不合格的直接丢弃并告警。

3.3 CEF 格式（Common Event Format）

CEF 是 ArcSight 搞出来的格式，后来成了很多 SIEM 产品的标准。它比 Syslog 结构化，又比 JSON 紧凑。我见过不少金融客户，成千上万台设备统一走 CEF，就是为了兼容已有 SIEM 平台。

3.3.1 基本语法

CEF 一行代表一个事件：

CEF:0|Security|Firewall|1.0|1001|Blocked Connection|5|src=10.0.0.1 dst=10.0.0.2 spt=12345 dpt=80 proto=tcp msg=Intrusion detected

我帮你拆解一下：

CEF:0：版本号，目前基本上是 0。
Security：设备厂商。
Firewall：设备产品名。
1.0：设备版本。
1001：事件 ID。
Blocked Connection：事件名称。
5：严重级别（0-10，5 表示中等）。
src=10.0.0.1 ...：扩展字段，key=value 对，用空格隔开。

3.3.2 关键设计特点

CEF 把事件拆成了两部分：

头部（Header）：从 CEF:0 到严重级别，共 7 个字段，位置固定，缺一不可。
扩展（Extension）：后面全是 key=value，支持动态字段。

这种设计的好处是：解析器可以快速跳过前面固定部分，直接定位到扩展字段做查询。比如你想查 src=10.0.0.1 的事件，不需要解析全部扩展，用字符串匹配就行。

注意：CEF 的扩展字段值如果包含空格，必须用反斜杠转义或整体加引号。我见过最坑的情况——某个防火墙把日志里的 IP 地址写成了“10.0.0.1 (trusted)”，没加转义，结果整条日志被解析成了两个字段。后来我在采集端加了一组预处理规则，专门处理这类奇葩。

3.4 三种格式对比

直接上表，你看完心里就有数了：

维度	Syslog	JSON	CEF
结构化程度	低（传统）/ 中（RFC 5424）	高	中高
解析速度	极快（按位置切）	中（需解析JSON树）	快（头部固定+扩展键值）
人类可读性	一般	好	一般
加密查询友好性	需要固定位置映射	最好（字段名清晰）	较好（扩展字段可哈希）
典型场景	网络设备、Linux	Web应用、微服务	SIEM、防火墙、IDS

核心结论：如果系统是从头搭建，我强烈推荐 JSON。加密、查询、压缩都有现成方案。如果必须对接老旧设备，Syslog 或 CEF 也能用，只是解析层要多写一些适配代码。

3.5 日志格式与加密查询的关系

你做审计日志加密查询，底层格式决定了你的加密粒度。我举个例子：

如果你用 Syslog，你只能对整条消息（msg）做加密，查询时全文匹配——慢且不灵活。
如果你用 JSON，可以对 user、ip、action 分别加密，查询时精准命中。
如果用了 CEF，你可以在扩展字段级别做加密，至少能按设备维度做索引。

想想看，如果你的审计系统每天接收上亿条日志，加密粒度和查询性能的取舍就变得非常实际了。我带的项目里，我们会先做一次格式标准化——把不同来源的日志统一转成一种结构化格式，然后再上加密。标准化的成本总是值得的。