SSH 爆破日志分析与成功判定

SSH 爆破日志分析

SSH 爆破几乎发生在每一台暴露到公网的主机上，所以「失败次数多」本身不构成事件。真正要回答的是三个问题：有没有成功登录、成功的是哪个账号、成功后执行了什么。分析方法是先按来源 IP 与目标账号聚合失败记录，再把时间窗前后推一步去看有没有对应的 Accepted 记录——只统计失败量的报告对处置没有任何指导意义。

基本信息

日志位置	Debian 系 /var/log/auth.log，RHEL 系 /var/log/secure，部分系统在 journald
失败关键字	Failed password、Invalid user、Authentication failure、Connection closed by authenticating user
成功关键字	Accepted password、Accepted publickey、session opened for user
轮转文件	auth.log.1 与压缩后的 .gz 需用 zgrep 检索，否则历史窗口被截断
时间基准	日志使用系统本地时区，分析前先确认时区并统一为 UTC
辅助证据	last、lastb、authorized_keys 的 mtime、sudo 日志、命令历史

典型使用场景

安全设备告警提示某 IP 高频登录失败，需要判断是否已突破
主机出现陌生外联，回溯登录入口确认是否为 SSH 密码爆破得手
评估现有加固策略（密钥认证、来源限制、失败锁定）是否有效
统计被尝试的账号名，判断是随机字典还是针对本单位账号的定向尝试
为边界封禁与告警规则优化提供依据

失败聚合与成功对照

grep -h 'Failed password' /var/log/auth.log* 2>/dev/null | grep -oE 'from [0-9.]+' | awk '{print $2}' | sort | uniq -c | sort -rn | head -n 10   # 失败来源
grep -h 'Invalid user' /var/log/auth.log* 2>/dev/null | grep -oE 'user [^ ]+' | sort | uniq -c | sort -rn | head -n 10                          # 被尝试的账号
sudo grep -hE 'Accepted (password|publickey)' /var/log/auth.log* 2>/dev/null | tail -n 20                                                        # 成功登录
sudo zgrep -h 'Accepted' /var/log/auth.log.*.gz 2>/dev/null | tail -n 20                                                                          # 轮转历史也要看
sudo grep -E 'Accepted|session opened' /var/log/auth.log | head -n 5                                                                               # 确认日志格式与字段位

日志行读法

字段	含义	异常信号
时间戳	月日时:分:秒，本地时区	与告警时间、文件落地时间对齐才有意义
主机名	写日志的主机	集中式日志里用于区分来源主机
进程与 PID	sshd 与进程号	同一 PID 连续大量失败说明是同一条连接在重试
动作	Failed password、Invalid user、Accepted、session opened	失败与成功混合出现最需要警惕
用户名	认证目标账号	root、admin 以及本单位真实账号被尝试属定向攻击
来源 IP 与端口	客户端地址与源端口	同一 IP 变换端口反复尝试是自动化工具特征
认证方式	password 或 publickey	publickey 成功时要顺带核对公钥指纹是否在台账内

判定口径要写死：同一来源在短时间内先出现大量 Failed password，紧接着出现 Accepted，就按「已突破」处理，立即进入账号处置流程——核查该账号的密钥文件、命令历史、sudo 记录与新增进程，而不是先去封 IP。

密钥登录也要核指纹：Accepted publickey 行会带出密钥类型与指纹，把它与 authorized_keys 里的指纹、运维台账逐条比对，能发现「密钥认证被滥用」这类密码爆破之外的入口。

突破后的动作核对

sudo last -aiF -n 20                                    # 该来源是否有真实会话
sudo ls -l --time-style=full-iso /root/.ssh /home/*/.ssh 2>/dev/null | head -n 20   # 密钥文件改动时间
sudo grep -rE 'sudo:\s+[^:]+:' /var/log/auth.log | tail -n 10    # 是否使用了 sudo
sudo tail -n 200 /root/.bash_history 2>/dev/null         # 登录后执行了什么
sudo ss -antp | grep -E 'ESTAB' | head -n 20             # 当前是否仍有回连

封禁要区分噪声源：监控探针、漏扫平台与堡垒机也会持续产生失败记录，先与台账核对来源再批量封禁，避免误封导致监控盲区。

结论建议写成三行便于交接与复核：尝试来源与总量、是否出现成功登录、成功之后执行了什么动作。只写「存在大量爆破尝试」的结论既无法支撑后续处置，也无法评估加固措施是否有效。

排查时间窗建议覆盖告警时间前后各 24 小时，并把上一次轮转的文件一起纳入，否则容易漏掉真正的首次尝试时间。