CrowdSec社区协作需启用online_client并完成CTI连接：检查/etc/crowdsec/config.yaml中api.server.online_client配置，确保credentials_path有效、enabled: true，执行cscli auth login获取凭证，重启服务后验证日志显示successfully connected to CTI API，并确认cscli decisions list含cti来源的ban条目及curl查询IP行为标签非空。
能直接用，但必须连上 CrowdSec CTI 网络，否则只剩单机检测能力 —— 社区协作的核心是 online_client 配置和 cscli 的决策同步。
确认 CrowdSec 已启用在线威胁情报客户端
默认安装后，crowdsec 本地运行但不自动连接社区 CTI。关键配置在 /etc/crowdsec/config.yaml 的 api.server.online_client 区块：
- 检查
credentials_path是否指向真实存在的/etc/crowdsec/online_api_credentials.yaml - 若该文件为空或不存在，执行
sudo cscli dashboard login或sudo cscli auth login获取凭证（会自动写入） - 确保
enabled: true（部分旧版配置项名是enable_online_client，注意 YAML 缩进） - 重启服务：
sudo systemctl restart crowdsec，再查日志：sudo journalctl -u crowdsec -n 50 --no-pager | grep -i "online\|cti"，看到successfully connected to CTI API才算通
验证社区共享的恶意 IP 是否实际生效
光连上还不够，得确认封禁动作是否调用了社区黑名单。重点看两个地方：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
cscli decisions list输出中，类型为ban且来源含cti或crowdsecurity的条目，才是社区贡献的 IP - 对比
cscli decisions list --ip 1.2.3.4和curl -s "https://cti.api.crowdsec.net/v2/smarts/1.2.3.4" | jq '.behaviors'，若后者返回非空行为标签（如ssh_bruteforce），说明该 IP 确实被社区标记 - 注意：社区数据有缓存，默认 10 分钟刷新一次，
cscli decisions list不会实时显示新拉取的条目，需等 LAPI 同步完成
绕过社区 CTI 的常见错误配置
很多用户以为装完就自动“群体免疫”，结果发现只拦自己服务器上的攻击 —— 这些配置最容易踩坑：
- 误把
local_api的listen_uri设成127.0.0.1:8080，但bouncer（如crowdsec-nginx-bouncer）连的是localhost:8080，而online_client要求local_api必须可被外网（CTI 服务端）回调 —— 实际只需确保local_api正常监听，不涉及公网暴露 - 防火墙（如 ufw）误拦了出站 HTTPS（
443），导致crowdsec无法连接cti.api.crowdsec.net；用curl -v https://cti.api.crowdsec.net/health测试连通性 - 使用了自定义
profiles.yaml但漏掉了cti相关过滤器，例如原生default_ip_remediation剧本里有Alert.GetScenario() =~ "crowdsecurity/"，而你删了这行，就只响应本地规则触发的警报
让本地检测也参与社区反哺的关键操作
你的服务器不只是消费者，更是情报源。要让检测到的新恶意 IP 上报社区，必须满足：
- 确保
cscli machines list中当前机器状态为valid（不是pending或invalid） - 检测规则本身需带
type: leak或明确设置leak: true（见/etc/crowdsec/parsers/s0X-XXX.yaml中的leak字段） - 上报前会做匿名化处理（IP 拆分、时间脱敏），但如果你在
config.yaml中设了disable_anonymous_leaks: true，则完全不会上传 - 执行
sudo cscli alerts list --since 1h查最近警报，再对某条 alert 执行sudo cscli alerts inspect <alert_id></alert_id>，若输出中有"leak": true且无报错，说明已进入上报队列
真正难的不是配置开关，而是理解“社区协作”不是全自动广播 —— 它依赖每个节点的 online_client 健康度、local_api 同步延迟、以及规则作者是否标记了 leak。一旦其中一环断开，你就退化回单机 Fail2ban 模式。
