关键在结构化+可比对：rsyslog需标准化日志字段（rfc5424/awk预处理）、打trace_id串联事件、建立登录频次/时段/命令等基线，再用property-filter实时捕获异常并路由告警，配合logrotate、chattr+ a和sha256sum保障日志防篡改。
直接用 rsyslog 做异常模式提取，关键不在“堆日志”，而在“结构化+可比对”。原始 syslog 行语义模糊、格式不一，靠 grep 翻找等于大海捞针。真正有效的提取，是让每条日志自带上下文、可量化、能打标。
标准化日志字段，为分析铺路
默认的 auth.log 或 messages 里，“Failed password for user admin from 10.1.2.5”这类文本无法直接做统计或告警。必须先统一成机器可读格式：
- 启用 RFC5424 协议格式：在 rsyslog 配置中加入 $ActionFileDefaultTemplate RSYSLOG_SyslogProtocol23Format，日志自动带 structured-data 字段，如 [origin ip="10.1.2.5" user="admin"]
- 对已有非结构化日志做预处理：用 awk 提取关键元素，例如把登录失败行重写为 event=login_fail user=admin src_ip=10.1.2.5 reason=bad_password
- 为每次会话打唯一 trace_id：结合 PAM session ID 或生成 UUID，把一次登录后的所有 sudo、命令执行、退出等事件串联起来，便于还原完整行为链
定义可验证的正常基线
没有基线，就分不清“多”还是“怪”。异常不是绝对值，而是偏离常态：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 按账号统计每日平均登录次数、高频登录时段（如运维账号集中在 9–18 点）、常用命令（dev 账号极少用 sudo su -，但运维账号高频出现）
- 用 ELK 或本地脚本定期计算这些指标，存为参考快照；新日志进来时，实时比对是否超出 ±2σ 或固定阈值
- 例如：某账号过去 7 天从未在凌晨 2–5 点登录，今天连续触发 3 次，即标记为高风险
用 rsyslog 规则实现实时模式捕获
别等日志写完再分析——rsyslog 本身就能边收边筛：
- 利用 property-based filter（如 if $programname == 'sshd' and $msg contains 'Failed'）精准匹配，避免正则开销
- 配合 omelasticsearch 或 omfile，把匹配到的异常事件单独路由到 /var/log/alerts/auth-fail.log，供后续聚合或告警调用
- 组合条件更实用：比如 同一 src_ip 在 3 分钟内触发 ≥5 条 login_fail + ≥1 条 sudo，说明可能正在暴力爆破后提权
保留与防篡改，确保分析可信
再准的模式，若日志被删或改，就失去意义：
- logrotate 配置至少保留 90 天，且用 create 0600 root root 保证日志文件权限严格
- 对关键日志路径（如 /var/log/auth.log）启用 chattr +a，只允许追加，禁止修改或删除
- 定期用 sha256sum 对归档日志生成校验和，并离线保存，事后可验证完整性
