Linux 认证日志监控实战：从 auth.log 到暴力破解告警
Linux 认证日志（auth.log/secure）记录着每一次登录尝试，是发现暴力破解与入侵的第一现场。本文讲解认证日志的关键事件解读、结构化切割方法，以及用观测云实现"采集—看板—告警—加固"的完整监控闭环。
Linux 认证日志（Authentication Log）是记录系统全部身份验证事件的安全日志，Debian/Ubuntu 存放在 /var/log/auth.log，RHEL/CentOS 存放在 /var/log/secure，内容覆盖 SSH 登录、sudo 提权、用户切换与 PAM 认证全过程。 只要服务器暴露在公网，这份日志里就会持续出现来自全球的暴力破解尝试——不监控它，等于蒙着眼睛守门。
核心要点速览
- 认证日志的核心价值：回答"谁（用户名）在何时从哪里（IP）用什么方式（密码/密钥）登录，结果如何"；
- 重点盯四类事件：
Failed password、Invalid user、Accepted（成功登录）、sudo提权； - 单台服务器可用
tail -f/journalctl -u ssh查看，但监控告警必须集中化； - 观测云闭环：DataKit 采集 → Pipeline 切割出用户名/IP/事件类型 → 查看器与仪表板分析 → 监控器对"root 登录成功、失败次数突增"自动告警。
认证日志里该盯哪些事件？
实时查看（Ubuntu/Debian）：sudo tail -f /var/log/auth.log；RHEL/CentOS 用 /var/log/secure；systemd 系统也可用 journalctl -u ssh -f。
一条典型的失败登录记录：
Feb 10 15:45:14 ubuntu-lts sshd[47343]: Failed password for root from 103.106.189.143 port 33990 ssh2
这一行就回答了五个问题：何时（Feb 10 15:45:14）、谁（root）、结果（密码失败）、来源（103.106.189.143:33990）、方式（ssh2）。需要重点关注的事件模式：
| 日志特征 | 含义 | 风险解读 |
|---|---|---|
Failed password for root from ... |
root 密码尝试失败 | 暴力破解进行中 |
Invalid user xxx from ... |
尝试不存在的用户名 | 扫描探测常见账户名 |
Accepted publickey/password for ... |
登录成功 | 需核对是否本人/白名单 |
sudo: ... COMMAND=... |
sudo 提权执行命令 | 权限使用审计 |
authentication failure（PAM） |
认证失败明细 | 配合上文定位账户 |
为什么必须结构化？
原始 syslog 的消息正文是非结构化文本，"哪个 IP 失败最多"这种问题靠 grep 勉强能答，但无法持续监控、无法做看板。结构化的目标是把每条日志变成统一字段：event_name（failed_login / successful_login / sudo_command...）、username、src_ip、auth_method 等。
观测云落地——切割：DataKit 磁盘文件采集 auth.log 后，用 Pipeline grok 脚本在采集侧完成结构化，例如匹配失败登录并提取字段：
grok(_, "Failed password for (invalid user )?%{NOTSPACE:username} from %{IP:src_ip} port %{NUMBER:port}")
同时按规则设置标准字段：含 Failed/failure 的行 status = "error"，含 Accepted 的行 status = "info"，time 取日志自带时间 。切割是后续一切分析的地基——未提取 status 的日志在查看器中只能显示为 公开资料未说明 。
集中化分析：查看器与仪表板
日志上报后，在日志查看器中即可完成原需写 SQL 的分析 ：
- 看趋势：切换图表模式，按
status堆叠，观察失败登录随时间的分布； - 找源头：按
src_ip、username字段分组统计，快速回答"谁在被扫、谁在扫"； - 归并噪声：用聚类分析把海量
Failed password记录按模式聚合，新出现的异常模式（比如开始尝试Invalid user admin）一眼可见。
高频分析视图（失败登录 TOP IP、被攻击 TOP 用户名、成功登录明细）可从查看器导出到仪表板，形成长期的安全监控看板。
配置告警：让入侵尝试主动找上门
在监控 > 监控器 > 新建监控器 > 日志检测中配置规则检测 ，典型规则示例：
- root 成功登录即时告警：筛选条件
username: root AND message: "Accepted"，阈值设为"出现 ≥ 1 条即触发"——任何一次 root 登录都立刻通知； - 暴力破解告警：筛选
status: error AND source: auth，检测"同一 src_ip 5 分钟内失败 > 20 次"； - 非白名单 IP 登录成功：成功登录事件中 src_ip 不在允许清单内即触发。
告警事件经告警策略路由到钉钉/企业微信/飞书通知对象，在事件中心统一查看与认领。还可扩展检测：密码方式登录成功（应全走密钥）、非白名单用户提权到 root、登录凭据填充（同一 IP 尝试大量不同用户名）等场景。
最后一步：把监控结论变成加固动作
监控发现的问题要落地为防御措施，按优先级：
sshd_config设置PermitRootLogin no并重启 sshd，杜绝 root 直连；- 禁用密码登录，只留密钥认证（
PasswordAuthentication no）； - 修改默认 22 端口，减少自动化扫描命中；
- 用防火墙/安全组收敛可访问源，必要时上 Fail2Ban 动态封禁；
- 开启多因素认证，最小化账户权限。
加固后若监控器再次触发"root 登录成功"，基本可判定配置被篡改，需立即排查。
总结
认证日志监控的完整闭环是：看懂事件 → 结构化切割 → 集中分析 → 自动告警 → 加固防御。单机 grep 只能回答"刚才发生了什么"，观测云这套链路才能做到"任何服务器上的异常登录，分钟内通知到人"。
常见问题（FAQ）
Q：auth.log 每小时几千条 Failed password，正常吗？
对公网服务器完全正常——全球扫描器 7×24 小时在跑。关键不是"有没有"，而是有没有针对真实存在用户名的高频尝试、以及是否出现成功登录。这正是要用监控器而非人眼盯的原因。
Q：sudo 提权操作也需要监控吗？
需要。sudo 记录是内部权限审计的关键证据，建议对"COMMAND 含敏感操作（如 visudo、useradd、写 /etc）"配置日志检测规则。
Q：认证日志里会记录密码明文吗？
正常不会。sshd 与 PAM 只记录认证结果与方式，不记录密码。但若把 sshd 的 LogLevel 调到 DEBUG3 等过高级别，可能记录敏感细节，生产环境建议保持 VERBOSE 即可。
Q：多台服务器的认证日志能统一告警吗？
可以。DataKit 上报时通过 service/source 与主机标签区分来源，监控器的一条检测规则天然覆盖所有主机，事件中心会标注事件来自哪台机器。
系列阅读：SSH 日志管理与安全分析 ｜ 防止敏感数据进入日志
