应优先检查 /var/log/auth.log（Ubuntu/Debian）或 /var/log/secure（CentOS/RHEL）中“Failed password”日志，结合 lastb 统计攻击 IP、grep“Accepted password”排查异常登录，并部署 fail2ban 实时封禁。
直接看 /var/log/auth.log 里有没有“Failed password”
绝大多数异常登录行为，第一眼就藏在这行日志里：Failed password。它代表密码错误的 SSH 登录尝试，是暴力破解最典型的痕迹。不是所有系统都用这个路径——Debian/Ubuntu 系统用 /var/log/auth.log，CentOS/RHEL 则常用 /var/log/secure，先确认你的发行版再开查。
- 快速验证命令：
grep "Failed password" /var/log/auth.log（或换为/var/log/secure） - 别只扫一眼：加
| wc -l看总数，比如grep "Failed password" /var/log/auth.log | wc -l，单小时超 10 次就该警觉 - 常见坑：有些攻击用密钥登录失败，日志里是
Permission denied (publickey)，漏掉这个就等于漏掉一半线索 - 注意大小写：部分日志写的是
failed password（小写），建议用grep -i "failed password"更稳妥
用 lastb 和 awk 统计高频攻击 IP
lastb 是专为爆破设计的命令，它直接读取 /var/log/btmp（二进制失败登录日志），比 grep auth.log 更快、更准，且不依赖文本格式解析。
- 查最近 50 条失败记录：
lastb -n 50 - 按 IP 统计攻击次数：
lastb | awk '{print $3}' | sort | uniq -c | sort -nr | head -10 - 为什么 不用
grep提取 IP？因为auth.log中 IP 字段位置不固定（比如 IPv6、域名、无 IP 的本地登录），lastb输出结构统一，字段稳定 - 注意：
lastb需要 root 权限；若返回空，可能是btmp被清空或服务未启用，别误判为“没攻击”
识别“Accepted password”里的异常模式
成功登录不等于安全——异常时间、陌生 IP、非活跃用户，都可能意味着账号已失守。重点不是“有没有登录”，而是“谁在什么时候从哪登的”。
- 提取所有成功登录的 IP 和用户名：
grep "Accepted password" /var/log/auth.log | awk '{print $11, $9}' | sort | uniq -c | sort -nr - 检查非工作时间登录：用
awk '$1 ~ /^(Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)$/ && $3"22:00"{print}' /var/log/auth.log（粗筛凌晨 / 深夜） - 警惕“幽灵用户”：运行
awk -F: '$3 == 0 {print $1}' /etc/passwd查 UID 0 用户，再比对auth.log里是否有人用这些账户登录 - 容易忽略的点：某些攻击会复用合法用户（如
www-data）做横向移动，别只盯着root和管理员账户
别只靠手动查——fail2ban 是必开的兜底防线
人工翻日志永远滞后，而 fail2ban 能实时盯住 auth.log，发现三次失败就封 IP，把大部分自动化攻击挡在门外。它不是可选项，是生产环境基础配置。
- 最小可用配置只需改三处：
maxretry = 3、findtime = 600（10 分钟内）、bantime = 3600（封 1 小时） - 务必确认
logpath指向正确日志：Ubuntu 写/var/log/auth.log，CentOS 写/var/log/secure，写错等于白装 - 启动后验证是否生效：
sudo fail2ban-client status sshd，看Number of jail是否 >0 - 最大误区：以为开了
fail2ban就高枕无忧——它只防爆破，不防社工、不防已泄露的密钥、不防内网横向渗透
真正难防的不是成百上千次的失败登录，而是某天凌晨 3:17，一个你从没见过的 IP，用正确的密码，以普通用户身份登进来，删了日志又改了 ~/.bash_history。这时候，auditd 或集中式日志（如 ELK）才是最后一道卡口——但那是另一个问题了。
