Protección del servidor Linux: Parte 3 — CrowdSec

Fail2ban protege cada servidor por separado: solo ve sus propios logs y no sabe que esas mismas direcciones hace un minuto atacaron miles de otras máquinas. CrowdSec resuelve la misma tarea — detectar un ataque a partir de los logs y bloquear la dirección — pero añade al análisis local una lista común de direcciones atacantes que recopilan todos sus usuarios.

CrowdSec se distribuye bajo la licencia MIT. Versión actual — 1.8.1 (03.09.2026).

Cómo funciona CrowdSec

En la documentación de CrowdSec se usan los siguientes conceptos:

• Security Engine — el propio sistema de detección. Consiste en un procesador de logs (Log Processor, a menudo llamado agente) y una API local.
• Log Processor lee los logs de los servicios y las peticiones HTTP, los analiza con parsers y los coteja con escenarios — descripciones de comportamientos maliciosos: fuerza bruta, escaneo, búsqueda de rutas vulnerables en un sitio.
• Local API (LAPI) almacena las decisiones de bloqueo y las distribuye a los componentes de respuesta. A través de ella el Security Engine también intercambia datos con la API central de CrowdSec.
• Componentes de respuesta (Remediation Components, llamados bouncers) — programas independientes que reciben las decisiones desde LAPI y aplican el bloqueo: en el firewall, en el servidor web, en el proxy inverso.
• Colecciones — conjuntos preparados de parsers y escenarios para un servicio concreto (SSH, Nginx, Postfix, etc.). Se almacenan en el directorio Hub.
• Console — interfaz web para ver las alertas y bloqueos de todos los servidores conectados.

Un detalle importante, mencionado explícitamente en la documentación: el Security Engine por sí solo no bloquea nada, es solo el sistema de detección. Sin un componente de respuesta CrowdSec encontrará ataques, pero dejará pasar a los atacantes.

Lista común de atacantes

Cuando su servidor detecta un ataque, envía una señal — la dirección y el escenario que se disparó — a la API central. A partir de las señales de miles de instalaciones de CrowdSec se compila la Community Blocklist y se distribuye entre los participantes. Las condiciones dependen de la contribución:

• quien envía señales regularmente, recibe la lista completa — hasta 15 000 direcciones, filtradas por escenarios que también aparecen en su servidor;
• quien no envía señales, recibe una versión reducida — hasta 3 000 direcciones;
• los planes de pago dan hasta 60 000 direcciones.

Así el servidor bloquea por adelantado direcciones que aún no han atacado a éste, pero ya han sido detectadas en otras máquinas.

Instalación en Debian y Ubuntu

curl -s https://install.crowdsec.net | sudo sh
sudo apt install crowdsec
sudo apt install crowdsec-firewall-bouncer-nftables   # o -iptables

El primer comando añade el repositorio de CrowdSec, el segundo instala el Security Engine, el tercero — el componente de respuesta para el firewall. Al instalar CrowdSec intenta detectar los servicios en ejecución y automáticamente instala los parsers y escenarios adecuados. Si algún servicio no se detecta, su log se añade manualmente en la configuración de fuentes y se instala la colección necesaria:

sudo cscli collections list
sudo cscli collections install crowdsecurity/nginx
sudo systemctl reload crowdsec

Primeros comandos

sudo cscli metrics                 # qué se está leyendo y qué se dispara
sudo cscli alerts list             # ataques detectados
sudo cscli decisions list          # bloqueos activos
sudo cscli decisions delete --ip 203.0.113.10   # quitar bloqueo
sudo cscli console enroll <clave>   # conectar el servidor a Console

cscli metrics — el principal comando de diagnóstico: si no muestra líneas para el log deseado, CrowdSec no lo está leyendo y ese servicio no está protegido.

Listas blancas

Antes de activar los bloqueos, añada a la lista blanca sus direcciones: oficina, servidores de monitorización, direcciones desde las que trabajan los administradores. La documentación recomienda este paso por separado — una falsa detección sobre su propio monitor hará que también lo bloquee como si fuera un bot.

En qué se diferencia CrowdSec de Fail2ban

Para un único servidor con SSH Fail2ban es suficiente. CrowdSec está justificado cuando hay varios servidores, cuando hace falta proteger aplicaciones web por comportamiento y no solo por accesos fallidos, y cuando se desea bloquear atacantes conocidos desde el primer intento.

Ejecutar Fail2ban y CrowdSec simultáneamente sobre los mismos logs no tiene sentido: duplicarán los bloqueos y será más difícil averiguar quién bloqueó una dirección. Normalmente se elige uno u otro.

Errores típicos

• Instalado solo el Security Engine sin componente de respuesta — los ataques se ven en cscli alerts, pero nadie es bloqueado.
• No se añadieron a la lista blanca las propias direcciones y la monitorización.
• El servicio escribe el log en un lugar no estándar, CrowdSec no lo lee y el administrador está convencido de que el servicio está protegido. Se verifica con cscli metrics.
• El componente de respuesta seleccionado no es para el firewall correcto (iptables en lugar de nftables).
• Las colecciones no se actualizan: los escenarios en el Hub se complementan regularmente, la actualización — cscli hub update y cscli hub upgrade.

Cómo integrar CrowdSec en el esquema general de protección de un servidor nuevo está descrito en el artículo «Un servidor nuevo no es una hoja en blanco».