fail2ban 是免费开源的主动防御工具，部署在服务器上能自动监控日志、封禁暴力破解和扫描行为，对个人站长和中小团队来说几乎零成本，尤其在国内云服务器上，SSH 爆破和面板撞库的防御效果立竿见影。
服务器只要带公网 IP 跑个两三天，/var/log/auth.log 或 /var/log/secure 里就会多出一堆不明来源的失败登录记录，这些不是人肉攻击，而是自动化扫描器在批量探测弱口令和开放端口，与其每天手动翻日志、手动封 IP，不如让 fail2ban 自己盯日志、自己拉黑。
fail2ban怎么用才能挡住大部分扫描嗅探？
fail2ban 的原理不复杂：它读取服务日志，发现某个 IP 在设定时间窗口内失败次数超过阈值，就调用防火墙后端把这个 IP 封禁一段时间，它的核心不是人写的固定规则，而是把“观察行为-作出决策-执行封禁”这个过程自动化了。
安装和基础配置路径
不同系统的安装命令略有差异。
- Debian/Ubuntu：
apt install fail2ban -y - CentOS 7/8：先装 EPEL，再执行
yum install fail2ban -y - 启动并设置开机自启：
systemctl enable --now fail2ban
主程序装完后，默认只带一个 jail.conf 示例，真正生效的配置建议写在 jail.local 里，它会覆盖同名参数,升级软件时也不容易被冲掉。
实战配置：SSH 防爆破
新建或编辑 /etc/fail2ban/jail.local,写入下面这份基础配置。
[DEFAULT]
bantime = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1 你的办公IP
[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
backend = autofindtime = 600：10 分钟窗口maxretry = 5：10 分钟内失败 5 次bantime = 600：封禁 10 分钟ignoreip：白名单，避免把自己办公网络的出口 IP 封掉
CentOS 系服务器要改 logpath = /var/log/secure，Debian/Ubuntu 默认是 /var/log/auth.log，如果系统日志走 journald，可以把 backend 改成 systemd。
保存后重启 fail2ban：
systemctl restart fail2ban
fail2ban-client status sshd如果输出里有 Currently banned: 1 这种字段，说明已经有 IP 被关进来了。
验证它真的在干活
别只看服务状态,直接看防火墙规则最直观。
iptables -L -n | grep fail2ban：能看到 fail2ban 自动插入的封禁链tail -f /var/log/fail2ban.log：实时观察封禁和解封动作fail2ban-client get sshd banip 1.2.3.4：手动封禁一个测试 IP
这套流程跑通之后，你会看到扫描器从疯狂撞库变成被封禁后彻底安静，多数情况下，只要 sshd jail 正常工作,就能挡住相当一部分自动化暴力破解。
fail2ban和iptables区别在哪？实际拦截靠谁
很多人一开始会问：我直接写 iptables 规则不行吗？为什么还要再装一层 fail2ban？
iptables 是内核层防火墙，负责按规则放行或丢弃数据包，fail2ban 是日志分析器，负责决定谁该被丢进去。 两者不是替代关系，而是分工关系，fail2ban 的后端默认就是 iptables，也可以切换成 nftables 或 firewalld。
直接写 iptables 规则的问题在于：你不知道攻击者下一分钟会换哪个 IP，手工封禁要么封不全，要么把规则写得很宽，误伤正常访问，fail2ban 可以逐 IP 判断、到期自动解封，也能把长期捣乱的 IP 用来延长封禁时间。
业内专家指出，单机防御的关键不是堆多少静态规则，而是能不能形成“日志-分析-封禁-审计”的闭环，fail2ban 做的正是这件事。
下表对比几种常见做法。
| 方式 | 自动化程度 | 误封风险 | 适用场景 |
|---|---|---|---|
| 手工写 iptables 规则 | 低 | 中 | 临时封单个 IP |
| 仅靠云安全组 | 低 | 低 | 控制端口和来源 |
| fail2ban | 高 | 中 | 单机暴力破解、扫描 |
| 云安全中心/高防 | 高 | 低 | 大流量攻击、业务级防护 |
简米云服务器上用fail2ban防暴力破解的真实记录
我手里一台简米云服务器，安全组只放开了 22、80、443 三个端口，每天 SSH 日志里照样会出现大量 Failed password 和 Invalid user 记录，这说明安全组只管“谁能连”，不管“连上之后试什么密码”。
那些盯着 22 端口的扫描器长什么样
典型日志长这样：
Failed password for root from 45.xx.xx.xx port 55231 ssh2
Invalid user admin from 103.xx.xx.xx port 42108这些 IP 来源很杂，有些是境外扫描器，有些是国内被挂马的主机，它们不是针对你，而是全网撒网，只要你的 SSH 密码稍微弱一点,很快就会被撞进去。
为什么安全组不能完全替代 fail2ban
安全组是网络边界，它不能判断登录失败次数，你能做的只有手动加 IP 段，或者把 22 端口改成仅允许特定来源访问，一旦你的办公网络 IP 变了,还得去改安全组。
fail2ban 的好处是跟着行为走，不管 IP 从哪来，只要失败次数超过阈值就封，配合安全组一起用，一个是边界收缩，一个是行为拦截,防御会更立体。
配置里的坑：为什么你的fail2ban不生效？
装完之后发现日志一直在涨，但 fail2ban-client status sshd 里封禁数始终是 0,这种问题很常见。
日志路径和 filter 不匹配
不同发行版的认证日志位置不同。
- Debian/Ubuntu：
/var/log/auth.log - CentOS/RHEL：
/var/log/secure - 使用 systemd 日志的系统：可能没有独立日志文件，需要
backend = systemd
logpath 指向不存在的文件，fail2ban 不会报错，但它什么都读不到，先 ls -l /var/log/ 确认目标日志确实在写入。
时间窗口设置不合理
findtime 设得太长，maxretry 设得太大，扫描器试探的频率没到阈值就没法触发封禁，常见配置是 findtime=600、maxretry=5，如果你的 SSH 端口非常规，扫描器可能每分钟只来两三次，可以适当把 maxretry 调低，或者把 findtime 拉到 1800。
白名单配置错误
ignoreip 没把自己的 IP 写进去，又恰好测试时输错几次密码，你可能会把自己锁在服务器外面，所以配置完成后先别急着退出当前 SSH 会话，另开一个终端测试登录,顺便确认白名单生效。
免费方案的成本账：fail2ban对比付费安全产品
价格方面，fail2ban 完全免费，开源协议宽松，不用按年付费，也不用按防护 IP 数量计费，对个人开发者、学生机、小团队站点来说,这是成本最低的单机主动防御方案。
付费的云安全中心和 DDoS 高防 IP 解决的是另外一层问题：大流量攻击、业务层 CC、多主机统一策略、恶意文件查杀，它们能提供更完善的情报库和人工响应,但价格对个人项目并不友好。
多数情况下，中小服务器先用 fail2ban 把 SSH、FTP、面板、Web 后台的爆破行为压下去，再用云服务商的基础安全组做端口收敛，就能挡住绝大多数自动化扫描，真正遇到海量 DDoS，再按需购买高防服务,不鼓励盲目上付费全家桶。
Q&A：关于fail2ban主动防御，这几个问题问得最多
fail2ban多久生效？封禁延迟会不会太久？
默认配置下，一个 IP 在 10 分钟内失败 5 次就会被封禁，对于高速撞库的扫描器，通常几十秒内就触发了，如果觉得慢，可以把 maxretry 调到 3，findtime 保持 600,封禁会更及时。
fail2ban能防CC攻击吗？
不能完全防，CC 攻击是海量分布式请求，源 IP 分散，单个 IP 的请求频率不一定触发失败阈值，fail2ban 擅长对付单 IP 的暴力破解和扫描，对真实 CC 流量基本无能为力，多数情况下，CC 防护得靠 WAF 或专门的高防服务。
fail2ban和DenyHosts哪个好？
DenyHosts 主要面向 SSH，功能相对单一，近年维护节奏也慢，fail2ban 支持各种服务的日志过滤器和多种防火墙后端，适用范围广得多，行业共识认为 fail2ban 是目前单机主动防御的事实标准。
服务器只要还在公网上，就会被扫，把 fail2ban 装好、调好、验证好，等于让一个不休息的门卫替你盯着所有可疑行为，它不承诺挡住所有攻击,但能把那些自动化扫描和撞库的噪音压到最低。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/655349.html
