一、一行参数，决定你的服务器扛不扛得住爆破

只要服务器开着 SSH 暴露在公网，日志里就会出现持续的密码爆破尝试——这是所有 Linux 运维的日常。fail2ban 的作用就是把这个"人工盯日志"的过程自动化：日志里谁反复失败，就自动把谁的 IP 封掉一段时间。

而整个自动化的核心开关，就是今天的主角——maxretry（最大重试次数）：它在问一个简单的问题："同一个 IP，失败多少次之后，我就不该再给它机会了？"

这个数字设太大，爆破者多拿几次机会；设太小，输错密码的自己人先被封。本文讲清楚它的准确定义、与另外两个参数的联动关系、各场景的推荐值，以及最容易踩的坑。

二、一分钟看懂 fail2ban 的工作循环

监控日志（jail 指定日志源）
   → filter 正则匹配"失败"记录（如 SSH 登录失败）
   → 同一 IP 的失败在 findtime 时间窗口内计数
   → 达到 maxretry 次 → 触发封禁
   → 封禁时长 = bantime（防火墙规则拦截该 IP）
   → bantime 到期解封（或用 recidive 策略对惯犯加重）

三个核心参数由此形成"铁三角"：

三者的联动关系用一个例子说清：maxretry=5, findtime=10m, bantime=1h 意思是——同一 IP 在 10 分钟内失败 5 次，即被封禁 1 小时。

两个容易忽略的细节：

1. 计数在窗口内滑动：窗口内没凑满次数，计数会随着旧记录滑出窗口而回落——不是"累计一辈子"，这避免了老账重算；
2. 按 IP 分别计数：不同 IP 互不影响；爆破者换 IP，就要从零开始攒次数——所以单靠 fail2ban 防分布式爆破有限，它是"防单点蛮力"的工具。

三、maxretry 的准确语义与配置方式

3.1 它数的是"filter 匹配到的记录"，不是"登录次数"

这是最常见的理解偏差。maxretry 计数的是filter 正则在日志里匹配到的行数。也就是说：

• 如果 filter 匹配的是"Failed password"，那数的是密码错误次数；
• 如果 filter 还匹配了"Invalid user"（无效用户名），无效用户名的尝试也会计入；
• filter 写得太宽，会把正常行为也算进去——调 maxretry 之前，先确认 filter 匹配的是什么。

3.2 配置写在哪里：jail.local 优先

不要直接改 jail.conf（升级会被覆盖），规范做法是写 jail.local 或 jail.d/ 下的独立文件：

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 3
ignoreip = 127.0.0.1/8 你的管理IP

[sshd]
enabled = true
maxretry = 3

优先级：jail.d/*.local > jail.local > jail.conf。改完记得 systemctl reload fail2ban（或 restart）。

3.3 验证配置是否生效的三个命令

# 查看某个 jail 的状态：当前封禁列表、累计失败总数
fail2ban-client status sshd

# 测试 filter 正则能否匹配你的真实日志（调 maxretry 前必做）
fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

# 查看某个 jail 实际生效的 maxretry 值
fail2ban-client get sshd maxretry

第三条尤其有用：它返回的是实际生效值，能立刻发现"改了 jail.local 但没生效"的问题。

四、各场景推荐配置

三条配套原则，比 maxretry 的数字本身更重要：

1. 白名单（ignoreip）永远先于阈值配置：把运维出口 IP、监控探测源加进去，否则"防御上线、自己被封"是新手第一大事故；
2. 对惯犯加重：默认 bantime 到期就解封，惯犯可以反复来。启用 recidive jail：在固定窗口内被封多次的 IP，处以天级/周级长封；
3. fail2ban 是止血，不是治愈：封禁解决的是"持续被爆破"，根治靠改 SSH 密钥登录、改默认端口、收敛暴露面（呼应本站《海外服务器 IP 被封》一文的"源头清理"思路）。

五、常见误区与排查

误区一：改了配置没生效。原因通常是写在 jail.conf 里被覆盖、或忘记 reload。用 fail2ban-client get <jail> maxretry 核对实际生效值。

误区二：maxretry=1，结果自己被封。一次失败就封会把输错密码的管理员、正常的认证抖动都拦下。除非服务只允许密钥认证，否则不建议低于 3。

误区三：只防了 IPv4。爆破越来越多来自 IPv6，检查 jail 的日志源与 backend 是否覆盖 v6 记录。

误区四：backend 与日志源不匹配。新版系统日志进了 journal，jail 还在追旧文件路径——什么都匹配不到，maxretry 永远达不到。

误区五：误封后不知道怎么解。应急解封：fail2ban-client set sshd unbanip <IP>；长期方案是加入 ignoreip。这两条命令应写进团队运维手册。

六、自查清单

• fail2ban-client status 确认服务在运行、关键 jail 已启用
• 用 fail2ban-client get <jail> maxretry 核对各 jail 实际生效值
• ignoreip 已加：本机回环、运维出口 IP、监控探测源
• filter 正则用 fail2ban-regex 对真实日志验证过（能匹配、不误匹配）
• backend 与日志源匹配（systemd journal 或文件路径）
• SSH 已优先考虑密钥登录；密码登录场景 maxretry ≤ 3
• recidive jail 已启用，惯犯长封策略生效
• 解封命令（unbanip）与白名单修改流程已写入运维手册
• 定期查看封禁统计：长期零封禁可能说明 filter 失效，而不是"很安全"

七、常见问题（FAQ）

Q1：maxretry 的默认值到底是 3 还是 5？

因 fail2ban 版本而异，老版本常见 3，较新版本常见 5，且各发行版打包可能再改。不要背数字，用 fail2ban-client get <jail> maxretry 查你系统的实际生效值。

Q2：maxretry、findtime、bantime 的关系再确认一遍？

同一 IP 在 findtime 窗口内失败达到 maxretry 次，即封禁 bantime 时长。例如 3 / 10m / 1h：10 分钟内错 3 次，封 1 小时。窗口内没凑满，旧记录滑出后计数回落。

Q3：maxretry 设成 1 更安全吗？

不推荐。一次失败就封会误伤输错密码的真实用户和正常的认证抖动；而且攻击者换 IP 的成本远低于你处理误封的成本。SSH 场景 3 次是经验平衡点，根治靠密钥登录。

Q4：被封的 IP 过了 bantime 还会再来，怎么办？

启用 recidive jail：统计"被封的次数"，反复被封的 IP 施以天级/周级长封。注意 recidive 监控的是 fail2ban 自己的日志，配置时确认其日志源可用。

Q5：自己被误封了，怎么解？

立即解封：fail2ban-client set <jail> unbanip <你的IP>；然后把 IP 加入 ignoreip 并 reload，避免复发。如果连 SSH 都进不去了，需要通过服务商控制台/VNC 处理——这就是为什么白名单必须先配。

Q6：fail2ban 能防分布式爆破（很多 IP 各试几次）吗？

作用有限。maxretry 按 IP 计数，分布式爆破让每个 IP 都低于阈值。应对思路不同：SSH 改密钥认证（爆破失效）、结合威胁情报封段、以及收敛暴露面。

Q7：filter 匹配不到日志，maxretry 永远达不到，怎么排查？

三步：确认 jail 的 logpath/backend 与系统日志实际位置一致；用 fail2ban-regex 手动跑正则验证；检查日志时间格式是否被正确解析。长期"零封禁"往往不是安全，而是 filter 失效。

Q8：fail2ban 和云防火墙/安全组的黑名单是什么关系？

互补。fail2ban 在主机侧基于日志精细封禁，云防火墙/安全组在网络侧粗粒度控端口来源。对被持续爆破的公网服务器，主机侧 fail2ban 反应最快；但规模化的攻击防护仍需上游能力（参考本站 UDP Flood、SYN Flood 系列）。

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务，全网第一款指纹识别技术防火墙，自研的WAF指纹识别架构，提供任意CC和DDoS攻击防御