单纯开启syslog不能自动完成异常操作审计，关键在于与auditd协同构成证据链：聚焦auth/authpriv设施捕获权限行为，显式配置sudo日志、启用auditd记录内核级调用，并通过rsyslog_syslogprotocol23format实现结构化日志与三层日志（syslog/auditd/journald）关联。
单纯开启 Syslog 不能自动完成异常操作审计，关键在于让日志具备可追溯性、上下文完整性和机器可读性。它不是替代 auditd 的方案，而是与之协同构成证据链的重要一环。
聚焦 auth 和 authpriv 设施，捕获真实权限行为
默认的 /var/log/auth.log（或 /var/log/secure）只记录 PAM 登录事件，容易漏掉 sudo、su、setuid 程序调用等关键动作。必须主动强化配置：
- 在 rsyslog 中显式捕获 sudo 日志：添加规则 local2.* /var/log/sudo.log，并在 /etc/sudoers 中启用 Defaults logfile="/var/log/sudo.log"
- 确保 auditd 启用并协同工作：Syslog 不记录 execve、openat 等内核级系统调用，需靠 auditd 捕获，再通过 audispd 插件将日志转发至 rsyslog 的 local0 设施
- 禁用模糊记录：避免出现 “user unknown” 或 “invalid user” 类泛化条目；强制 SSH 等服务记录完整用户名、源 IP、TTY 和时间戳
结构化日志格式 + 关键字段提取
原始 Syslog 行是半结构化文本，人工排查效率低。提升质量的第一步是统一字段表达：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 启用 rsyslog 的 RSYSLOG_SyslogProtocol23Format 模式，使日志符合 RFC5424，自带 structured-data 字段（如 [origin ip="10.1.2.3"]）
- 对 auth.log 做预处理：用 awk 或 logrotate 配合 script 提取并重写关键字段，例如将 "Failed password for invalid user alice from 192.168.5.22" 标准化为 event=login_fail user=alice src_ip=192.168.5.22 reason=invalid_user
- 为每条日志打上唯一 trace_id（如 UUID 或 session ID），便于串联一次登录后的全部命令执行链
设置可验证的审计基线与偏差告警
“有日志”不等于“能审计”，必须定义什么是“正常”，才能识别“异常”：
- 建立用户行为基线：统计各账号每日平均登录次数、常用登录时段、高频执行命令（如运维账号常跑 ansible，开发账号极少用 sudo）
- 配置 rsyslog + imfile + omelasticsearch 实时写入 ELK，用 Kibana 建立 watch：当某用户在非工作时间触发 3 次 sudo su - root，或同一 IP 在 5 分钟内尝试 5 个不同账号登录，立即触发告警
- 保留至少 90 天的完整日志，并启用 logrotate 的 create 0600 root root 权限控制，防止日志被低权限进程篡改或覆盖
与 auditd 和 systemd-journald 形成三层证据链
Syslog 是审计证据链中的一环，不是全部。高质量内部权限审计依赖三类日志：
- Syslog 层：记录服务级行为（SSH 登录、sudo 执行、PAM 认证结果）
- auditd 层：记录内核级细粒度操作（execve 调用、文件 openat、capset 变更）
- journald 层：记录 systemd 单元生命周期、环境变量、命令行参数，补充上下文
三者通过时间戳、PID、UID、session ID 关联，形成不可抵赖的操作证据链。
