CrowdSec separa la detección de la acción. El motor de seguridad (el servicio crowdsec) lee los logs, aplica escenarios y toma decisiones (por ejemplo, banear una IP durante 4 horas). Los bouncers consultan esas decisiones en la API local (LAPI) y las ejecutan: el bouncer de firewall las convierte en reglas de nftables. La consola web de CrowdSec muestra las alertas de todos tus servidores y te permite suscribirte a listas de bloqueo. En este tutorial instalarás el bouncer de firewall en Ubuntu 24.04, inscribirás el servidor en la consola y aprenderás a gestionar decisiones, listas blancas y un escenario propio.
Requisitos previos
- Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
- Un usuario no root con privilegios
sudo. - Acceso alternativo al servidor (consola VNC del panel) por si un bloqueo te deja fuera por SSH.
- Una cuenta gratuita en app.crowdsec.net para la parte de la consola.
- El puerto
8080libre en127.0.0.1: la LAPI escucha ahí por defecto.
Paso 1: Instalar el motor de CrowdSec
Si ya tienes CrowdSec funcionando, salta al paso 2. El método oficial añade el repositorio de CrowdSec con un script. Descárgalo y revísalo antes de ejecutarlo:
curl -fsSL https://install.crowdsec.net -o /tmp/crowdsec-repo.sh
less /tmp/crowdsec-repo.sh
sudo sh /tmp/crowdsec-repo.sh
Instala el motor:
sudo apt install crowdsec
Durante la instalación, CrowdSec detecta los servicios presentes (SSH, Nginx...) e instala las colecciones correspondientes. Compruébalo:
sudo systemctl status crowdsec --no-pager
sudo cscli collections list
COLLECTIONS
Name Status Version Local Path
crowdsecurity/linux enabled ... /etc/crowdsec/collections/linux.yaml
crowdsecurity/sshd enabled ... /etc/crowdsec/collections/sshd.yaml
Si instalas Nginx más tarde, añade su colección y recarga: sudo cscli collections install crowdsecurity/nginx y sudo systemctl reload crowdsec.
Paso 2: Instalar el bouncer de firewall
Sin un bouncer, CrowdSec detecta y decide pero no bloquea nada. El bouncer de firewall es el más eficiente porque descarta el tráfico en el kernel, antes de que llegue a SSH o al servidor web. Ubuntu 24.04 usa nftables, así que instala esa variante:
sudo apt install crowdsec-firewall-bouncer-nftables
Al instalarse en el mismo servidor que el motor, el paquete se registra solo en la LAPI y guarda su clave en /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml. Comprueba que el servicio está activo y que la LAPI lo reconoce:
sudo systemctl status crowdsec-firewall-bouncer --no-pager
sudo cscli bouncers list
Name IP Address Valid Last API pull Type Version
cs-firewall-bouncer-1727260000 127.0.0.1 true 2026-09-25T10:31:02Z crowdsec-firewall-bouncer v0.0.x
Una fecha reciente en Last API pull indica que el bouncer está consultando decisiones. El bouncer crea sus propias tablas de nftables (crowdsec para IPv4 y crowdsec6 para IPv6), independientes de UFW, así que ambos conviven sin problemas.
Paso 3: Probar un bloqueo con una decisión manual
Añade una decisión de baneo de 5 minutos para una IP de documentación:
sudo cscli decisions add --ip 203.0.113.50 --duration 5m --reason "prueba de bouncer"
sudo cscli decisions list
ID Source Scope:Value Reason Action Country AS Events expiration Alert ID
1 cscli Ip:203.0.113.50 prueba de bouncer ban 1 4m58s 1
En pocos segundos el bouncer la aplica. Búscala en nftables:
sudo nft list table ip crowdsec | grep 203.0.113.50
elements = { 203.0.113.50 timeout 4m55s expires 4m40s }
Elimina la decisión y confirma que desaparece del firewall:
sudo cscli decisions delete --ip 203.0.113.50
Otras variantes útiles: --range 198.51.100.0/24 para una red completa y --duration 168h para una semana. No bloquees rangos amplios sin revisar antes a quién pertenecen.
Paso 4: Inscribir el servidor en la consola
La consola centraliza las alertas de todos tus motores, permite ver el contexto de cada ataque y suscribirse a listas de bloqueo gestionadas. Entra en la consola, pulsa Add Security Engine y copia la clave de inscripción que muestra. En el servidor:
sudo cscli console enroll your_enrollment_key
Enrolled to the CrowdSec Console
Please accept the new instance on the console page.
Vuelve a la consola, acepta la instancia pendiente y reinicia el motor para que empiece a enviar datos:
sudo systemctl restart crowdsec
Revisa qué información compartes con la consola:
sudo cscli console status
La salida lista opciones como custom (alertas de escenarios propios), manual (decisiones añadidas con cscli), tainted (escenarios modificados localmente), context y console_management. Esta última permite gestionar decisiones y listas de bloqueo desde la web; actívala solo si la vas a usar:
sudo cscli console enable console_management
sudo systemctl restart crowdsec
Cuando te suscribes a una lista de bloqueo en la consola, sus IPs llegan al motor como decisiones con origen lists y el bouncer las aplica igual que las locales:
sudo cscli decisions list --origin lists | head
Paso 5: Evitar bloqueos a tus propias IPs
Si tu oficina, tu bastión o el sistema de monitorización generan tráfico que parece un ataque, te acabarás bloqueando. Una lista blanca de parser descarta esos eventos antes de que lleguen a los escenarios.
Crea el fichero en la etapa de enriquecimiento (s02-enrich):
sudo nano /etc/crowdsec/parsers/s02-enrich/mis-ips-confianza.yaml
name: local/mis-ips-confianza
description: "IPs de administración y monitorización"
whitelist:
reason: "IP de confianza"
ip:
- "198.51.100.20"
cidr:
- "10.0.0.0/8"
Sustituye las direcciones por las tuyas y recarga el motor:
sudo systemctl reload crowdsec
sudo cscli parsers list | grep mis-ips-confianza
local/mis-ips-confianza enabled,local /etc/crowdsec/parsers/s02-enrich/mis-ips-confianza.yaml
Comprueba que un intento de SSH desde esa IP quedaría ignorado con cscli explain, que pasa una línea por todo el proceso de parseo:
sudo cscli explain --log "Sep 25 11:02:10 web01 sshd[3321]: Invalid user test from 198.51.100.20 port 52144" --type syslog
En la salida, la etapa s02-enrich debe mostrar tu lista con el evento marcado como whitelisted. La lista blanca no elimina decisiones que ya existan: si ya te habías bloqueado, bórrala con cscli decisions delete --ip.
Paso 6: Crear un escenario propio
Los escenarios de tipo leaky funcionan como un cubo que se llena con cada evento y se vacía a un ritmo fijo: si se desborda, se genera una alerta y una decisión. Este ejemplo detecta a quien hace más de 30 peticiones a /api/ en ráfaga, con la colección crowdsecurity/nginx instalada:
sudo nano /etc/crowdsec/scenarios/api-abuse.yaml
type: leaky
name: local/api-abuse
description: "Demasiadas peticiones a /api/ desde la misma IP"
filter: "evt.Meta.log_type == 'http_access-log' && evt.Meta.http_path startsWith '/api/'"
groupby: evt.Meta.source_ip
capacity: 30
leakspeed: "1s"
blackhole: 5m
labels:
service: http
behavior: "http:scan"
label: "Abuso de la API"
remediation: true
capacity: 30 con leakspeed: "1s" permite ráfagas de 30 peticiones y un ritmo sostenido de una por segundo. blackhole evita repetir la alerta para la misma IP durante 5 minutos y remediation: true hace que la alerta genere un baneo.
sudo systemctl reload crowdsec
sudo cscli scenarios list | grep api-abuse
Ajusta capacity y leakspeed a tu tráfico real antes de dejarlo en producción: una aplicación de página única legítima puede hacer decenas de llamadas a la API al cargar.
Paso 7: Consultar decisiones desde tus aplicaciones
Cualquier programa puede preguntar a la LAPI si una IP está baneada, igual que hace un bouncer. Crea una clave de bouncer para tu integración y guárdala, porque solo se muestra una vez:
sudo cscli bouncers add mi-integracion
API key for 'mi-integracion':
your_api_key
Please keep this key since you will not be able to retrieve it!
Consulta una IP:
curl -s -H "X-Api-Key: your_api_key" "http://127.0.0.1:8080/v1/decisions?ip=203.0.113.50"
Si la IP no tiene decisiones, la respuesta es null; si está baneada, un array JSON con el tipo (ban), el ámbito y la duración restante. Las claves de bouncer solo permiten leer decisiones; para crearlas usa cscli decisions add.
Solución de problemas
El bouncer no aparece en cscli bouncers list o Last API pull está vacío. Revisa su log con sudo journalctl -u crowdsec-firewall-bouncer -n 50. Si la clave no es válida, crea una nueva con sudo cscli bouncers add firewall-bouncer, pégala en api_key de /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml y reinicia el servicio.
CrowdSec no detecta nada. Comprueba que lee los logs con sudo cscli metrics: en la sección de adquisición, cada fichero debe tener líneas leídas y parseadas. Si un fichero no aparece, añádelo en /etc/crowdsec/acquis.d/ y recarga.
Te has bloqueado a ti mismo. Entra por la consola VNC del panel, ejecuta sudo cscli decisions list para encontrar tu IP, bórrala con sudo cscli decisions delete --ip tu_ip y añádela a la lista blanca del paso 5.
Falso positivo de un escenario. Localiza la alerta con sudo cscli alerts list y examínala con sudo cscli alerts inspect -d ID. Si el tráfico es legítimo, añade la IP a la lista blanca o ajusta el escenario.
Conclusión
Tu servidor ya bloquea en el firewall las IPs que CrowdSec detecta, reporta a la consola y protege tus direcciones de administración con una lista blanca. Como siguientes pasos, inscribe el resto de tus servidores en la misma consola para ver los ataques de forma conjunta, suscríbete a alguna lista de bloqueo y añade el bouncer de Nginx o de tu proxy si necesitas respuestas en capa 7, como un captcha.