Actualizado: 2026-07-17

CrowdSec, la evolución moderna de fail2ban, se instala en Debian o Ubuntu con el script oficial (curl -s https://install.crowdsec.net | sudo sh y luego sudo apt install crowdsec); después activas las collections adecuadas y añades al menos un bouncer (el componente que consulta las decisiones de bloqueo y las aplica, por ejemplo en Traefik o en el firewall) para pasar de la simple detección a la protección real. CrowdSec[1] es un WAF (cortafuegos de aplicación web, la capa que filtra peticiones HTTP maliciosas antes de que lleguen a tu aplicación) comunitario: separa la detección del bloqueo, expone una API local y se apoya en una blocklist alimentada por miles de instalaciones voluntarias repartidas por el mundo. Esta guía recorre la instalación y la integración con Traefik explicando por qué existe cada pieza, no solo los comandos que hay que copiar.

Puntos clave

  • CrowdSec separa detección (agente + LAPI) de bloqueo (bouncers): la misma fuente de decisiones puede alimentar un bouncer HTTP en Traefik y otro de red en iptables a la vez.
  • La acquisition es el paso que más se olvida: decirle al agente qué logs leer, con las etiquetas correctas, es crítico.
  • La remediación con captcha (Cloudflare Turnstile) evita banear a usuarios legítimos en escenarios de fuerza bruta.
  • La blocklist comunitaria bloquea cientos de IPs conocidas antes de que lleguen a hacer nada.
  • En un VPS de hobby con una sola capa que proteger, fail2ban sigue siendo más simple; CrowdSec compensa a partir de dos o tres capas.

Por qué vale la pena el cambio desde fail2ban

La diferencia más importante es arquitectónica. fail2ban lee logs, decide y ejecuta una regla de iptables en el mismo proceso. CrowdSec separa esas responsabilidades:

  • El agente lee logs y emite decisiones a la LAPI (una API REST local que, por defecto, escucha en 127.0.0.1:8080).
  • Los bouncers consultan la LAPI y ejecutan el bloqueo, ya sea en el firewall, en un proxy inverso o en el propio servidor web.

Esta separación tiene consecuencias prácticas. Puedes tener un bouncer en el firewall para SSH y otro en Traefik para HTTP, y ambos actúan sobre las mismas decisiones: cambias la detección sin tocar el bloqueo. Y si decides contribuir tus detecciones a la comunidad, recibes a cambio una lista actualizada de IPs que están atacando a otros en ese momento.

La segunda diferencia es la expresividad. fail2ban usa expresiones regulares sobre líneas de log; CrowdSec usa scenarios (reglas declarativas en YAML que combinan qué detectar, con qué umbral, en qué ventana de tiempo y cómo agrupar coincidencias). Escribir un scenario para un patrón nuevo es un ejercicio de unos quince minutos una vez entiendes la sintaxis.

Instalación del agente

En Debian o Ubuntu:

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec

El agente y la LAPI quedan en el mismo proceso, escuchando en localhost. sudo cscli version y sudo systemctl status crowdsec confirman que todo arrancó.

Collections: trabajo ahorrado desde el primer día

Una collection (paquete que agrupa parsers, los traductores de un formato de log concreto, y scenarios listos para una tecnología) evita escribir reglas desde cero. Para un stack típico con Traefik, WordPress y Gitea:

sudo cscli collections install crowdsecurity/traefik
sudo cscli collections install crowdsecurity/wordpress
sudo cscli collections install crowdsecurity/gitea

Cada collection trae lo que necesitas: la de WordPress detecta fuerza bruta en el login, escaneo de usuarios y accesos a rutas sensibles como wp-config.php. No hace falta entender cada scenario desde el primer día; en pocos días habrás revisado cuáles se disparan con tu tráfico real.

Decirle al agente qué logs leer

Este es el paso que más se olvida. La acquisition (la configuración que le dice al agente qué archivos leer y con qué etiqueta) va en /etc/crowdsec/acquis.yaml. Para un setup con Traefik en Docker y SSH vía systemd:

- filenames:
    - /var/log/traefik/access.log
  labels:
    type: traefik
- source: journald
  journalctl_filter:
    - "_SYSTEMD_UNIT=sshd.service"
  labels:
    type: syslog

La etiqueta type no es arbitraria: los parsers filtran por ella. Si pones type: traefik-access cuando el parser espera type: traefik, no detectará nada y no mostrará ningún error explícito; es el fallo más común entre usuarios nuevos. Tras editar el archivo: sudo systemctl restart crowdsec. A los pocos minutos, sudo cscli metrics debe mostrar líneas siendo procesadas.

Diagnóstico: qué ver los primeros días

Tres comandos que conviene convertir en rutina:

  • sudo cscli alerts list: alertas disparadas (detecciones).
  • sudo cscli decisions list: decisiones activas (IPs bloqueadas o bajo captcha en este momento).
  • sudo cscli metrics: ritmo de detecciones, aciertos de caché, estado general.

Si llevas más de 24 horas con el agente activo y ninguno de estos comandos muestra actividad, tu acquisition probablemente no está leyendo lo que crees.

Los bouncers: de detección a bloqueo efectivo

CrowdSec detecta, pero todavía no bloquea nada por sí solo. Hace falta al menos un bouncer. Para Traefik, el plugin oficial es maxlerebourg/crowdsec-bouncer-traefik-plugin[2], que puedes instalar siguiendo la guía de instalación de Traefik con Docker Compose como base si todavía no tienes el proxy inverso funcionando.

Se declara en la configuración estática de Traefik como plugin experimental y en la dinámica como middleware. El plugin consulta la LAPI en modo stream (cachea las decisiones y se actualiza cada pocos segundos), así que la latencia percibida por el visitante no aumenta.

La clave de API del bouncer se genera así:

sudo cscli bouncers add traefik-bouncer

Copia el token que aparece una única vez y ponlo en la configuración del middleware.

Para SSH, añade el firewall bouncer:

sudo apt install crowdsec-firewall-bouncer-iptables

Se configura solo a partir de las decisiones ya activas. Ahora tienes dos bouncers compartiendo la misma fuente de decisiones.

Remediación con captcha: no todo es ban

El error clásico de un WAF es banear todo lo sospechoso y descubrir a la semana que estabas bloqueando clientes legítimos. CrowdSec permite emitir decisiones de tipo captcha en lugar de ban. El bouncer de Traefik sabe interpretarlas: muestra un desafío de Cloudflare Turnstile[3] en lugar de cortar la conexión.

El patrón que funciona bien en producción:

  • Fuerza bruta (alguien probando contraseñas): captcha. El usuario legítimo lo resuelve y sigue.
  • Exploits conocidos (CVEs como CVE-2021-44228, o accesos a rutas sensibles): ban directo. Un bot de exploit no resuelve captchas.

La integración con Turnstile solo requiere dos claves (site key y secret key) del panel de Cloudflare; el servicio es gratuito y admite un volumen de peticiones generoso para uso normal.

El valor real de la blocklist comunitaria

Registrar tu instalación con la CAPI central (sudo cscli capi register) te pone en la red comunitaria de CrowdSec, la empresa francesa fundada a finales de 2019 que mantiene el proyecto. Empiezas a recibir una lista actualizada de IPs que están atacando a otros ahora mismo, y contribuyes (de forma anonimizada) las tuyas: cuantas más detecciones compartes, más completa es la blocklist que recibes a cambio. Revisa las métricas antes y después de activar la CAPI y verás cómo cae el ruido de intentos sobre endpoints típicos.

Matiz ético: al compartir detecciones contribuyes a una defensa colectiva, pero también envías información sobre tu tráfico. Para la mayoría de instalaciones el intercambio es aceptable; para entornos con exigencias de privacidad estrictas, conviene leer los términos antes de activarlo.

Monitorización

CrowdSec expone métricas Prometheus en un endpoint HTTP local, por defecto en 127.0.0.1:6060/metrics (puedes verificarlo con la documentación oficial de métricas[4]). Si ya monitorizas el servidor con algo como la guía de Netdata en Docker, este endpoint encaja igual de bien en ese panel. Métricas útiles:

  • cs_bucket_overflow_count: detecciones acumuladas.
  • cs_active_decisions: IPs bloqueadas en este momento.

Hay un dashboard oficial de Grafana listo para importar. La alerta más importante no es el pico de detecciones (puede ser ruidoso) sino la ausencia de métricas durante más de cinco minutos: es la señal de que el agente se paró o la acquisition se rompió.

Whitelists y errores comunes

Antes de bloquear nada en serio, asegúrate de que tus propias IPs están en whitelist: tu oficina, la VPN que usas, el CI/CD que hace los despliegues, los monitores externos. Va en /etc/crowdsec/parsers/s02-enrich/whitelists.yaml y acepta IPs individuales y rangos CIDR, por ejemplo 203.0.113.0/24 para toda una subred de oficina. El número de administradores que se han bloqueado a sí mismos en las primeras horas supera fácilmente al de atacantes que han frustrado ese mismo día.

Otro error frecuente: no reiniciar el agente después de editar la configuración. CrowdSec no detecta cambios en caliente en la mayoría de archivos; ejecutar systemctl restart crowdsec tras cada edición es disciplina básica.

Cuándo no compensa CrowdSec

Hay escenarios donde fail2ban sigue siendo más simple y adecuado:

  • Servidor único con bajo tráfico y sin necesidad de compartir inteligencia entre nodos.
  • Sin Traefik (sin plugin HTTP) y sin varias capas que proteger.

CrowdSec empieza a compensar cuando tienes más de una capa (web, SSH, aplicaciones), cuando la blocklist comunitaria corta ruido de forma medible, o cuando quieres integrarlo con Ansible para gestionar whitelists y configuración de forma centralizada en varios servidores.

Mi recomendación

Si vas a probarlo, hazlo con un despliegue progresivo:

  1. Instala el agente, configura la acquisition y déjalo una semana en modo detección sin bouncer.
  2. Revisa qué se dispara, ajusta scenarios si hay ruido, añade whitelists.
  3. Solo entonces activa el primer bouncer (Traefik).
  4. Espera otra semana y añade la remediación con captcha para fuerza bruta.
  5. Por último, conecta con la CAPI.

Llegar a este punto de madurez lleva dos o tres semanas de convivencia con la herramienta. La inversión merece la pena para cualquier stack con exposición real a internet.

Preguntas frecuentes

¿Cómo saber si CrowdSec está bloqueando tráfico de verdad?

Ejecuta sudo cscli decisions list: si aparecen filas con IPs y un tipo de decisión (ban o captcha), el bouncer correspondiente está aplicando bloqueos activamente. Si la lista está vacía tras varias horas con tráfico normal, revisa primero la acquisition antes de sospechar del bouncer.

¿Necesito Traefik para usar CrowdSec?

No. El agente y la LAPI funcionan igual sin Traefik; lo que cambia es el bouncer. Sin proxy inverso puedes usar el firewall bouncer con iptables o nftables para bloquear a nivel de red, y añadir más tarde un bouncer HTTP si incorporas Traefik u otro proxy compatible.

¿La blocklist comunitaria de CrowdSec es gratis?

Sí. Al registrar la instalación con cscli capi register accedes a una blocklist básica sin coste. Si además contribuyes tus propias detecciones de forma habitual, CrowdSec amplía el acceso a una blocklist comunitaria más completa; los planes de pago añaden listas premium adicionales, pero no son necesarios para el uso descrito en esta guía.

Fuentes

  1. CrowdSec
  2. maxlerebourg/crowdsec-bouncer-traefik-plugin
  3. Cloudflare Turnstile
  4. documentación oficial de métricas
  5. documentación oficial de instalación de CrowdSec

Ruta: Self-hosting con Docker: de cero a producción