保障linux日志完整性核心是全链路可信可验证：启用auditd append_only强制只追加、chrony统一时间锚点（偏差≤3秒）、rsyslog+tls外发并强绑定身份、每月闭环验证记录/防删/还原能力。
保障Linux日志完整性，核心不是“存下来”，而是让日志在法律和合规场景中真正可采信——即能证明“谁、在何时、做了什么”，且过程不可抵赖、不可篡改。这要求从生成、存储、传输到验证的全链路具备技术可信与流程可审计能力。
用 auditd + append_only 模式锁死日志写入行为
auditd 默认以追加方式写入日志，但若未启用强制只追加保护，攻击者仍可能通过覆盖或清空文件破坏证据链。必须在 /etc/audit/auditd.conf 中明确配置：
- log_file = /var/log/audit/audit.log
- append_only = yes（关键！启用内核级只追加保护）
- max_log_file_action = rotate（避免日志满导致丢事件）
- space_left_action = email 和 action_mail_acct = root（磁盘空间预警）
启用后，即使 root 用户也无法 truncate 或重定向该文件，系统调用会直接返回 EPERM。这是满足 SOX、等保2.0三级“防篡改”条款的技术基线。
时间锚点统一是行为链合法性的前提
多台机器时间不同步，会导致 sudo 执行、文件修改、登录登出等事件无法串联成完整操作链——司法采信时会被质疑“时间逻辑断裂”。必须做到：
- 全节点使用 chrony（非 ntpd），配置相同可信 NTP 源（如内网授时服务器或 pool.ntp.org）
- /etc/chrony.conf 中必须含 makestep 1 -1，防止重启后时间跳变引发日志倒序
- 每日自动检查偏移：执行 chronyc tracking | grep "Last offset"，超 ±50ms 触发告警
等保2.0和 GDPR 明确要求“时间戳连续、可信、可验证”，时间偏差超过3秒即视为审计失效。
外发日志必须带身份强绑定与传输完整性
仅本地保存日志等于无审计——攻击者控制主机后可一键清除。合规要求日志“生成即离机”，且需确保外发过程不被中间人篡改或伪造来源：
- 用 rsyslog + TLS 或 journalbeat + mTLS 推送 audit 日志至独立 SIEM（如 ELK/Splunk）
- 配置 RSYSLOG_ForwardFormat 或 journalbeat fields，显式注入 host_id、node_role、auditd_version 等上下文字段
- SIEM 端需校验每条日志的 loginuid、auid、ses 字段，拒绝缺失或非法值（如 auid=4294967295 表示未设置）
金融行业“四眼原则”还要求对特权命令执行链做跨进程溯源，例如通过 -S fork -S execve -F auid!=uid 规则捕获完整调用链，并在外发日志中保留原始 syscall 结构。
定期验证日志是否真被记录、真不可删、真可还原
规则写了 ≠ 生效 ≠ 持久 ≠ 可用。每月至少执行一次闭环验证：
- 触发测试行为：sudo touch /tmp/audit-test，再运行 ausearch -m SYSCALL -ts recent -i | grep "touch.*tmp" 查是否捕获
- 检查日志权限：ls -l /var/log/audit/ 应为 drwx------ root root，日志文件为 -rw-------
- 抽样比对 SIEM 中事件时间戳与本地 chrony 偏移，确认误差 ≤100ms
- 用 aureport --key cluster_sudo_exec --summary 统计集群维度 sudo 使用频次，验证规则覆盖一致性
不复杂但容易忽略：很多环境 auditd 在跑，规则也加载了，但 append_only 关着、chrony 同步失败、rsyslog 走的是明文 UDP——这些细节一漏，整套审计在法务质证环节就站不住脚。
