SSH 密钥换上了、22 端口也改了，可爆破流量照样天天来。装个自动封 IP 的工具之前，选型问题摆在面前：老牌的 fail2ban 还能用，新一代的 CrowdSec 来势汹汹，差在哪、差多少？
这篇文章从架构、检测能力、资源占用、上手成本四个维度把两者摆在一起比，最后按场景给结论。fail2ban 的基础用法见「fail2ban 防爆破实战」，全景加固清单见「服务器安全加固」。
一张表看懂核心差异
| 维度 | fail2ban | CrowdSec |
|---|---|---|
| 架构 | 日志正则匹配 + 防火墙动作，单机进程 | 解析器 + 情景引擎 + 本地 API + 封禁组件，四层分离 |
| 检测能力 | 依赖预置 filter 正则，主要抓单一重复模式 | 解析日志后按多步情景（scenario）判断行为序列 |
| 情报共享 | 无 | 可接入社区网络共享 IP 信誉，本地自动拉取社区黑名单 |
| 生态组件 | jail 概念统一管理，生态集中在 filter 配置 | bouncer 覆盖 iptables/nftables、Nginx、Cloudflare 等更多执行点 |
| 上手成本 | 低，装完配 jail.local 即可用 | 中，需要理解 LAPI、bouncer、enroll 等新概念 |
| 资源占用 | Python 单进程，小内存机器可用 | Go 编译二进制，官方最低配置 512MB 内存 / 1 核 CPU |
维度一：架构决定封禁的上限
fail2ban 的所有工作围绕「读日志、匹配正则、改防火墙」这一条链。jail 把 filter（正则模板）和 action（封禁动作）绑在一起，匹配到就调 iptables 插规则。单机 SSH 防爆破够用，多余的正则还可能拖慢大日志量机器的匹配。天花板也在这里：它看到的世界就是日志文本，日志里没有的信息它一概不知。
CrowdSec 拆成四层。解析器把原始日志转成结构化事件，HTTP 请求路径、登录尝试都进同一个事件模型，情景引擎在事件流上跑多步检测逻辑，本地 API 存决策，bouncer 读决策去执行封禁。层与层解耦，同一套检测结果可以喂给防火墙、Nginx、CDN 好几个执行点。检测和封禁分开后，封禁不再受限于本机日志能看到什么。
维度二：检测模式，多步行为 vs 单点重复
fail2ban 的 filter 是正则模板，默认规则主要抓「同一 IP 在时间窗口内重复 N 次同一类事件」：SSH 爆破、web 扫描都靠这个套路。优点是逻辑透明，fail2ban-regex 能直接拿日志样本测正则。局限是行为序列类的攻击抓不住——多步动作序列（探测、试弱口令、撞库），单条正则表达不了。
CrowdSec 把这类逻辑写成 scenario，多步行为判断是它的主场。HTTP 探测系列（http-probing、http-bad-user-agent、http-crawl-non-statics）、暴力破解系列（smb-bruteforce、mysql-fail2ban 等按服务拆分）、端口扫描、以及专门抓扫描器指纹的 combo 场景，官方 Hub 里都有现成条目。
表面看 fail2ban 缺场景，官方 Hub 里现成的 scenario 集合直接补齐。装完 CrowdSec 再跑一次 cscli scenarios list，能看到的检测条目远多于 fail2ban 预置 filter 能覆盖的范围。
维度三：资源占用与部署方式
CrowdSec 是 Go 编译的单二进制，官方文档的最低配置是 512MB 内存、1 核 CPU，官方仓库一条脚本装好，Ubuntu 24.04 上需要留意仓库优先级——系统自带源里的 1.4.6 是老版本，装之前先 apt-cache policy crowdsec 确认候选项来自官方仓库，必要时写 pinning 把它提到 1001。装完还要单独装封禁组件。防火墙层用 crowdsec-firewall-bouncer-iptables，Web 层有 Nginx/OpenResty/Traefik 各自的 bouncer。
| 对比项 | fail2ban | CrowdSec |
|---|---|---|
| 安装 | apt install fail2ban | 加官方仓库 + 装 engine + 装 bouncer，三步 |
| 内存 | Python 进程，几十 MB 量级 | Go 二进制，官方最低 512MB 内存的机器即可 |
| 版本时效 | Ubuntu 24.04 仓库 1.0.2，多年未动 | 官方仓库持续发新版本 |
| 配置入口 | /etc/fail2ban/jail.local | /etc/crowdsec/ 下的 acquisition、profiles 等 YAML |
部署链路 CrowdSec 更长，代价换来的是版本时效性和执行点的多样性。Ubuntu 24.04 源里的 fail2ban 1.0.2 长期没动，新 filter 规则修复要等发行版同步。对安全工具来说，版本停滞本身就是减分项。
维度四：情报共享改变游戏规则
fail2ban 各台机器独立作战。每个管理员都要单独面对同一批扫描器，防来防去都是同一群人。CrowdSec 的社区模式把这件事变成共享的：本地引擎发现恶意 IP 后可以选择回传（信号），同时自动拉取社区黑名单，别人踩过的坑你这边直接免疫。CrowdSec 的付费层有更全的企业级情报，社区版免费。对个人服务器来说，社区版给的部分已经值回部署成本。
对单机用户，这条社区黑名单的实际价值在于把防御从「等到被打才知道」变成「来之前就已拉黑」。多机场景收益更大：一台机器上的新发现，全局生效。
分场景结论
| 你是谁 | 选哪个 | 为什么 |
|---|---|---|
| 只有一台 VPS，主要防 SSH 爆破 | fail2ban | 五分钟配完，Python 单进程轻，够用 |
| 想要 Web 层防护（Nginx/反代前的应用） | CrowdSec | bouncer 直接挂 Nginx，scenario 覆盖 HTTP 攻击模式 |
| 手里有多台服务器要统一防护 | CrowdSec | 社区黑名单 + 本地 API 集中决策，跨机共享天然支持 |
| 服务器内存 ≤1G 且不想引入新概念 | fail2ban | 无学习成本，jail.local 改几行就能跑 |
| 介意 fail2ban 开发停滞、想要持续更新的规则库 | CrowdSec | 官方仓库滚动更新，Hub 情景集持续迭代 |
混用也成立：fail2ban 眡 SSH，CrowdSec 管 Web 层，两者写各自的防火墙规则互不冲突。不过单机上跑两套日志检测纯属浪费，选定一个往下走更干净。
常见问题
Q：fail2ban 还在被维护吗？ Ubuntu 24.04 源里是 1.0.2，上游开发近年明显放缓。新功能基本没有，旧规则仍然可用。介意维护状态的话，CrowdSec 是当前的活跃替代。
Q：CrowdSec 免费吗？社区黑名单要注册吗？
安全引擎和社区黑名单免费。接入社区网络需要注册账号并 enroll，本地注册 cscli console enroll <token> 即可；不 enroll 也能用，只是拿不到社区情报和 Console 面板。
Q：两者能共存吗？ 技术上没有冲突，封禁都落在防火墙层。但两套工具重复解析同样的日志，资源浪费。规则打架排查起来也麻烦，建议单机选定一个。
Q：CrowdSec 只装 engine 不装 bouncer 会怎样？ 什么都不会封。engine 是纯检测组件，决策存在本地 API 里，必须有 bouncer 去执行——这是 CrowdSec 新手最常见的翻车点。
Q：小内存机器跑 CrowdSec 现实吗？ 官方最低配置 512MB 内存、1 核 CPU，2 核 2G 的机器在官方标准之内。再往下（1G 整机）建议 fail2ban。
结尾一句话：fail2ban 是「每台机器自己扛」，CrowdSec 是「全网一起扛」。只有一台机器、只防 SSH，fail2ban 装完就能收工；只要涉及 Web 层、多机或者想要持续更新的检测规则，CrowdSec 值得多花的那些部署步骤。
