必须启用@@(o) TLS双向认证以确保日志加密可信，精准捕获authpriv、auditd和local6三类高价值审计日志源，禁用文件轮转读取，改由rsyslog直连源头；客户端须正确加载gtls模块、配置证书路径与权限，并使用@@(o)host:6514语法；服务端需按IP隔离落盘、禁用本地伪造日志写入，并结合WORM机制防篡改。
必须用 @@(o) 语法启用 TLS 双向认证，否则日志只是“发出去了”，但不加密、不可信、可被中间人篡改。
怎么确认关键审计日志源已精准捕获
authpriv、auditd 和 local6 是三类高价值审计日志源，不能靠 /var/log/secure 或 /var/log/auth.log 文件轮转后读取——那会丢日志。正确做法是让 rsyslog 直接接入源头：
-
authpriv.*：默认已由 rsyslog 的imuxsock模块接收，无需额外配置；但要确保/etc/rsyslog.conf中没禁用module(load="imuxsock") -
auditd日志：必须用imfile模块实时 tail/var/log/audit/audit.log，否则 auditd 轮转时（如 logrotate 触发）会丢失最后几秒事件；配置示例：module(load="imfile")<br>input(type="imfile" File="/var/log/audit/audit.log" Tag="auditd:" Severity="info" Facility="local6")
- 用户命令审计（可选）：在
/etc/bash.bashrc或用户 profile 中加trap 'logger -p local6.notice "$(history 1 | sed "s/^[ ]*[0-9]\+[ ]*//")"' DEBUG，把每条命令打到local6设施，便于统一加密转发
客户端 TLS 转发配置里最容易错的三处
rsyslog 客户端配置不是“写完就通”，常见失败点集中在模块加载顺序、TLS 驱动绑定和目标地址语法：
- 必须显式加载
gtls模块：module(load="gtls")，且要在omfwd之前；否则@@(o)会退化为普通 TCP -
$DefaultNetstreamDriver必须设为gtls，且后续所有$DefaultNetstreamDriver*参数（如CAFile、CertFile、KeyFile）必须路径绝对、权限为600（仅 root 可读），否则 rsyslog 启动直接报Could not load certificate - 目标地址必须用
@@(o)host:6514，不是@(o)或@@(x)；(o)表示 “open TLS session with server cert verification”，缺括号或字母就走明文
服务端接收配置必须隔离 IP + 防篡改落盘
只开 imtcp + TLS 不等于安全——攻击者若拿到客户端证书，仍可伪造任意主机 IP 发送日志。必须靠模板和规则强制按来源隔离：
- 用
$template动态生成路径：$template RemoteAudit,"/var/log/remote/%FROMHOST-IP%/%syslogfacility-text%/%$YEAR%%$MONTH%.log"<br>*.* ?RemoteAudit &~
这样每台机器日志独立目录，避免交叉污染 - 禁用默认全局日志文件写入：在
rules段开头加:fromhost-ip, !isequal, "127.0.0.1" ~，防止本地伪造日志混入远程流 - WORM（一次写入多次读取）需靠外部机制实现：rsyslog 本身不提供防删改，建议用
chattr +a锁定日志目录，或挂载为noatime,nobarrier的 ext4，并配合定期sha256sum校验存证
真正难的不是配通 TLS，而是让每条 authpriv 登录失败、auditd 权限变更、local6 命令执行都从源头进管道、全程不落地、抵达后不可抵赖——这要求客户端证书按主机粒度签发、服务端模板按 IP 粒度隔离、磁盘队列参数（如 $ActionQueueMaxDiskSpace）足够扛住网络抖动，漏掉任何一环，备份就只是“看起来很安全”。
