日志完整性检查
判断日志是否被动过，主要看三类信号：序号是否跳跃、时间是否倒退、文件长度与行数是否异常。清理日志的工具往往留下痕迹，但单一信号容易误判，必须先把轮转与归档合并这类正常运维动作排除掉再定性。
基本信息
| 序号来源 | 审计日志的事件号、应用日志中的序列字段 |
|---|---|
| 时间检查 | 用 sort -c 或脚本校验时间单调递增 |
| 文件检查 | 当前文件长度与行数，连同轮转文件一起核对 |
| 前置动作 | 先保全原始文件与哈希，再开始解析 |
| 差异来源 | 轮转、归档合并、跨主机汇聚都会造成断档 |
| 权限要求 | 读取审计与安全日志通常需要 root |
典型使用场景
- 判断日志是否被部分删除
- 确认时间线中是否存在被篡改的时段
- 校验归档合并后日志的连续性
- 配合审计日志检查事件号断档
- 在报告中说明日志覆盖范围的缺口
最小示例
最小示例
# 时间单调性检查（示例假设行首两列为时间字段）
awk '{print $1, $2}' /var/log/auth.log | sort -c 2>&1 | head -3
# 应用日志的序列号是否断档
grep -oE 'seq=[0-9]+' app.log | tail -20
# 审计事件号连续性
grep -oE 'audit\([0-9.]+:[0-9]+\)' /var/log/audit/audit.log | tail -20
# 与轮转文件一起核对总量
wc -l /var/log/auth.log /var/log/auth.log.1
sha256sum /var/log/auth.log > auth.log.sha256 # 先固化哈希再分析信号与可能原因
| 信号 | 含义 | 可能原因 |
|---|---|---|
| 序号跳跃 | 编号不连续 | 删除、轮转或跨主机合并 |
| 时间倒退 | 后一行时间早于前一行 | 时钟调整或拼接顺序错误 |
| 长度骤减 | 文件比预期明显小 | 被截断或被重写 |
| 末行不完整 | 最后一行无换行 | 写入过程被中断 |
| 元数据异常 | 属主或权限被改动 | 文件被替换或重新生成 |
日志轮转、归档合并与多主机汇聚都会造成编号断档，定性前先核对轮转配置与运维记录，把正常动作排除在外。
审计日志的事件号在同一引导周期内递增，重启后重新计数，因此连续性判断必须限定在同一次引导之内。
发现可疑后不要用编辑工具打开后再保存：写操作会改变 mtime 与内容，先复制副本并计算哈希再动手分析。