2. 主机日志来源与分类

主机日志审计的第一步不是“采集”，而是“认源”。同一台服务器上，日志可能来自内核、系统服务、Web 应用、Java 中间件、数据库以及旁路的安全设备。它们的生成机制、落盘位置、字段结构和时间语义差异很大，如果混在一起采集和解析，后续的关联分析与异常检测就会失去基础。本节按五类来源逐一说明其生成机制与关键字段，并给出可落地的识别方法。

一、操作系统日志：内核与系统服务的统一出口

在 Linux 上，操作系统日志主要由三部分构成：内核环形缓冲区（dmesg）、systemd 日志（journald）以及传统 syslog 文件。内核通过 printk 将消息写入环形缓冲区，systemd-journald 从 /dev/kmsg、syslog socket 和标准输出收集消息，再按配置转发到 /var/log/messages、/var/log/secure 或 /var/log/syslog。Windows 则通过事件日志服务写入 .evtx 文件，分为系统、安全、应用三大通道。

操作系统日志的关键字段包括：时间戳（注意时区与 UTC 偏移）、主机名、进程名与 PID、日志级别（emerg/alert/crit/err/warning/notice/info/debug）、消息体，以及 syslog 的 facility 与 priority。以一条典型 sshd 登录失败日志为例：

Mar 12 09:14:22 web01 sshd[2317]: Failed password for invalid user admin from 203.0.113.45 port 51422 ssh2

解析时应提取：时间 Mar 12 09:14:22、主机 web01、进程 sshd、PID 2317、事件类型“登录失败”、源 IP 203.0.113.45、源端口 51422。这些字段是暴力破解检测、异常登录基线建模的最小输入。

二、应用日志：业务语义最丰富的一类

应用日志由应用程序自身通过日志框架（如 Log4j2、Logback、Python logging、Go log/slog）生成，通常写入本地文件、标准输出或直接发送到远端。其生成机制是“代码埋点 + 框架格式化 + 输出目标”三段式：开发者在关键分支调用 logger.info()，框架按 Pattern 渲染成文本或 JSON，Appender 决定落盘或转发。

应用日志的关键字段取决于格式。文本格式常见字段为时间、级别、线程、类名、消息；JSON 格式则更利于解析，典型字段包括 timestamp、level、logger、thread、traceId、userId、message、exception。其中 traceId 是跨服务关联的核心，缺失它会导致分布式追踪断裂。示例：

{"timestamp":"2025-03-12T09:14:22.317+08:00","level":"ERROR","logger":"com.shop.OrderService","thread":"http-nio-8080-exec-7","traceId":"a1b2c3d4e5","userId":"u10086","message":"payment callback timeout","orderId":"O20250312001"}

审计关注点在于：错误级别突增、同一 traceId 下的异常链路、userId 与敏感操作的对应关系。

三、安全设备日志：旁路视角的攻防证据

安全设备日志来自防火墙、WAF、IDS/IPS、EDR、堡垒机等。它们通常不直接运行在业务主机上，而是通过镜像流量、Agent 或 API 上报生成。生成机制是“检测引擎匹配规则 → 命中事件 → 格式化输出”，常见格式为 syslog、CEF（Common Event Format）或 JSON。

CEF 格式的关键字段为：CEF:Version|Device Vendor|Device Product|Device Version|Signature ID|Name|Severity|Extension。扩展部分常含 src、dst、spt、dpt、proto、act、msg。例如 WAF 拦截 SQL 注入：

CEF:0|Vendor|WAF|2.1|942100|SQL Injection Attempt|8|src=198.51.100.23 dst=10.0.0.8 dpt=443 act=blocked cs-method=GET cs-uri=/login

安全设备日志的价值在于提供“外部攻击视角”，与主机日志中的进程、文件、账号行为做时间对齐后，可还原完整攻击链。

四、中间件日志：请求链路的枢纽

中间件包括 Nginx、Tomcat、Kafka、Redis、RabbitMQ 等。以 Nginx 为例，其访问日志由 ngx_http_log_module 在请求结束时按 log_format 写入，错误日志由各模块在异常时写入。Tomcat 则通过 JULI 记录 Catalina、localhost、manager 等日志。

Nginx 默认 combined 格式字段为：$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent"。示例：

203.0.113.45 - - [12/Mar/2025:09:14:22 +0800] "POST /api/login HTTP/1.1" 401 231 "-" "curl/7.68.0"

关键字段：客户端 IP、时间、请求方法与 URI、状态码、响应字节数、User-Agent。状态码 401/403 集中出现、单一 IP 高频访问、异常 User-Agent 都是异常检测的强特征。中间件日志是连接“外部请求”与“应用内部处理”的桥梁。

五、数据库日志：数据变更的最终凭证

数据库日志分为错误日志、慢查询日志、通用查询日志和二进制日志（binlog）。以 MySQL 为例，binlog 由存储引擎层在事务提交时写入，记录所有数据变更；慢查询日志由 long_query_time 阈值触发；错误日志记录启动、崩溃、复制异常。

binlog 的关键字段包括：Log_name、Pos、Event_type、Server_id、End_log_pos、Info。慢查询日志关键字段为：Query_time、Lock_time、Rows_sent、Rows_examined、user@host、SQL 语句。示例：

# Time: 2025-03-12T09:14:22.317+08:00
# User@Host: appuser[appuser] @ 10.0.0.12 []  Id: 8821
# Query_time: 12.431  Lock_time: 0.002  Rows_sent: 1  Rows_examined: 1843201
SET timestamp=1741742062;
SELECT * FROM orders WHERE user_id='u10086' AND status='PENDING';

数据库日志是审计“谁在什么时间改了什么数据”的最终依据，尤其适用于越权访问、批量导出、异常更新等场景。

六、五类日志的生成机制与字段对照

为便于统一建模，下表汇总五类日志的生成触发点、典型落盘位置与核心字段。实际环境中字段名可能因版本和配置不同而变化，应以解析规则实测为准。

七、从字段到检测：一个最小关联示例

假设 09:14:22 出现一次异常登录，五类日志分别留下痕迹：操作系统日志记录 sshd 登录失败；中间件日志记录 POST /api/login 返回 401；应用日志记录 payment callback timeout 并携带 traceId；安全设备日志记录同一源 IP 的 SQL 注入拦截；数据库慢查询日志记录该用户触发的全表扫描。若五类日志的时间戳、源 IP、traceId、userId 能正确解析并归一化，就能在一条时间线上还原“扫描 → 尝试登录 → 注入 → 异常查询”的完整链路。反之，若字段缺失或时间错位，关联就会断裂。

掌握五类日志的生成机制与关键字段后，采集端才能有针对性地配置解析规则：操作系统日志重点提取进程与账号，应用日志重点保留 traceId 与业务标识，安全设备日志重点保留五元组与动作，中间件日志重点保留状态码与 URI，数据库日志重点保留 SQL 与影响行数。字段选得准，后续的异常检测才有可靠的输入。