Fail2Ban是日志驱动型应急响应触发器，专注秒级自动阻断有日志证据的入侵行为；监控工具负责宏观预警，二者分工协作实现“监控→发现→响应”闭环。
Fail2Ban 本身不是监控系统，但它天然适合作为日志驱动型应急响应的“触发器”。它不采集指标、不画图表，而是把系统日志当作实时事件流，一旦识别到攻击模式（如 SSH 连续失败、Nginx 404 扫描、FRP 非法连接），立刻调用防火墙或脚本执行阻断动作。真正实现“监控→发现→响应”闭环，关键在于让它和系统监控工具形成职责分工：监控工具负责长期趋势与异常告警，Fail2Ban 负责秒级自动处置。
明确角色边界，避免功能重叠
Fail2Ban 不替代 Prometheus/Grafana 或 Zabbix，也不该用来做 CPU/内存预警。它的定位很清晰：只响应“已发生的、有明确日志证据的入侵行为”。比如：
- Zabbix 发现某台服务器 SSH 登录失败次数突增 300%，发邮件提醒管理员 → 这是宏观预警
- Fail2Ban 在同一台机器上，从
/var/log/secure实时读到第 3 条Failed password for root，立即封 IP → 这是微观拦截
两者配合，前者让人“知道出事了”，后者让人“不用动手就止损”。
让 Fail2Ban 输出可被监控系统采集的日志事件
默认情况下，Fail2Ban 的封禁动作只写入 /var/log/fail2ban.log，但监控平台很难直接解析。建议统一输出到 syslog，并打上结构化标签：
- 编辑
/etc/fail2ban/fail2ban.conf，设为：logtarget = SYSLOG syslogsocket = auto
- 在
/etc/rsyslog.d/50-fail2ban.conf中添加转发规则（以接入 ELK 或 Loki）：:programname, isequal, "fail2ban" /var/log/fail2ban-events.log & stop
这样每条封禁记录都会带
jail=sshd,ip=192.168.3.45,bantime=86400等字段，便于监控平台做聚合统计、地理分布热力图或关联分析。
联动执行层：不止封 IP，还能触发更多响应动作
Fail2Ban 的 action 机制支持链式调用。除了默认的 firewallcmd-ipset，你可以在 action.d/ 下自定义脚本，实现：
- 封 IP 同时向企业微信/钉钉发送含攻击详情的卡片消息
- 检测到 FRP 异常连接后，自动调用
frpcAPI 断开对应客户端会话 - SSH 被封时，自动提取该 IP 最近 5 分钟的所有登录尝试用户名，写入审计数据库
示例动作配置（/etc/fail2ban/action.d/notify-webhook.conf）：[Definition] actionstart = actionstop = actioncheck = actionban = curl -X POST -H "Content-Type: application/json" \ -d '{"msg": "Blocked %(ip)s on %(jail)s, retry=%(maxretry)s"}' \ https://your-webhook-url actionunban =
日志源协同：让监控工具帮 Fail2Ban 更准地“看见”攻击
有些攻击不会直接留下认证失败日志（例如利用 Nginx 伪静态漏洞绕过登录）。这时可借助监控工具前置过滤：
- Prometheus + node_exporter 监控
/var/log/auth.log文件增长速率，若 1 分钟内新增行数 > 200，触发 alert - Alertmanager 将该事件推给一个轻量脚本，临时提高 Fail2Ban 对
sshdjail 的maxretry到 1，缩短findtime到 60 秒，进入“高敏模式”
相当于监控系统在“喊一声：小心！”，Fail2Ban 立刻切换成更激进的防御姿态。
不复杂但容易忽略
