CrowdSec 在运行，攻击却在穿过：bridge 容器的 DNS 如何悄悄禁用了 IPS

症状：防护开着，却没用

一台服务器遭受攻击：约 20,000 req/h，550 倍于正常流量，CPU 100%。奇怪的是 CrowdSec 已安装并"在运行"——却没有封禁任何 IP。一个在攻击下不封禁的 IPS 不是在防护；而是装饰。

原因：bridge 容器内的 DNS 坏了

CrowdSec 容器运行在带静态 IP 的 Docker bridge 网络里。在这种配置下，DNS 解析走 Docker 在 127.0.0.11 的内部解析器——而它在这里对外部域名返回 SERVFAIL。宿主机通过 VPC DNS 正常解析；容器却不行。没有 DNS，CrowdSec 无法与 LAPI 通信，陷入重启循环：

$ docker logs crowdsec --tail 3
level=fatal msg="dial tcp: lookup version.crowdsec.net on 127.0.0.11:53: server misbehaving"
# 重启、失败、重启……（静默循环）

问题的特征藏在 uptime 里：该容器只有 20 秒寿命，而健康的邻居有 5 个月。重启循环本身不会触发告警——只有当你查看 uptime 或日志时它才现形。

处于重启循环的安全服务比缺席更糟：仪表盘显示"运行中"，告警从不触发，等你发现时攻击已经在里面了。

修复：network_mode host

修复是把容器从 bridge 移到宿主机网络，让它继承机器可用的 DNS 解析器：

services:
  crowdsec:
    image: crowdsecurity/crowdsec
    network_mode: "host"   # 之前：带静态 IP 的 bridge → 127.0.0.11 的 DNS 坏了
    # ...

在宿主机网络上重启后的几秒内，CrowdSec 解析了 LAPI、下载了场景，并开始封禁扫描器的 IP。CPU 随之回落。

随后的车队审计

这样的问题很少是孤立的。扫一遍服务器，16 台里有 10 台的 CrowdSec 在 bridge 上（易受同样的静默重启循环影响）；6 台已在 host 上。把整个车队标准化到 host，一次性堵上了缺口。

经验教训

1. bridge 容器依赖 127.0.0.11 解析器。一旦它失败，需要 DNS 的服务（如与 LAPI 通信的 IPS）就会重启循环。

2. 重启循环不告警——监控 uptime。一个 20 秒寿命的容器挨着数月寿命的邻居就是特征。对反复出现的低 uptime 告警。

3. "已安装" ≠ "在防护"。验证 IPS 在负载下确实会封禁；一次周期性的封禁测试胜过一个"running"状态。

结论

最糟的安全失效是静默的那种：CrowdSec 在那里，状态显示"运行中"，攻击却穿了过去，因为容器从未能与 LAPI 通信。network_mode: host 几秒内修好了它——但真正的教训是监控 uptime 并测试封禁，因为一个死掉的 IPS 不会举手。