Fail2ban 是基于日志单行正则匹配的轻量级守门人，适合中小静态环境；CrowdSec 采用行为建模与共享情报的云原生架构，支持多节点协同防御。
Fail2ban 和 CrowdSec 都是 Linux 系统中用于实时检测并阻断恶意行为的入侵防御工具，但设计哲学、架构和扩展方式差异明显。Fail2ban 更轻量、成熟、依赖日志正则匹配，适合中小规模静态环境；CrowdSec 是云原生风格的现代方案，强调行为建模、共享情报与可编程决策，更适合动态、多节点、需协同响应的场景。规则自定义上，前者靠手写正则+ jail 配置，后者用 YAML + DSL（如 CAPI）驱动，学习曲线略高但更结构化。
fail2ban：基于日志行匹配的守门人
Fail2ban 的核心逻辑是持续 tail 日志文件（如 /var/log/auth.log），用正则表达式提取失败登录、暴力扫描等模式，触发 iptables 或 nftables 封禁 IP。它不分析行为序列，只看单行是否“像攻击”。
- 规则定义在 /etc/fail2ban/filter.d/ 下的 .conf 文件中，例如 sshd.conf 包含：
failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure.*\s+rhost=\s*$ - 封禁策略由 jail 定义（/etc/fail2ban/jail.local），可设置 maxretry=3、bantime=1h、backend=systemd（适配 journal 日志）
- 自定义一个针对 WordPress 暴力登录的规则：新建 /etc/fail2ban/filter.d/wordpress-login.conf，匹配 Apache 日志中 POST /wp-login.php 返回 200 但含 "Invalid username" 的行；再在 jail 中启用该 filter 并指定日志路径
crowdsec：行为感知+社区驱动的防御网络
CrowdSec 不止看单条日志，而是将多个事件聚合为“攻击会话”，结合时间窗口、IP信誉、地理信息和共享威胁情报（CAPI）做综合判断。它的 parser → scenario → decision 流水线支持深度定制。
- Parser（解析器）将原始日志结构化，例如用 grok 表达式从 Nginx 日志中提取 http_path、status、client_ip
- Scenario（场景）是核心规则单元，YAML 编写，支持条件链（如“5 分钟内 10 次 404 + 路径含 /wp-admin”）、白名单排除、指标计数。官方仓库已含 http-bad-user-agent、ssh-slow-bruteforce 等近百个场景
- 自定义一个针对 API 密钥暴力探测的 scenario：在 /etc/crowdsec/scenarios/ 新建 api-key-bruteforce.yaml，匹配 GET /api/v1/users?token=xxx 返回 401，且同一 IP 在 30 秒内触发 ≥8 次，触发 ban 动作并上报 CAPI
关键能力对比：什么场景选谁？
选择不是非此即彼，而是看运维目标和技术栈适配度：
- 已有稳定日志格式 + 单机或小集群 + 运维熟悉正则 → Fail2ban 上手快、资源占用低（Python 启动即走），适合传统 VPS 或跳板机防护
- 多云/容器/K8s 环境 + 需跨节点共享威胁数据 + 希望自动更新攻击指纹 → CrowdSec 的 LAPI（Local API）+ CAPI 架构天然支持横向扩展，且其 hub 提供一键安装 parser/scenario/bouncers（如 nginx-bouncer、iptables-bouncer）
- 合规审计要求可追溯、可解释 → Fail2ban 的封禁记录全在 /var/log/fail2ban.log，一行一事件；CrowdSec 决策日志更丰富（cscli decisions list 可查原因、来源 scenario、持续时间），还支持导出 JSON 供 SIEM 接入
规则调试与验证：别让自定义变成盲区
无论哪种工具，新规则上线前必须验证匹配精度——误杀比漏放更伤业务。
- Fail2ban：用 fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf 测试正则是否捕获真实失败行，加 -v 查看匹配细节；再用 fail2ban-client status sshd 确认 jail 活跃且当前 bans 数非零
- CrowdSec：用 cscli parsers test -f /var/log/nginx/access.log --name nginx 验证日志是否被正确解析；再运行 cscli scenarios test -f /tmp/test.log --name my-scenario 输入模拟日志行，观察是否触发 decision；最后用 cscli decisions list --scope ip 查看实时封禁状态
- 通用建议：先设短 bantime（如 60s）、禁用实际防火墙动作（Fail2ban 设 action = %(action_)s；CrowdSec 设 mode: dry-run），确认逻辑无误后再切到生产模式
