Skip to content

CrowdSec — concepto y encaje en Wetopi

1. Qué es

CrowdSec es un sistema de prevención de intrusiones colaborativo, open source (Go), con una idea central: los atacantes que golpean tu plataforma están golpeando miles de plataformas iguales — compartamos la señal.

Es el equivalente moderno de fail2ban (mismo autor conceptual, Philippe Humeau), con tres diferencias clave: analiza logs estructurados modernos (JSON, no regex sobre texto plano), separa la DECISIÓN del ENFORCEMENT, y añade una capa colaborativa global que fail2ban no tiene.

2. Cómo funciona — tres piezas

┌────────────────────────────────────────────────────┐
│ 1. SECURITY ENGINE (el "cerebro", corre en TI)     │
│    Lee tus logs (traefik, sshd, suricata, nginx…)  │
│    y aplica "scenarios" (patrones de ataque):      │
│    - 50 logins fallidos desde 1 IP                  │
│    - scan de /wp-admin, /.env, /vendor…             │
│    - ráfagas de 403/404, LFI probes, etc.           │
│    → decide: "esta IP es maliciosa, banea 4h"       │
├────────────────────────────────────────────────────┤
│ 2. BOUNCER / Remediation Component (el "brazo")    │
│    Consulta las decisiones del Engine (vía LAPI,   │
│    la Local API) y las EJECUTA donde tú elijas:      │
│    nftables/iptables, nginx, traefik plugin,        │
│    cloudflare, firewalls cloud…                     │
├────────────────────────────────────────────────────┤
│ 3. LA RED GLOBAL (app.crowdsec.net)                 │
│    Tu Engine REPORTA las IPs maliciosas detectadas  │
│    → a cambio RECIBES la blocklist comunitaria      │
│    ("consensus": millones de IPs reportadas por     │
│    miles de servidores)                             │
└────────────────────────────────────────────────────┘
  • El Engine es un agente que parses tus logs existentes y aplica scenarios (la comunidad publica cientos; para nosotros interesarían los de WordPress: crowdsecurity/http-wordpress-*, brute-force genérico, crawlers agresivos).
  • El bouncer es desacoplado: puede ser un binario en el host, un plugin de traefik (p.ej. maxlerebourg/crowdsec-bouncer-traefik), un script que alimente nftables… Consulta el LAPI cada pocos segundos y sincroniza el baneo.
  • La red: el Engine reporta señales a los servidores de CrowdSec y recibe a cambio las blocklists comunitarias (curadas por su equipo: niveles "consensus" etc.). El reporte es opt-in y anonimizado.

3. Diferencia con lo que ya tenemos (fw-edge)

fw-edge (firehol level1 + listas duras) CrowdSec
Blocklist Estática, descargada con cada revisión Dinámica: reacciona a ataques en TU plataforma en casi tiempo real
Origen de la señal Feeds públicos compilados por terceros Tus PROPIOS logs + la red comunitaria
Detección Ninguna — solo aplica listas Scenarios: detecta el ataque mientras ocurre
Reacción Minutos-horas (poll ≤60s del agent) Segundos (bouncer consulta el LAPI)
Escalada a incidente Manual (operador añade IP a la lista) Automática + compartida con toda la red

No compiten: CrowdSec alimentaría el mismo set nft del fw-edge — es una capa de señal encima de nuestro enforcement existente.

4. Por qué es la Q3 abierta del ADR-0019

La propuesta evaluada en el estudio (ADR-0019 §3, Q3):

  • El LAPI + Security Engine correrían in-cluster (Deployment), analizando los access logs JSON del traefik que YA producimos (el pipeline access-traefik-* de E-OBS.1 es exactamente su input).
  • El bouncer NO instalaría su propio firewall: alimentaría el set wetopi_fwedge de nuestra capa 1 vía la API del fw-edge-controller — integración con lo construido, no un componente paralelo.
  • Valor concreto: un wepod sufriendo brute-force AHORA → sus atacantes baneados en segundos en TODOS los nodos edge, y reportados a la red.

Por qué no se decidió aún: no bloquea nada del ADR (es una mejora reactiva encima de la pila ya construida), y añade superficie de decisión: otro componente que mantener (v1.7.1 pinned), qué scenarios activar para WordPress sin falsos positivos, y el contrato de coexistencia con las revisiones inmutables del fw-edge (fw-rev-N): las decisiones de CrowdSec son dinámicas por diseño y tendrían que ir por el camino de "estado dinámico por API del backend" que el ADR ya define para bloqueos de incidente — no por GitOps.

5. Qué decidir si se activa (checklist de la Q3)

  1. Coste del Engine sobre el flujo de access logs (CPU del pod LAPI a ~100k requests/día).
  2. Set inicial de scenarios WordPress (brute-force wp-login, scans .env/.git, crawlers) con umbrales por sitio, no globales.
  3. Contrato de integración con fw-edge: nueva ruta "dynamic-blocks" en la API del controller (separada de las revisiones inmutables).
  4. Reporte a la red global: sí/no (opt-in; considera qué señal saldría).
  5. Bouncer v1.7.1 (plugin traefik) vs alimentación directa del set nft.

6. Cómo se rompe y se arregla

Síntoma Causa Acción
IP maliciosa sigue llegando Bouncer sin conexión al LAPI Check del pod LAPI + bouncer logs; fail-open: el resto de capas sigue
Falsos positivos en masa Scenario demasiado agresivo Desactivar el scenario en el Engine (las decisiones expiran solas)
Engine caído Sin DETECCIÓN nueva, pero el baneo vigente persiste (fail-open) Reiniciar el pod; los bounces activos siguen hasta su expiración
Blocklist comunitaria degrada Sin salida a internet del LAPI Los escenarios locales siguen funcionando (solo se pierde la señal global)

7. Resolución de la Q3 (veredicto)

La Q3 quedó evaluada en INV-001 (operations/investigations/inv-001-crowdsec-edge-reactive-q3.md, 2026-09-12): activar con recortes — Engine+LAPI in-cluster parseando el access log JSON del traefik (pin v1.7.8+, NO v1.7.1: CVE-2026-44981 LAPI DoS + CVE-2026-44982 WAF bypass, ambos HIGH, 1.7.8 de 2026-05-27), 5 scenarios WordPress con umbrales por sitio y ban scope=ip ≤4h con whitelist de IPs internas/NAT-GW, integración por una ruta /api/v1/dynamic-blocks en la API del fw-edge-controller (el bouncer traefik plugin queda descartado por el incidente 2026-09-12 del DS), y reporte a la red global DIFERIDO a fase 2 (tras validar falsos positivos en simulación). Detalles, coste y contrato: ver INV-001.