CrowdSec vs fail2ban en 2026: cuál elegir para proteger tu servidor

Si administras un servidor Linux expuesto a internet, tarde o temprano alguien va a golpear el puerto SSH hasta que una contraseña débil ceda. fail2ban lleva más de una década siendo la respuesta por defecto: baneas IP durante N minutos tras M intentos fallidos y listo. CrowdSec apareció en 2020 con un giro interesante: cuando un nodo detecta un patrón de ataque, esa firma se comparte con el resto de la red y se aplica de forma colectiva.

Ambos siguen vivos en 2026, ambos siguen siendo open source, y ambos siguen resolviendo el mismo problema de fondo (ataques de fuerza bruta, escaneo de puertos, credential stuffing). La diferencia real está en la filosofía y en cómo encajan en una flota de servidores. Esta guía compara los dos en instalación, consumo de recursos, manejo de falsos positivos, respuesta al incidente y curva de aprendizaje para que elijas con criterio.

Qué hace cada uno en una frase

fail2ban es un demonio local que parsea logs (SSH, Postfix, Nginx, Apache, lo que sea), cuenta coincidencias con regex y aplica reglas de firewall cuando un origen supera un umbral. Toda la decisión se queda en tu servidor.

CrowdSec es un motor de detección que hace lo mismo pero además exporta las alertas validadas a una API central y descarga una blocklist comunitaria de IPs ya confirmadas como maliciosas. La “memoria” del ataque sale de tu servidor y se vuelve colectiva.

Esa diferencia de diseño explica casi todo lo demás.

Instalación inicial

fail2ban viene en los repos oficiales de Debian, Ubuntu, Fedora y Arch. Instalación típica:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Sirve para activar el servicio con la configuración por defecto, que vigila SSH y bloquea 10 minutos tras 5 intentos fallidos. En la práctica vas a tocar /etc/fail2ban/jail.local para extenderlo a Nginx, Postfix o tus servicios propios.

CrowdSec se instala con su script oficial, que detecta la distro y baja el binario + un bouncer por defecto:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-iptables

La instalación es un poco más larga porque añade el motor (crowdsec) y el bouncer (crowdsec-firewall-bouncer-iptables) como dos procesos separados. El bouncer es quien aplica las reglas al firewall; el motor es quien decide qué bloquear.

Troubleshooting: si el script de packagecloud falla con GPG error, probablemente tu apt-key está deprecado. Exporta la key manualmente y añade el repo con signed-by apuntando al archivo.

Consumo de recursos

Este es el punto donde más se nota la diferencia entre los dos.

fail2ban es un script Python muy ligero. En un servidor con 50 jails activas y un log de 100 MB/día, ocupa entre 30 y 60 MB de RAM y prácticamente nada de CPU. Lo puedes correr en una Raspberry Pi 3 sin despeinarla.

CrowdSec corre un agente Go + una base SQLite local + un bouncer. El agente suele consumir 40-80 MB de RAM y SQLite añade otros 20-40 MB. La CPU sube cuando se comparte con la red: cada alerta validada se envía a la API central (consensus + API) y se descarga la blocklist periódicamente.

ps -o pid,rss,cmd -C fail2ban-server    # ~40 MB típico
ps -o pid,rss,cmd -C crowdsec           # ~60-90 MB típico

Si tienes un solo servidor pequeño, esa diferencia de RAM no importa. Si estás metiendo todo en un contenedor con 256 MB de RAM o tienes una flota de 20 nodos, empieza a sumar.

Manejo de falsos positivos

Este es el punto débil histórico de fail2ban y donde CrowdSec introduce cambios.

fail2ban aplica reglas deterministas: si el regex matchea N veces en la ventana, banea. No hay contexto, no hay scoring. El resultado es que un usuario que teclea mal su contraseña tres veces seguidas se queda afuera 10 minutos, y un atacante que rota IPs cada 5 intentos recibe baneos triviales que esquiva sin esfuerzo.

# /etc/fail2ban/jail.local
[sshd]
enabled  = true
maxretry = 5
findtime = 600
bantime  = 3600

fail2ban se puede tunear con ignoreip y recidive para reducir falsos positivos. recidive es una jail especial que observa qué IPs ya fueron baneadas varias veces y les aplica un baneo más largo, sin importar la jail original:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 5

CrowdSec introduce un sistema de scoring: cada escenario (detector) asigna un peso al evento, y la IP solo se bloquea cuando supera un umbral configurable. Los eventos individuales pesan poco; los patrones de ataque sostenido suman hasta cruzar el umbral. Esto reduce muchísimo los falsos positivos sin sacrificar la respuesta al ataque real.

Troubleshooting: si ves IPs bloqueadas que claramente no son atacantes, revisa cscli alerts list --since 24h y mira qué escenario las detectó. Muchos falsos positivos vienen de un escenario demasiado sensible (por ejemplo, un http-bad-user-agent que matchea un crawler legítimo).

Respuesta al incidente: ban local vs blocklist compartida

Cuando fail2ban detecta algo, aplica una regla iptables o nftables local. Eso es todo. Si el atacante cambia de IP, vuelve a empezar desde cero.

Cuando CrowdSec valida una alerta como ataque confirmado (por scoring o por consenso de otros nodos), la comparte con la API central. Tu bouncer aplica el ban local, y además descarga una blocklist comunitaria con miles de IPs que otros operadores ya confirmaron como maliciosas.

# Ver alertas locales en CrowdSec
sudo cscli alerts list
# Ver la blocklist que tu nodo está aplicando
sudo cscli hublist list
# Banear manualmente una IP concreta
sudo cscli decisions add --ip 203.0.113.42 --reason "ssh-bf" --duration 24h

Para un solo servidor casero, la blocklist compartida no cambia mucho. Para una flota de 5-10 servidores, significa que cuando uno aprende, todos aprenden. Si alojas servicios para clientes, además puedes consultar la blocklist desde tu WAF o CDN (Cloudflare, AWS WAF, Fastly) sin desplegar bouncers en cada nodo.

Coordinación entre múltiples servidores

fail2ban no coordina nada entre servidores de forma nativa. Si tienes tres servidores y uno detecta un ataque, los otros dos no se enteran. Puedes montarte algo con consul o etcd, pero es trabajo tuyo.

CrowdSec ya viene con la coordinación incluida. Cada nodo habla con la API central (que puedes hostear tú o usar la comunitaria). Las alertas validadas se comparten, las decisiones se propagan y la blocklist se replica automáticamente. Es la diferencia más clara en escenarios multi-servidor.

Troubleshooting: en redes privadas donde el servidor no puede hablar con internet, puedes hostear tu propia instancia de la API de CrowdSec (crowdsec-local-api) y conectarte a ella. La documentación oficial tiene una guía paso a paso para Docker Compose.

Para desplegar la API privada con Docker Compose, lo más limpio es el repo crowdsec-custom-bouncer + crowdsec-blocklist-mirror corriendo en una máquina de tu red:

git clone https://github.com/crowdsecurity/hub.git
cd hub/docker/local-api
docker compose up -d
# Esperar 30 segundos y verificar
docker compose ps
curl -s http://127.0.0.1:8080/v1/usage-metrics | jq .

Curva de aprendizaje

fail2ban se entiende leyendo un único archivo: /etc/fail2ban/jail.local. La documentación es larga pero el 80% de los casos se cubre con copiar/pegar ejemplos. Si sabes regex, puedes escribir jails custom para cualquier servicio en menos de una hora.

CrowdSec tiene más conceptos: agentes, bouncers, escenarios, decisiones, API central, hublist. La documentación es buena pero más densa. Antes de sentirte cómodo vas a tocar la consola (cscli), la config del agente y probablemente la config del bouncer.

Si nunca tocaste ninguna de las dos herramientas, fail2ban te va a dar resultado funcional en 30 minutos. CrowdSec te va a dar una configuración decente en 2-3 horas.

Ecosistema y extensibilidad

fail2ban tiene jails comunitarias para casi cualquier servicio imaginable: SSH, Postfix, Dovecot, Nginx, Apache, Asterisk, WordPress (wp-login), Nextcloud, ProFTPD. La mayoría vienen en el paquete fail2ban y se activan cambiando enabled = true. Si tu servicio tira logs a un archivo, puedes escribir una jail.

CrowdSec tiene una colección de escenarios más reducida pero crece rápido, especialmente para HTTP (parsers HTTP específicos por framework) y APIs. Para servicios custom, el enfoque es escribir un parser en YAML o un agente que consuma logs vía Loki/syslog. La barrera de entrada para extensiones custom es más alta que en fail2ban.

Cuándo elegir fail2ban

Elige fail2ban si:

• Tienes un solo servidor (o unos pocos) y no planeas escalar mucho.
• Tu servidor es chiquito (VPS de 512 MB-1 GB, Raspberry Pi, contenedor ligero).
• Quieres algo que entiendas de un vistazo, sin nuevos demonios ni APIs externas.
• Tus logs ya tienen un formato limpio que matchear con regex.
• No quieres depender de un servicio externo (la API central de CrowdSec es opcional pero útil).

Para un homelab, un VPS personal o un servidor de un cliente pequeño, fail2ban sigue siendo la respuesta correcta en 2026.

Cuándo elegir CrowdSec

Elige CrowdSec si:

• Tienes varios servidores y quieres que compartan inteligencia de amenazas.
• Quieres visualizar ataques (la consola web de CrowdSec da dashboards muy buenos).
• Quieres aplicar la blocklist comunitaria en un WAF o CDN, no solo en el firewall local.
• El servicio expone APIs o apps web donde los falsos positivos cuestan caro (un scoring inteligente ayuda).
• Puedes tolerar unos 100 MB extra de RAM y la dependencia de un servicio externo (o de tu propia API).

Para una empresa mediana con 5-50 servidores, o para un proveedor que ofrece hosting gestionado, CrowdSec empieza a pagar el costo extra de setup con la coordinación automática y la blocklist compartida.

Cuándo combinar los dos

No son mutuamente excluyentes. Hay configuraciones donde fail2ban cubre el grueso de los servicios (SSH, mail, FTP) con jails ligeras, y CrowdSec se reserva para el servicio HTTP principal (Nginx frente a una API) donde el scoring fino y la blocklist compartida suman más. La convivencia es técnicamente viable: ambos bouncean a iptables/nftables y puedes priorizar reglas con un chain dedicado.

Veredicto

fail2ban en 2026 sigue siendo una pieza sólida, simple y suficiente para la mayoría de servidores. CrowdSec es su evolución natural para escenarios donde la coordinación entre nodos y el scoring fino valen la complejidad extra. No hay una respuesta única; depende del tamaño de tu flota, del tipo de servicio que proteges y de cuánta memoria extra estás dispuesto a gastar.

Si tuvieras que elegir una sola herramienta hoy, empieza por fail2ban y migra a CrowdSec cuando notes que los falsos positivos te cuestan soporte o que necesitas coordinar varios nodos.

Un comando útil para revisar el estado de fail2ban desde cualquier script de monitoreo:

sudo fail2ban-client status sshd | grep -E 'Banned|Total' | awk '{print $1, $4}'
sudo fail2ban-client banned                                    # lista de IPs baneadas
sudo fail2ban-client set sshd unbanip 203.0.113.42             # desbanear manualmente

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux