Fail2Ban阻断日志是攻击行为原始数据源，需从中提炼策略、节奏与目标偏好以优化防护逻辑；应分析IP频次、jail分布、时间集中性，关联源日志识别攻击手法，利用recidive识别高危持续威胁，并动态校准阈值。

Fail2Ban 的阻断日志不是封禁记录的终点，而是攻击行为的原始数据源。真正有价值的是从中提炼出攻击者的策略、节奏和目标偏好，再反向优化防护逻辑——而不是只看“今天封了多少IP”。

从 /var/log/fail2ban.log 中提取有效模式

该日志记录每次 ban/unban 动作，包含时间、jail 名称、IP、动作类型等字段。关键不是统计总数，而是识别重复出现的特征：

• 用 grep "Ban" /var/log/fail2ban.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -10 查看被封次数最多的 IP，判断是否为真实累犯（而非扫描器轮换IP）
• 用 grep "Ban" /var/log/fail2ban.log | awk '{print $5}' | sort | uniq -c | sort -nr 统计各 jail（如 sshd、apache、recidive）触发频次，确认主攻服务
• 结合时间戳分析集中爆发时段，例如连续三天凌晨 3:15–3:22 出现多 jail 同时 ban，大概率是定时脚本攻击

关联原始服务日志定位攻击手法

Fail2Ban 只是响应者，真正的攻击痕迹藏在它监控的源日志里（如 /var/log/auth.log 或 /var/log/secure）。必须交叉验证：

• 对某高频被封 IP，执行 grep "192.168.1.100" /var/log/auth.log | tail -20，观察是尝试 root/admin/test 等通用账户，还是针对特定用户名暴力枚举
• 检查失败行中的 port 字段：若端口随机跳变（54232 → 54234 → 54236），说明攻击者在规避连接限制；若固定端口但用户名变化剧烈，则属典型字典攻击
• 留意是否有 “Invalid user” 和 “Failed password for user” 混合出现——前者常为探测阶段，后者才是真实撞库起点

用 recidive jail 发现高危持续性威胁

默认的 sshd jail 只管单次会话内的失败，而 recidive 是专门抓“屡教不改者”的机制。它的日志直接写入 fail2ban.log，格式为 NOTICE [recidive] Ban xxx.xxx.xxx.xxx：

• 一旦发现 recidive 触发，说明该 IP 已在 24 小时内被其他 jail 封禁 ≥5 次（可调），属于高置信度恶意源
• 建议将 recidive 的 bantime 设为 604800（7 天）以上，并配合 action=iptables-allports 彻底封锁所有端口，而非仅限 SSH
• 若 recidive 封禁 IP 中大量来自同一 C 段（如 185.143.224.0/24），可考虑在防火墙层主动屏蔽整个网段

建立攻击画像并调整核心阈值

不要依赖默认的 maxretry=5、findtime=600。应根据实际日志分布动态校准：

• 若合法用户偶尔输错密码（如运维批量操作时），但 fail2ban 频繁误封，说明 findtime 过短或正则太宽——需收紧 filter.d/sshd.conf 中的 failregex，排除 sudo 认证失败等干扰项
• 若攻击者每轮只试 3 个密码，间隔 3 分钟发起下一轮，而你的 maxretry=5、findtime=600 就形同虚设——应改为 maxretry=2、findtime=1800（30 分钟）提高敏感度
• 对暴露在公网的服务器，可启用双重惩罚：普通 jail 封 1 小时，recidive 封 7 天，形成“试探即重罚”的威慑节奏