Linux 认证日志监控实战：从 auth.log 到暴力破解告警
Linux 认证日志（auth.log/secure）记录着每一次登录尝试，是发现暴力破解与入侵的第一现场。本文讲解认证日志的关键事件解读、结构化切割方法，以及用观测云实现"采集—看板—告警—加固"的完整监控闭环。
Linux 认证日志（Authentication Log）是记录系统身份验证相关事件的安全日志，常见 Debian/Ubuntu 配置写入 /var/log/auth.log，常见 RHEL/CentOS 配置写入 /var/log/secure，具体覆盖范围取决于服务、syslog 与 journal 配置，并不保证记录全过程。 只要服务器暴露在公网，这份日志里就会持续出现来自全球的暴力破解尝试——不监控它，等于蒙着眼睛守门。
核心要点速览
- 认证日志的核心价值：回答"谁（用户名）在何时从哪里（IP）用什么方式（密码/密钥）登录，结果如何"；
- 重点盯四类事件：
Failed password、Invalid user、Accepted（成功登录）、sudo提权； - 单台服务器可用
tail -f/journalctl -u ssh查看，但监控告警必须集中化； - 集中采集前先验证用户名、来源 IP、事件类型和时间；告警按这些已解析字段设置。
认证日志里该盯哪些事件？
实时查看（Ubuntu/Debian）：sudo tail -f /var/log/auth.log；RHEL/CentOS 用 /var/log/secure；systemd 系统可按实际 unit 使用 journalctl -u ssh -f 或 -u sshd；这种筛选只覆盖对应 SSH 服务，并不包含全部 sudo/PAM 日志。
一条典型的失败登录记录：
Feb 10 15:45:14 ubuntu-lts sshd[47343]: Failed password for root from 192.0.2.10 port 33990 ssh2
这一行就回答了五个问题：何时（Feb 10 15:45:14）、谁（root）、结果（密码失败）、来源（192.0.2.10:33990）、方式（password；ssh2 表示 SSH 协议版本）。旧式时间戳未含年份和时区，解析时需结合来源补齐。需要重点关注的事件模式：
| 日志特征 | 含义 | 风险解读 |
|---|---|---|
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 等。
使用观测云时，先按日志采集文档指定实际认证日志路径，再用 Pipeline grok 脚本提取字段。例如匹配失败登录的规则应以当前系统的一条真实日志测试：
grok(_, "Failed password for (invalid user )?%{NOTSPACE:username} from %{IP:src_ip} port %{NUMBER:port}")
按已识别的认证事件设置标准字段，例如失败登录映射 status = "error"，成功登录映射 status = "info"，结合年份和时区提取 time [1]。不要仅靠任意 Failed 子串分类；未提取 status 时的表现取决于采集与解析配置 [2]。
集中化分析：查看器与仪表板
日志上报后，在日志查看器中即可完成原需写 SQL 的分析 [3]：
- 看趋势：切换图表模式，按
status堆叠，观察失败登录随时间的分布； - 找源头：按
src_ip、username字段分组统计，快速回答"谁在被扫、谁在扫"； - 归并噪声：用聚类分析把海量
Failed password记录按模式聚合，新出现的异常模式（比如开始尝试Invalid user admin）一眼可见。
高频分析视图（失败登录 TOP IP、被攻击 TOP 用户名、成功登录明细）可从查看器导出到仪表板，形成长期的安全监控看板。
配置告警：让入侵尝试主动找上门
在监控 > 监控器 > 新建监控器 > 日志检测中配置规则检测 [4]，以下为逻辑条件示例，并非可直接粘贴的查询语法，需在监控器中配置并验证：
- root 成功登录检测：筛选已解析的 username 为 root 且 event_name 为 successful_login，阈值设为"出现 ≥ 1 条即触发"，再用测试事件验证检测周期和通知延迟；
- 暴力破解告警：筛选 source 为 auth 且 event_name 为 failed_login，检测"同一 src_ip 5 分钟内失败 > 20 次"；
- 非白名单 IP 登录成功：成功登录事件中 src_ip 不在允许清单内即触发。
告警事件经告警策略路由到钉钉/企业微信/飞书通知对象，在事件中心查看检测结果。还可扩展检测：密码方式登录成功（应全走密钥）、非白名单用户提权到 root、登录凭据填充（同一 IP 尝试大量不同用户名）等场景。
最后一步：把监控结论变成加固动作
监控发现的问题要落地为防御措施，按优先级：
sshd_config设置PermitRootLogin no，先用 sshd -t 和有效配置检查，再按服务方式重载；保留现有会话并测试新登录；- 若只允许密钥认证，除 PasswordAuthentication no 外还需核对 KbdInteractiveAuthentication、PAM 与 Match 配置；MFA 场景要保留所需认证方式并配置 AuthenticationMethods；
- 修改默认 22 端口只能减少部分扫描噪声，不能替代认证与访问控制；
- 用防火墙/安全组收敛可访问源，必要时上 Fail2Ban 动态封禁；
- 开启多因素认证，最小化账户权限。
加固后若监控器再次触发"root 登录成功"，需核对实例、有效配置、Match 条件、时间和采集延迟，不能直接判定配置被篡改。
总结
认证日志分析应从事件识别开始，依次验证字段、筛选条件和告警通知，再根据已确认的问题调整访问控制。检查范围应覆盖实际接入的主机，并定期用已知登录事件验证采集是否中断。
常见问题（FAQ）
Q：auth.log 每小时几千条 Failed password，正常吗？
对公网服务器完全正常——全球扫描器 7×24 小时在跑。关键不是"有没有"，而是有没有针对真实存在用户名的高频尝试、以及是否出现成功登录。这正是要用监控器而非人眼盯的原因。
Q：sudo 提权操作也需要监控吗？
需要。sudo 记录是内部权限审计的证据，但不一定记录提权 shell 内的每条命令，建议对"COMMAND 含敏感操作（如 visudo、useradd、写 /etc）"配置日志检测规则。
Q：认证日志里会记录密码明文吗？
正常 sshd 认证日志不应记录明文密码，但 PAM 模块、自定义脚本及错误日志仍需核查。但若把 sshd 的 LogLevel 调到 DEBUG3 等过高级别，可能记录敏感细节，生产日志级别应按审计需求确定，并验证脱敏和访问权限。
Q：多台服务器的认证日志能统一告警吗？
可以。DataKit 上报时通过 service/source 与主机标签区分来源，检测规则按查询范围筛选主机，并按主机字段分组；先确认目标主机均有数据，再验证告警中的来源标识。
系列阅读：SSH 日志管理与安全分析 ｜ 防止敏感数据进入日志
[1]: 观测云文档《日志采集》https://docs.guance.com/integrations/logging/
[2]: 观测云文档《DataKit 日志采集综述》https://docs.guance.com/integrations/datakit-logging/
[3]: 观测云文档《日志查看器》https://docs.guance.com/logs/manag-explorer/
[4]: 观测云文档《日志检测》https://docs.guance.com/monitoring/monitor/log-detection/
