关键在于轮转与日志服务协同：auditd需SIGHUP通知，rsyslog用USR1重载；须设maxsize+daily双触发、create 0600权限、chattr +a/+i防护，并通过logrotate -d/-f验证生效。
要防止安全日志被覆盖或丢失，关键不是“轮转动作本身”，而是让轮转与日志服务协同工作、权限受控、保留策略合规、失败可感知。Logrotate 本身不运行服务，靠 cron 每天触发，所以配置必须一次写对，且每处细节都影响数据连续性。
确保 auditd 和 rsyslog 不丢日志
audit.log 和 auth.log 来源不同，处理方式不能一概而论：
-
auditd 日志必须发 SIGHUP：auditd 不监听文件变化，轮转后若不通知，它继续往已重命名的旧文件句柄写——新日志不出现，旧归档持续膨胀。在 postrotate 中加：
/bin/systemctl kill --signal=SIGHUP auditd 2>/dev/null || true -
rsyslog/auth.log 推荐用 USR1：多数发行版中 rsyslog 支持
kill -USR1重载日志路径，比 restart 更安全；检查 pid 文件是否存在再发信号，避免静默失败。 -
禁用 restart 类操作：如
systemctl restart auditd会中断审计流，syscall 事件丢失不可恢复，等保场景下直接算违规。
用 maxsize + daily 双触发防突发暴涨
仅设 daily 不可靠：某次暴力破解攻击可能在一小时内生成数 GB auth.log，单日轮转完全来不及响应。
- 在配置块中同时写
daily和maxsize 100M，logrotate 优先响应先达条件； - 对 audit.log 这类高敏感日志，建议
maxsize 50M起步，结合rotate 24和maxage 90（满足等保180天可换为180）； - 注意
maxage依赖dateext：没开 dateext，logrotate 只认audit.log-20260619这类命名，否则 maxage 不生效。
权限与文件系统级防护堵住误删漏洞
光靠 chmod 无法防 root 误操作，需叠加内核级锁定：
- logrotate 配置中必须含
create 0600 root root，确保新日志仅属主可读写； - 轮转完成并归档后，对已压缩的旧文件执行：
chattr +i /var/log/audit/audit.log-20260618.gz —— 加 i 属性后，连 root 也需先chattr -i才能删，操作留痕； - 对当前正在写的
audit.log不能加+i（auditd 会写失败），但可加+a（仅追加），防止截断或覆盖； - 检查 SELinux 上下文：
ls -Z /var/log/audit/，若 context 错误（如 unconfined_u），auditd 可能静默降级不写日志。
验证是否真生效，别只信配置文件
改完配置不验证，等于没配。每天轮转靠 cron，但你得确认它真按预期跑：
- 用调试模式看逻辑：
logrotate -d /etc/logrotate.d/auditd，检查输出里是否有 “rotating log /var/log/audit/audit.log” 和 “running postrotate script”； - 强制立即执行测试：
logrotate -f /etc/logrotate.d/auditd，然后立刻执行：
ls -lt /var/log/audit/ —— 应看到新audit.log时间戳是当前秒级；
ausearch -m avc -ts recent | head -5 —— 确认仍有新审计事件写入； - 查状态文件：
cat /var/lib/logrotate/status | grep audit，确认最后轮转时间与预期一致。
