这两个工具都读日志、都封地址，乍一看 CrowdSec 就是代码更新一些的 Fail2ban。它们之间的差别比这要根本得多，而且不在代码的年纪上，而在封禁这个决定是从哪里来的。
它们是怎么构成的
Fail2ban 是一个单独的进程，它读日志、数正则匹配次数，然后调用防火墙命令。每一个决定都在你的机器上、依据你自己的计数器做出。什么也不往外发，没有依赖，配置就是文本文件。
CrowdSec 被拆成了两部分，而这正是安装之前最需要理解的一点。代理本身只负责发现：它分析日志、套用场景，并把决定写进自己的数据库。执行决定的是另一个程序，叫 bouncer。而不装 bouncer 的话，CrowdSec 照样运行、照样显示 alert、照样维护决定清单——而什么也不拦。
这是第一次接触时最常见的失望：工具装好了，攻击也看得见，而流量还和先前一模一样地流着。
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables
sudo cscli bouncers list最后这条命令至少应当显示出一条已注册的记录。空列表意味着没有任何拦截。
第二个差别：共享信誉
Fail2ban 只知道你这里发生了什么。一个昨天花了一整天去攻破上百台别人服务器的地址，在它眼里依然干净，直到它敲你的门为止——而它的前五次尝试是免费的。
CrowdSec 会把触发了什么的信号发到一个共享网络，并收回一份在别人服务器上出现过的地址清单。实际效果是：相当一部分密码猜测在第一次尝试之前就被切掉了。而这在面对分布式攻击时尤其要紧——成千上万个地址各试一次，本地计数器按定义就无能为力。
还有一点要事先知道：交换是双向的。从你的服务器出去的是违规地址以及触发的场景类型。完全本地运行是可行的——不去云端控制台注册——但那样共享清单对你也不再可用，主要优势也就没了。这是一个需要有意识做出的选择，而不是配置细节。
日常命令
sudo cscli metrics
sudo cscli alerts list
sudo cscli decisions list
sudo cscli decisions delete --ip 203.0.113.25metrics 回答的是日志到底有没有被读：如果被解析的行数是零，那说明对应你 Web 服务器的采集集合没装上，或者日志路径不对。这是「装好了却不工作」的第二常见情形。
sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx资源占用
CrowdSec 用 Go 写成，把状态放在数据库里。内存占用在一百兆左右，再加上 bouncer。在一台一个 G 内存的服务器上这是感觉得到的；两个 G 往上就无所谓了。Fail2ban 更轻，做的事也更少。
要不要两个都用
它们不冲突：一个把自己的规则写进防火墙，另一个写自己的，同一个地址被封两次也不害谁。合理的分工是这样的。
CrowdSec 承担大规模流量：SSH 猜测、Web 服务器扫描，以及共享清单里已知的坏地址。而 Fail2ban 留在那些你有自己格式的自有日志的地方——对它们来说写一条正则比写一个场景更容易：自制的应用、某个少见的服务、某个特定的登录表单。
如果只能选一个，判断标准是：在一台带站点、被不停试探的服务器上，CrowdSec 靠共享清单给得更多。而在一台只有你用密钥经 SSH 够得到的服务器上，两者差别不大——那里大部分工作靠关掉密码就已经做完了。
一个共同的边界
它们谁也防不住应用本身的缺陷。两者都作用于请求频率和地址信誉，而一个从干净地址第一次就利用某插件漏洞的请求，会从它们两个身边一起过去。那是别的工具的活儿——请求层面的 WAF 和及时的更新。封地址去掉的是背景噪声，而不是原因。
而两者的实用价值都取决于有没有人去看结果。决定数量的增长、某个场景第一次触发、尝试来源国家的变化——这正是当初装这个工具所要的信息。它在一个页面上是什么样子，见下面的演示。