CrowdSec rodando, ataque passando: o DNS de um container em bridge que desligou o IPS silenciosamente

O sintoma: proteção ligada, mas inútil

Um servidor sob ataque: ~20.000 req/h, 550× o tráfego normal, CPU em 100%. O estranho era que o CrowdSec estava instalado e "rodando" — e nenhum IP tinha sido banido. Um IPS que não bane sob ataque não está protegendo; está enfeitando.

A causa: DNS quebrado dentro do container em bridge

O container do CrowdSec rodava numa rede Docker bridge com IP estático. Nessa configuração, a resolução de DNS passa pelo resolver interno do Docker em 127.0.0.11 — que, ali, retornava SERVFAIL para domínios externos. O host resolvia normalmente via DNS da VPC; o container, não. Sem DNS, o CrowdSec não falava com a LAPI e entrava em crash-loop:

$ docker logs crowdsec --tail 3
level=fatal msg="dial tcp: lookup version.crowdsec.net on 127.0.0.11:53: server misbehaving"
# reinicia, falha, reinicia...  (loop silencioso)

A assinatura do problema estava no uptime: o container tinha 20 segundos de vida, enquanto os vizinhos saudáveis tinham 5 meses. Crash-loop não gera alerta sozinho — ele só aparece se você olhar o uptime ou os logs.

Um serviço de segurança em crash-loop é pior que ausente: o dashboard diz "rodando", o alerta nunca dispara, e você só descobre quando o ataque já está dentro.

O fix: network_mode host

A correção foi tirar o container da bridge e colocá-lo na rede do host, onde ele herda o resolver de DNS funcional da máquina:

services:
  crowdsec:
    image: crowdsecurity/crowdsec
    network_mode: "host"   # antes: bridge com IP estático → DNS 127.0.0.11 quebrado
    # ...

Em segundos após o restart na rede do host, o CrowdSec resolveu a LAPI, baixou os cenários, e começou a banir os IPs do scanner. A CPU caiu junto.

A auditoria de frota que veio depois

Um problema desses raramente é isolado. Varrendo os servidores, 10 de 16 estavam com o CrowdSec em bridge (vulneráveis ao mesmo crash-loop silencioso); 6 já estavam em host. Padronizar para host em toda a frota fechou a brecha de uma vez.

Lições

1. Container em bridge depende do resolver 127.0.0.11. Se ele falha, serviços que precisam de DNS (como um IPS falando com a LAPI) entram em crash-loop.

2. Crash-loop não gera alerta — monitore uptime. Um container com 20s de vida ao lado de vizinhos com meses é a assinatura. Alerte sobre uptime baixo recorrente.

3. "Instalado" ≠ "protegendo". Valide que o IPS realmente bane sob carga; um teste de banimento periódico vale mais que um status "running".

Conclusão

A pior falha de segurança é a silenciosa: o CrowdSec estava lá, o status dizia "rodando", e mesmo assim o ataque passava porque o container nunca conseguiu falar com a LAPI. network_mode: host resolveu em segundos — mas a lição real é monitorar o uptime e testar o banimento, porque um IPS morto não levanta a mão.