如何在Linux中配置具体的系统安全日志记录等级

Linux系统安全日志（auth/authpriv）不能靠全局开关调低级别，必须在rsyslog配置文件中显式指定如auth.warning等规则，否则默认记录info及以上全部消息，易淹没关键事件；其规则独立于*.info，需单独配置并注意顺序。

先把结论放在前面：Linux 的安全日志，尤其是 auth 和 authpriv 这两类，记录等级并不能靠一个全局开关就“一把调低”。要控制它，必须到 /etc/rsyslog.conf 或 /etc/rsyslog.d/ 下面的规则里明确写出级别；否则系统通常会按默认方式，把所有 info 及以上的消息都记下来。结果是什么？大量 info 级别的 SSH 登录成功、sudo 命令执行这类日志会不断涌入，很容易把真正值得盯紧的 err 或 crit 事件压在里面，关键告警反而不显眼了。

auth/authpriv 日志规则必须单独写，不能依赖 *.info

很多人误以为改了 *.info 就能控制安全日志，但实际 auth.* 和 authpriv.* 是独立规则，常被写在配置文件靠后位置，优先级高于通配规则。它们默认是 auth.* 或 authpriv.*，意味着所有 info 及以上都会落盘。

• 查当前规则：grep -E "^(auth|authpriv)." /etc/rsyslog.conf /etc/rsyslog.d/*.conf
• 典型危险写法：auth.* /var/log/auth.log —— 这会记录每次 SSH 登录成功（info）、密码错误（warning）、密钥拒绝（notice）等，日志量爆炸
• 合理写法应明确限定级别，例如只记录 warning 及以上：auth.warning /var/log/auth.log
• 若需保留登录成功但过滤掉失败尝试，可用 auth.info;auth.!warning /var/log/auth.log（注意语法：分号分隔，! 表示排除）

sshd 和 sudo 的日志来源不等于 auth 设施

sshd 默认使用的是 auth 设施，不过在一些发行版环境里，比如 RHEL/CentOS 8+，或者开启了 UsePAM 时，登录失败记录往往会被写进 authpriv；至于 sudo，默认同样走 auth，但更细的命令执行日志还会受到 syslog 模块配置的影响，所以未必都会完整落在 /var/log/auth.log 里。

• 确认 sshd 实际设施：sshd -T | grep -i syslog，看输出是否含 syslog_facility AUTH 或 AUTHPRIV
• sudo 日志位置取决于 /etc/sudoers 中的 Defaults syslog 设置，常见值为 auth 或 local2，不是固定写死的
• 不要只盯 /var/log/auth.log，用 journalctl -t sshd -p warning 或 journalctl _COMM=sudo -p err 直接按程序和级别过滤更可靠

rsyslog 动态过滤比静态规则更准，但要防顺序陷阱

用 $syslogseverity 字段做条件判断（比如只收 severity ≤ 4 即 warning 及以上），比改 auth.warning 更细粒度，但规则顺序决定成败——它必须放在通用规则（如 *.*）之前，否则日志早被前面规则吃掉了。

• 正确顺序示例（写入 /etc/rsyslog.d/30-security-filter.conf）：

  if $syslogfacility-text == 'auth' and $syslogseverity <= 4 then /var/log/auth-critical.log
  & stop

• & stop 不可省：阻止后续规则重复写入，否则既写进 auth-critical.log 又写进默认 auth.log
• 验证 severity 数值：emerg=0, alert=1, crit=2, err=3, warning=4, notice=5, info=6, debug=7
• 测试规则是否生效：logger -p auth.warning "test warning" + logger -p auth.info "test info"，然后检查目标文件是否只含前者

真正难的不是写哪一行配置，而是搞清某条日志到底从哪个程序发出、经由哪个 facility、被哪个 rsyslog 规则捕获、又是否被 & stop 截断——漏掉任意一环，auth 日志该刷屏还是刷屏。