审计日志基础：日志格式、标准（syslog、CEF）
聊审计日志，第一个绕不开的问题就是——日志长什么样？
我早年刚接触DLP合规项目时，接过一个客户的原始日志，那叫一个放飞自我：字段顺序全靠心情，时间戳有的用2024-01-15，有的用01/15/2024 3:20PM。我当时就一个念头：这要是让合规审计的人来查，我估计得加班到退休。
后来我慢慢明白，日志格式不统一，检索、归档、溯源全得乱套。所以这一节，咱们把两个最主流的日志标准掰开揉碎讲清楚：syslog 和 CEF。
syslog：最通用的“老大哥”
syslog 是 Unix/Linux 世界的原生日志协议，诞生于 80 年代。虽然年纪大，但至今仍是网络设备、服务器、安全设备最主流的输出格式。
两个主要版本
- RFC 3164（传统 syslog）：没有严格的结构，靠空格和标点分隔。常见于老系统、部分嵌入式设备。
- RFC 5424（结构化 syslog）：2009 年推出，增加了结构化数据字段，解析更友好。新硬件和软件基本都支持。
RFC 3164 示例
<14>Jan 15 10:45:33 fw01 sshd[12345]: Failed password for root from 10.0.0.100 port 22 ssh2你看，这部分主要包括：优先级（<14>）、时间戳、主机名、进程名/PID、消息体。说白了，用人眼读还行，机器解析就有点费劲。
RFC 5424 示例
<14>1 2024-01-15T10:45:33.000Z fw01 sshd 12345 - - [meta sequenceId="1"][origin ip="10.0.0.1"] Failed password for root from 10.0.0.100我觉得 RFC 5424 最大的改进是引入了 结构化数据（SD-ELEMENT），用方括号括起来，键值对清清楚楚。这样日志分析工具就能直接提取字段，省去一堆正则。
CEF：安全设备的“专用语言”
CEF（Common Event Format）是 ArcSight 公司提出的，专门给安全日志用的。它不像 syslog 那么通用，但在 SIEM 领域用得非常多。
我做过一个项目，客户要求所有安全设备必须输出 CEF 格式。当时防火墙、IDS、终端防护都得改配置，折腾了一周。但改完之后，日志解析的成功率直接从 70% 飙到 99%，太值了。
CEF 的结构
一条 CEF 日志长这样：
CEF:0|Security|Firewall|1.0|100|Login Failed|5|src=10.0.0.100 dst=10.0.0.1 dhost=app01 msg=Failed password for root拆开看，它用竖线 | 分隔固定字段，后面跟着键值对扩展字段：
| 位置 | 含义 | 例子 |
|---|---|---|
| 1 | CEF 版本 | 0 |
| 2 | 设备厂商 | Security |
| 3 | 设备产品 | Firewall |
| 4 | 设备版本 | 1.0 |
| 5 | 事件 ID | 100 |
| 6 | 事件名称 | Login Failed |
| 7 | 严重级别（0-10） | 5 |
| 8+ | 键值对扩展 | src=10.0.0.100 |
嗯，这里要注意：CEF 的严重级别是 0 最低、10 最高，跟 syslog 的优先级相反。我曾经在这个坑上栽过跟头，写告警阈值的时候写反了，导致一天收到几千条低级告警……后来加了个映射表才搞定。
syslog 与 CEF 对比
你想想看，既然两个都能用，该选哪个？我习惯用一张表来对比：
| 维度 | syslog | CEF |
|---|---|---|
| 标准化程度 | RFC 5424 是国际标准 | 事实标准，ArcSight 主导 |
| 解析复杂度 | RFC 3164 要正则，RFC 5424 较简单 | 固定字段 + 键值对，解析清晰 |
| 扩展性 | 结构化数据用 SD-ELEMENT | 键值对扩展，无数量限制 |
| 适用场景 | 服务器、网络设备、系统日志 | 安全设备、SIEM 接入 |
| 携带字段 | 基本字段 + 可选结构化 | 7 个固定字段 + 任意自定义 |
一句话总结：syslog 是万能钥匙，CEF 是安全专用刀。如果你的审计系统只需要接安全设备，直接用 CEF 最顺手；如果设备五花八门（Linux、交换机、数据库），用 syslog 更灵活。
实践经验：格式选择与避坑
- 统一格式，别混用：我记得有个项目，同一个机房 30 台设备，5 种日志格式。最后我们写了个适配层，每种格式配不同解析器，开发量翻了一倍。
- 时间戳必须带时区：遇到过很多次日志时间没有时区，导致跨域关联时差 8 小时。我建议统一用
2024-01-15T10:45:33.000Z（UTC）或带偏移。 - 别忽视优先级映射：syslog 的 facility 和 severity 跟 CEF 的严重级别不是一一对应，需要做映射表。我曾经踩过坑，把 Info 级别的日志标成了 High，被合规审计揪出来写整改报告。
- 设备厂商的“方言”：就算都说自己支持 CEF，我碰到过厂商把 src 写成 source，或者多加几个空格。所以接入新设备时，一定要先抓几根日志验证。
template(name="MyFormat" type="string" string="<%pri%>1 %timestamp:::date-rfc3339% %hostname% %app-name% %procid% %msgid% [meta logsource="%fromhost%"] %msg%\n")。
|）在 CEF 里是字段分隔符，如果在消息里出现了，必须转义为 \|。否则解析会直接断行，导致后面的字段全部错位。
一张图看懂审计日志格式选择
我画了个流程图，帮你在实际选型时快速判断：
这个图其实是我自己在做《密文检索审计日志DLP合规架构》第一版时画的。当时团队争论用 syslog 还是 CEF，我直接画了个决策树贴在白板上。大家一看就明白：安全设备多就用 CEF，剩下的全走 syslog（优先 RFC 5424）。后来这个决策树几乎没改过。
好了，格式基础就这些。你以后接新设备时，先问自己三个问题：它输出的是 syslog 还是 CEF？是否带结构化字段？时区对了没？问完再配解析器，省得走弯路。