CrowdSec en 2026: el fail2ban colaborativo que comparte reputación

Por qué CrowdSec y no solo fail2ban

Fail2ban lleva casi dos décadas leyendo logs y empujando reglas a iptables. Funciona, pero su visión es local: la IP que te atacó hoy puede volver mañana desde otro nodo de la misma botnet y tu servidor no se entera. CrowdSec parte de la misma idea (un agente que lee logs, detecta patrones y emite decisiones) y le añade un componente que fail2ban nunca tuvo: un canal de reputación compartida entre todos los que corren el agente. Cuando una IP te ataca a ti y a otros doscientos servidores, las tres detecciones se agregan en una blocklist comunitaria que tu instancia descarga y aplica antes incluso de que el primer paquete malicioso llegue a tu servicio.

La diferencia operativa importa: en lugar de mantener listas locales que se quedan cortas, heredas la inteligencia de una red que a fecha de septiembre de 2026 publica la versión 1.8.1 del motor de seguridad y mantiene blocklists curadas de hasta 15.000 IPs maliciosas para usuarios activos. Además, CrowdSec separa la detección del bloqueo: el motor produce decisiones vía una API local (LAPI) y un bouncer independiente las aplica. Mismo motor, distintos puntos de aplicación: iptables para SSH, Nginx para tráfico web, Cloudflare para sitios en el edge.

Arquitectura: motor, LAPI, bouncers y CAPI

CrowdSec tiene cuatro piezas y entenderlas evita el 90% de las confusiones cuando algo no bloquea o bloquea de más.

• Security Engine: el demonio que lee logs, aplica escenarios y emite decisiones. Lo instalas con el paquete crowdsec.
• Local API (LAPI): una API HTTP en 127.0.0.1:8080 que centraliza alertas y decisiones, y desde la que los bouncers leen qué aplicar. Es la columna vertebral local.
• Bouncers: componentes de remediación que consumen decisiones del LAPI y actúan. Hay uno por cada punto donde quieras cortar el tráfico: crowdsec-firewall-bouncer-iptables para iptables, crowdsec-nginx-bouncer para Nginx, cs-haproxy-spoa-bouncer para HAProxy, crowdsec-cloudflare-bouncer para Cloudflare.
• Central API (CAPI): el servicio en la nube al que el motor sube señales (si optas por compartirlas) y desde el que recibes la blocklist comunitaria curada.

El flujo de un ataque real es simple: un parser lee el log (Nginx, SSH, syslog) y lo entrega al motor. El motor evalúa el evento contra escenarios; cuando un patrón se cumple, el escenario genera una alerta. La alerta pasa por los profiles configurados en el LAPI, que la convierten en una decisión (típicamente un ban de 4 horas). El bouncer lee la decisión y la aplica. Si el motor está subscrito a la CAPI, la decisión también se comparte; a cambio, recibes la blocklist comunitaria, que se inyecta como decisiones adicionales en tu LAPI sin que tu servidor sufriera esos ataques directamente.

Instalación limpia en Debian/Ubuntu

La vía oficial es el script de bootstrap, que añade el repositorio de packagecloud y firma con la clave GPG del proyecto. Úsalo en lugar de instalar el paquete directo desde los repos de tu distro, porque las versiones en repos estables suelen estar muy por detrás (1.4.x frente a 1.8.x actuales) y perderías escenarios nuevos y fixes recientes.

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

El instalador genera un primer conjunto deparsers y escenarios a partir de los servicios detectados en el host (Nginx, SSH, Apache, Postfix, Docker, etc.). Comprueba qué activó ejecutando sudo cscli parsers list y sudo cscli scenarios list; si falta un servicio, instala su parser a posteriori con sudo cscli parsers install <nombre>.

Verifica la versión instalada y el estado del motor antes de añadir bouncers:

cscli version
sudo systemctl status crowdsec
sudo cscli hub list

Si systemctl status muestra active (running) y cscli hub list devuelve escenarios descargados, el motor está vivo. Si tienes un apt-cache policy crowdsec mostrando un candidato por debajo de 1.6.x en Ubuntu 24.04, prioriza el repo de CrowdSec con un fichero en /etc/apt/preferences.d/crowdsec que ponga Pin-Priority: 1001 para el origen packagecloud.io/crowdsec/crowdsec; en Pro/ESM Ubuntu el paquete de la distro puede tener mayor peso por defecto y dejarías la instalación obsoleta sin darte cuenta.

Añadir un bouncer firewall con iptables

El motor solo no bloquea: detecta, alerta y decide, pero la acción la tiene que hacer un bouncer. Empieza por el de iptables si proteges SSH, bases de datos o SMTP.

sudo apt install crowdsec-firewall-bouncer-iptables

Tras instalar, regístralo en el LAPI y comprueba que el servicio quedó activo:

sudo systemctl status crowdsec-firewall-bouncer
sudo cscli bouncers list

Si el bouncer no aparece, el registro automático falló (suele pasar cuando la instalación corre sin acceso al socket del LAPI). Lo registras manualmente y vuelcas la API key en su fichero de configuración:

sudo cscli bouncers add firewall-iptables
sudo install -m 600 /dev/null /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml
API_KEY=$(sudo cscli bouncers add firewall-iptables -o raw 2>/dev/null | tail -1)
echo -e "url: http://127.0.0.1:8080napi_key: ${API_KEY}nupdate_frequency: 10sn" | sudo tee /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml > /dev/null
sudo systemctl restart crowdsec-firewall-bouncer

Troubleshooting típico: si cscli bouncers list muestra el bouncer con last_pull fijo en el tiempo, el bouncer no está hablando con el LAPI. Comprueba con sudo ss -ltnp | grep 8080 que el LAPI escucha, y revisa journalctl -u crowdsec-firewall-bouncer -n 50 --no-pager para errores de autenticación. Una API key mal copiada o con saltos de línea es la causa más común.

Bouncer Nginx para WAF en capa 7

Si sirves una aplicación web, el bouncer de firewall solo bloquea a nivel IP. Para parar SQLi, XSS, path traversal y exploits de CVE conocidos en tiempo real, instala el bouncer de Nginx, que se enchufa como módulo Lua y consulta el LAPI en cada request.

sudo apt install crowdsec-nginx-bouncer

El paquete añade automáticamente la línea include /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf; en /etc/nginx/nginx.conf dentro del bloque http y carga las dependencias Lua. Verifica con:

sudo nginx -t
sudo systemctl reload nginx
sudo cscli bouncers list

La diferencia operativa frente a ModSecurity: el bouncer de CrowdSec consume decisiones del LAPI que ya pasaron por escenarios actualizados desde el Hub, así que no tienes que mantener un conjunto de reglas OWASP CRS a mano. Si quieres además protección AppSec (inspección profunda de payloads), necesitas el componente AppSec separado, que se documenta en la guía oficial y se activa con appsec_config: crowdsecurity/appsec-default en la sección config del motor.

Troubleshooting: si tras instalar ves HTTP 500 aleatorios, mira el error log de Nginx (tail -f /var/log/nginx/error.log): el síntoma típico es lua entry thread aborted: runtime error: ... no field package_preload, que significa que libnginx-mod-http-lua no está cargado. En Debian/Ubuntu con Nginx de los repos oficiales, sudo apt install libnginx-mod-http-lua lo resuelve; en Nginx compilado desde fuente o vía el repo de Nginx Inc, hay que añadir load_module modules/ndk_http_module.so; y load_module modules/ngx_http_lua_module.so; al top del nginx.conf.

Suscribirse a la blocklist comunitaria

Para que tu servidor se beneficie de las detecciones agregadas de la red, tienes que enlazar tu motor con la CAPI. El proceso usa un enrollment token que generas en la consola web de CrowdSec (app.crowdsec.net) y registras en el LAPI.

sudo cscli console enroll --token <TOKEN_DE_LA_CONSOLA>

Tras el enroll, el motor empieza a subir señales y a recibir la blocklist comunitaria. El tier que recibes depende de tu contribución:

• Community Blocklist: unos 15.000 IPs maliciosas, alineadas con los escenarios que reportas. Solo disponible si tus señales cumplen los criterios (escenarios oficiales sin modificar, contribución regular).
• Community Blocklist (Lite): máximo 3.000 IPs. Se asigna si no contribuyes o si tu señal se considera de baja visibilidad.
• Community Blocklist (Premium): para cuentas de pago, sin límite de tamaño ni requisito de contribución.

Reglas duras que muchos pasan por alto: solo cuentan las señales de escenarios oficiales del Hub sin modificar. Si copias un escenario y lo editas, tus señales se ignoran para el consenso, aunque localmente sigan disparando alertas. Modificar parsers, en cambio, no afecta la elegibilidad, porque el hash de los escenarios es lo que se verifica contra el consenso.

Comprueba tu tier con:

sudo cscli capi status
sudo cscli hub list | grep blocklist

Operación diaria: decisiones, métricas, listas

Una vez en marcha, lo que más vas a tocar son las decisiones activas. La interfaz de gestión es cscli; las decisiones se guardan en SQLite (o MySQL/Postgres si configuraste el LAPI con backend externo) y se replican en memoria al bouncer.

sudo cscli decisions list
sudo cscli alerts list --since 24h

Para liberar una IP legítima que cayó en un ban (un proveedor de monitorización, un balanceador que rota IPs, tu propia IP fija), primero identificas la decisión y luego la borras con cscli decisions delete:

sudo cscli decisions list -j | jq '.[] | select(.scope=="Ip") | select(.value=="203.0.113.42")'
sudo cscli decisions delete --ip 203.0.113.42 --reason "monitorizacion interna"

El parámetro --reason queda en el log de auditoría del LAPI. Úsalo siempre, porque cuando vuelvas a preguntarte por qué una IP se desbloqueó, el log es la única fuente. Para excepciones recurrentes, crea un parser whitelist o un filtro en el profile en lugar de borrar decisiones cada vez.

Si quieres exponer métricas, activa el listener Prometheus que viene con el motor y apúntale un scraper. Está desactivado por defecto para no exponer el endpoint sin querer:

sudo sed -i 's/^#s*listen_port:s*60601/listen_port: 60601/' /etc/crowdsec/config.yaml
sudo systemctl restart crowdsec

Cuándo CrowdSec no encaja

CrowdSec brilla en servidores expuestos a internet con tráfico de servicio identificable (SSH, Nginx, APIs autenticadas, SMTP). Donde no aporta tanto:

• Tráfico interno de microservicios: las IPs suelen ser efímeras y los escenarios no están pensados para east-west traffic. Cubre ese caso con políticas de red, no con CrowdSec.
• Endpoints con NAT masivo de salida: si tu tráfico legítimo sale por una IP compartida (CGNAT, VPN corporativa, móvil), un ban a esa IP te baneas a ti mismo. Usa whitelists para rangos conocidos antes de activar la firewall bouncer.
• Latencia sub-10ms en hot path: el bouncer de Nginx añade un lookup al LAPI en cada request, normalmente menor a 1 ms en local, pero en modo stream (descarga de decisiones a un cache) puedes llegar a cero. Si estás en un path que no tolera ni un milisegundo extra, considera el modo stream y mide.
• Equipos que quieren mantener todo on-prem sin nube: puedes operar CrowdSec sin CAPI y obtener solo las decisiones locales. Pierdes la blocklist comunitaria, pero todo el procesamiento queda en tu host.

En hosts con estas restricciones, fail2ban sigue siendo la opción más simple. CrowdSec no reemplaza a fail2ban en todos los casos; lo complementa en los que la reputación distribuida marca la diferencia.

Resumen

CrowdSec en 2026 es la opción de referencia cuando quieres detección + bloqueo + inteligencia compartida. Instala el motor desde el repo oficial, registra al menos un bouncer (firewall para SSH/DB, Nginx para tráfico web), enlaza con la CAPI si quieres la blocklist comunitaria, y acostúmbrate a cscli decisions list como primer paso antes de tocar reglas de iptables a mano. La versión 1.8.1 del motor trae fixes de falsos positivos en detección de bots (Brave con shields) y una API de challenges estable, así que es un buen momento para adoptarlo si todavía no lo tienes en producción.

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