为什么要先聚合来源 IP
面对大批失败登录，先按来源 IP 聚合再看分布：计数排名能区分「单点暴力」与「分布式扫描」，也直接决定封禁策略是否有效。但要记住封 IP 只是止血——尤其要警惕 NAT 与云出口，封掉一个地址可能误伤整个网点的正常用户。
基本信息
| 统计手段 | grep + awk + sort | uniq -c 计数 |
|---|---|
| 常见日志 | /var/log/auth.log（Debian 系）、/var/log/secure（RHEL 系） |
| 封禁手段 | fail2ban、firewalld rich rule、iptables、ufw、Nginx deny、上游 WAF |
| 误伤风险 | NAT 出口、云厂商共享地址、企业代理由此封禁易误伤 |
| 根治方向 | 禁用口令认证、仅允许密钥、限制来源网段 |
| IPv6 | 必须一并统计与处置，日志里两类地址同时存在 |
典型使用场景
- 失败登录量激增时判断是单点爆破还是分布式扫描
- 决定封禁名单与封禁粒度：封单个地址还是整个网段
- 评估现有 fail2ban 等自动封禁机制是否真的生效
- 长期巡检中识别持续尝试的固定来源
- 与业务正常来源比对，避免把合作方地址封掉
- 整理成 IoC 清单交给边界设备统一拦截
聚合来源并查看现有封禁
聚合来源并查看现有封禁
grep -h 'Failed password' /var/log/auth.log* | grep -oE 'from [^ ]+' | awk '{print $2}' | sort | uniq -c | sort -rn | head -n 20
sudo fail2ban-client status sshd 2>/dev/null # 自动封禁状态与名单
sudo firewall-cmd --list-rich-rules 2>/dev/null | grep -i drop # 现有 rich rule
sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=203.0.113.0/24 drop'
sudo firewall-cmd --reload # 使规则生效
grep -h 'Failed password' /var/log/auth.log* | grep -c ':' # 粗看 IPv6 来源占比聚合结果读法
| 维度 | 含义 | 判读要点 |
|---|---|---|
| 计数 | 该来源的失败次数 | 数百以上即为自动化爆破 |
| 来源 IP | 尝试来源地址 | 集中在少数地址是单点，离散则是分布式 |
| 尝试账号 | 被猜解的账号名 | root、admin 等通用名说明是字典爆破 |
| 时间分布 | 尝试发生的时刻 | 全天持续说明脚本化运行 |
| 目标服务 | 被攻击的端口 | 22 最常见，也可能指向 3389 等 |
分布式爆破里每个 IP 的计数都不高，很容易被阈值型告警漏掉：此时改看账号维度的失败总量，以及有没有出现成功登录。
封禁前先确认不是合作方、监控探针或 NAT 出口：误封共享出口会影响整片区域访问。处置顺序应为先限制来源网段，再逐条封禁。