为什么要做真实验证
日志防篡改措施（只追加属性、权限收敛、集中转发、哈希校验）往往只在制度里被描述，实际是否生效没人验证过。等到检查或事件复盘时才去删一条日志试试，风险太大：要么发现措施根本没生效，要么在生产环境造成不可逆损失。正确做法是把「尝试修改与删除日志」做成一次有预案的定期演练，用测试文件在受保护目录内验证属性与权限，再把过程与结果整理成迎检证据。
验证清单
- 属性验证：对受保护目录内的测试文件设置只追加或不可变属性，确认删除与覆写被拒绝
- 权限验证：用非授权账号尝试读取与写入日志目录，确认被拒绝且产生告警
- 集中副本验证：确认采集端（如 rsyslog、Winlogbeat）在本地日志被破坏后仍有完整副本
- 完整性验证：核对哈希索引或校验值，确认日志链未被裁剪或替换
- 审计留存验证：确认 auditd 或安全日志的留存周期满足制度与法规要求
- 恢复验证：从归档介质取回一段时间窗日志，确认可检索、可读
验证步骤示例
验证步骤示例
# 1 属性验证：在受保护目录内用测试文件，避免动到生产日志
sudo touch /var/log/audit/.tamper-test
sudo chattr +a /var/log/audit/.tamper-test # 只追加
touch /var/log/audit/.tamper-test; echo "退出码=$?" # 预期 Operation not permitted
sudo rm -f /var/log/audit/.tamper-test # 预期 Operation not permitted
sudo chattr -a /var/log/audit/.tamper-test && sudo rm -f /var/log/audit/.tamper-test # 清理
# 2 集中副本验证：本地日志被破坏后远端仍在
ssh logserver 'ls -l /var/log/remote/web01/ | head -5'
# 3 完整性验证：校验当日归档包的哈希
grep "nginx-access" /secure/hash-index.txt | tail -1 | sha256sum -c -验证项与预期结果
| 验证项 | 预期结果 |
|---|---|
| 只追加属性生效 | 删除与覆写返回 Operation not permitted，追加写入成功 |
| 非授权账号访问 | 读取被拒绝，且审计日志中出现对应的权限拒绝事件 |
| 集中副本完整 | 采集平台上的记录条数与源端一致，时间戳连续无断档 |
| 哈希校验通过 | 校验值与索引记录一致，返回 OK |
| 留存周期达标 | 最早可检索日志的时间点不晚于制度规定的最短留存期 |
验证记录建议包含：时间、执行人、执行命令、预期结果、实际结果、结论，并由不属于日志管理岗的独立人员复核签名；Windows 侧可用 wevtutil 或 PowerShell 查询日志配置与通道容量，验证方式与 Linux 不同但记录格式应统一。