CrowdSec frente a Fail2Ban: diferencias en la aplicación práctica

Entender bien CrowdSec y Fail2Ban

La elección adecuada no depende de qué herramienta se considere más moderna, sino del servidor, los datos de registro y el punto de aplicación deseado. Para un único servicio SSH con mensajes de error claros, Fail2Ban puede resultar muy eficaz. CrowdSec cobra interés cuando hay que evaluar y proteger conjuntamente varias fuentes de registros, distintos niveles de protección o sistemas distribuidos.

Ambas soluciones sirven para Detección de ataques basada en registros: Analizan eventos relevantes para la seguridad, como intentos fallidos de inicio de sesión, los clasifican según un patrón y pueden bloquear una dirección IP. Para ello, Fail2Ban combina filtros y acciones en «jails». CrowdSec procesa los datos leídos a través de su motor de seguridad y toma decisiones, cuya aplicación corre a cargo de un componente de corrección independiente.

Lo decisivo es lo que realmente se registra. Sin marca de tiempo, una dirección IP de origen útil y una fuente de registro adecuada, ninguna de las herramientas puede atribuir un ataque de forma fiable. Además, un bloqueo solo protege allí donde es técnicamente aplicable: una regla de cortafuegos local no sirve automáticamente de ayuda si el tráfico de datos pasa primero por un proxy inverso externo o un equilibrador de carga.

Como Prevención de intrusiones Ambas herramientas complementan una arquitectura de seguridad, pero no la sustituyen. Las actualizaciones de seguridad corrigen las vulnerabilidades conocidas; un proceso de inicio de sesión seguro y, a ser posible, en varias etapas, limita el uso indebido de las cuentas; y unas reglas básicas restrictivas del cortafuegos reducen los servicios accesibles. Las copias de seguridad limitan los daños tras un incidente, mientras que la supervisión continua de los registros también pone de manifiesto problemas que no activan ningún bloqueo.

Por lo tanto, la cuestión práctica es la siguiente: ¿qué patrones hay que detectar, en qué punto debe producirse la reacción y quién se encarga de gestionar las reglas, las excepciones y los registros? Solo entonces se podrá decidir con fundamento si basta con una configuración local de «jail» manejable o si los componentes independientes de CrowdSec aportan un valor añadido apreciable a la infraestructura.

Cómo vincula Fail2Ban las «jails» y las acciones

Fail2Ban gestiona la detección y la respuesta en Cárceles. En SSH, por ejemplo, una «jail» lee los protocolos de autenticación o el registro del sistema. Un filtro busca en ellos los intentos fallidos de inicio de sesión procedentes de una IP de origen. Si, dentro del intervalo de tiempo configurado, esta IP supera el número permitido de intentos fallidos, Fail2Ban considera la coincidencia como un caso de bloqueo.

La acción posterior determina la reacción. A menudo complementa una regla del cortafuegos local, aunque también son posibles otras acciones configuradas. De este modo, la cadena resulta comprensible: la fuente de registro proporciona líneas, el filtro detecta los eventos relevantes, la «jail» los cuenta y la acción aplica la contramedida prevista. Esto facilita la localización de errores, siempre que el formato del registro y el filtro sean compatibles.

Una «jail» utiliza exactamente un filtro, pero puede ejecutar varias acciones. Así, por ejemplo, el mismo caso detectado de bloqueo de SSH puede desencadenar una acción del cortafuegos y, además, activar una notificación. La realización de varias acciones hace que la reacción sea más flexible, pero no altera la base de la detección: todas dependen del mismo filtro y de su interpretación de las líneas del registro.

Los textos escritos por uno mismo requieren un cuidado especial Filtro de expresiones regulares. La documentación disponible sobre los filtros es, expresamente, una guía de desarrollo para Fail2Ban 0.9.0.dev y no una prueba de funcionamiento para una versión estable concreta del paquete. Sus indicaciones generales siguen siendo útiles para el desarrollo de filtros: deben cubrirse las variantes reales de los formatos de registro, mientras que los patrones no deben ser demasiado amplios. Por lo tanto, los nuevos filtros deben comprobarse primero con líneas de ejemplo anonimizadas antes de que activen bloqueos.

Los cambios locales deben guardarse siempre en archivos con la extensión .local, no en los entregados .conf-Archivos. De este modo, los valores personalizados para las rutas de registro, las redes permitidas o las acciones se mantienen más fáciles de rastrear en las actualizaciones de paquetes y no se sobrescriben sin más. Además, antes de la implementación, se debe comprobar si la fuente de registro seleccionada existe realmente y contiene los eventos esperados.

El proceso de CrowdSec: del registro al bloqueo

CrowdSec separa más claramente la detección y la aplicación en componentes individuales. En primer lugar, las fuentes de adquisición definen qué registros o flujos de eventos se recopilan. Los analizadores normalizan estos datos; a continuación, los escenarios evalúan los patrones y el comportamiento. Si se detecta un patrón coincidente, se genera una alerta. A partir de ahí, la API local puede tomar una decisión basada en los perfiles configurados, como, por ejemplo, un bloqueo de IP de duración limitada.

Un breve ejemplo ilustra el proceso: los errores de autenticación de un servicio llegan al motor a través de la adquisición. Los analizadores identifican campos como la hora, el servicio y la IP de origen; un escenario evalúa los intentos fallidos repetidos. La alerta generada a partir de ello se transmite a la API local, que puede tomar una decisión utilizando un perfil adecuado. Solo una Componente de remediación aplica esta decisión en el punto de protección previsto.

A este componente también se le conoce tradicionalmente como «Bouncer». Dependiendo de la variante, puede aplicar decisiones, por ejemplo, en un cortafuegos, un proxy inverso o un servidor web. El motor de seguridad por sí solo detecta incidentes y gestiona las alertas y las decisiones a través de la API local, pero no bloquea el tráfico de datos. Sin un componente de corrección correctamente conectado, una decisión generada no supone más que una notificación, sin que se produzca ningún bloqueo activo de la red o de la aplicación.

En la práctica, esta separación permite distribuir la detección y el bloqueo entre distintos puntos de la infraestructura. Sin embargo, aumenta el alcance de las operaciones: la fuente de registros, la conexión local a la API, los permisos y la asignación de Bouncer deben coincidir. Especialmente cuando hay varios servicios, hay que comprobar si el Remediation Component se encuentra realmente delante del servicio cuyos accesos debe bloquear en virtud de una decisión.

Hay que distinguir entre los aciertos de escenarios locales y la opción Lista de bloqueados de la comunidad. En caso de participación voluntaria, se pueden aportar señales y obtener decisiones seleccionadas sobre atacantes ya conocidos. Se trata de una fuente preventiva adicional, pero no sustituye a la detección local ni garantiza la detección de atacantes nuevos o que pasen desapercibidos. Por lo tanto, el origen de una decisión de bloqueo debe seguir siendo trazable durante el funcionamiento.

Comparar las herramientas según su uso

La elección entre CrowdSec y Fail2Ban debe partir del aspecto de la protección, no de una valoración general de la calidad. Fail2Ban analiza las entradas de registro mediante filtros y las vincula a acciones en las «jails». CrowdSec procesa las fuentes de registro mediante analizadores y escenarios para generar alertas; a partir de ahí, la API local puede generar decisiones con perfiles, que a su vez se aplican mediante componentes de corrección independientes. Ambos dependen de que los eventos se registren correctamente.

La tabla no es una clasificación. En el caso de unos pocos patrones de registro bien conocidos, suele ser más fácil comprobar una «jail» local: la fuente del registro, el filtro y la acción del cortafuegos se encuentran muy próximos entre sí. En cuanto intervienen varias fuentes, sistemas previos o distintos puntos de aplicación, puede resultar conveniente separar la detección y la reacción en CrowdSec. Sin embargo, esto también exige gestionar las relaciones entre los componentes de forma transparente.

En lo que respecta al criterio de protección web, el nivel técnico es decisivo. Un «Bouncer» de CrowdSec aplica decisiones a nivel de red, pero no analiza el contenido HTTP. En una configuración de AppSec compatible, un «Bouncer» adecuado reenvía las solicitudes HTTP al componente AppSec del motor de seguridad, donde se evalúan las reglas de AppSec. Esta comprobación complementa el desarrollo seguro y las actualizaciones puntuales, en lugar de corregir vulnerabilidades conocidas.

Caso práctico de un VPS individual con SSH

En un pequeño VPS de Linux con SSH y una pila web sencilla, Fail2Ban suele ser una opción fácil de controlar. En primer lugar, comprueba si los intentos fallidos de inicio de sesión por SSH, con la marca de tiempo y la IP de origen, aparecen de forma fiable en el registro o diario correspondiente. Sin estos datos, una «jail» no puede contabilizar de forma fiable los intentos fallidos ni pasar la dirección correcta a una acción.

A continuación, selecciona una «jail» SSH adecuada y comprueba que los filtros, los intervalos de tiempo, el número de intentos fallidos permitidos y la duración del bloqueo se ajusten a tu situación real de inicio de sesión. Una «jail» vincula un filtro con una o varias acciones. De este modo, es posible, por ejemplo, delegar el bloqueo al cortafuegos local sin duplicar la lógica de detección. Para un único host, esta vinculación suele hacer que el proceso resulte transparente.

Las redes administrativas, los accesos de emergencia y los sistemas de monitorización requieren excepciones definidas de forma deliberada. Estas deben estar estrictamente limitadas y no eximir de forma generalizada a las grandes redes de proveedores. Además, antes de la implementación, comprueba qué reglas de cortafuegos establece realmente la acción y si IPv4 e IPv6 se ajustan al diseño del servidor. Un inicio controlado con registros supervisados es más seguro que un bloqueo inmediato y prolongado.

Propia Filtro de expresiones regulares solo tienen sentido cuando no existe ningún filtro que cubra ese formato de registro concreto. La guía disponible para el desarrollo de filtros está etiquetada como documentación de Fail2Ban 0.9.0.dev y, por lo tanto, no corresponde a ninguna versión estable como la 1.1.1. No obstante, sus consejos de desarrollo resultan prácticos: comprueba los nuevos patrones con líneas de ejemplo reales anonimizadas y con líneas similares, pero legítimas. La herramienta de prueba fail2ban-regex Sirve para validar el filtro; no modifica ningún bloqueo de producción.

La configuración local debe incluirse en .local-archivos, no incluidos en la entrega .conf-Archivos. De este modo, los ajustes realizados en las actualizaciones de paquetes se pueden rastrear y no se sobrescriben por error. Tras cada cambio, comprueba por separado la entrada del registro, el estado de la «jail» y la acción desencadenada; un servicio en ejecución por sí solo no constituye aún una cadena de bloqueo efectiva.

Proxies, IP real del cliente y protección web

Una CDN, un equilibrador de carga o un proxy inverso modifican la dirección que ve el servidor. Si el servidor web solo recibe la IP del proxy y la registra como cliente, un bloqueo basado en registros podría, en el peor de los casos, identificar al intermediario común en lugar del visitante atacante. Por lo tanto, antes de cada «jail», cada escenario y cada regla WAF, debe quedar claro cómo se transmite, se acepta y se registra de forma fiable la IP original del cliente.

Esta cadena de confianza no debe aceptar sin más cualquier encabezado entrante. Solo las direcciones de proxy conocidas deben estar autorizadas a proporcionar una dirección reenviada; de lo contrario, los clientes externos podrían falsificar la identidad en la que se basan la detección y el bloqueo. Comprueba, mediante extractos de registros anonimizados, si los registros de la aplicación y de acceso muestran la misma IP de cliente. Documenta, además, el reenvío de encabezados entre el borde y el origen. Solo tras verificar la IP del cliente es posible interpretar de forma adecuada una reacción ante eventos HTTP sospechosos.

A Bloqueo de IP Limita las conexiones a nivel de cortafuegos antes de que lleguen a la aplicación, pero no comprueba el contenido de las solicitudes. En una configuración de CrowdSec AppSec compatible, un «bouncer» adecuado reenvía las solicitudes HTTP al componente AppSec del motor de seguridad; donde se comprueban las reglas de AppSec correspondientes. Por el contrario, un «bouncer» que funciona únicamente como cortafuegos aplica las decisiones a nivel de red y no realiza ninguna comprobación HTTP. La variante más adecuada dependerá del punto de entrada real del tráfico y de los componentes utilizados.

Además, la detección basada en registros es de carácter retrospectivo: primero debe producirse un incidente, registrarse correctamente y reconocerse como patrón. No impide un único ataque exitoso sin que se produzca un incidente posterior que llame la atención, ni sustituye a los parches ni a un inicio de sesión seguro. Por lo tanto, los componentes previos deben integrarse en la arquitectura de seguridad global con sus transferencias fiables, registros y puntos de protección.

En la práctica, esto significa lo siguiente: primero decide si se debe proteger el acceso a la red, la solicitud HTTP o ambos niveles. A continuación, documenta el recorrido desde la dirección pública, pasando por el proxy, hasta la entrada del registro, y comprueba los bloqueos con una dirección de prueba autorizada. De este modo, evitarás que una conexión que aparentemente funciona Prevención de intrusiones solo afecta al componente de infraestructura incorrecto.

Proteger varios servidores de forma controlada

En cuanto intervienen varios hosts, contenedores o registros recopilados de forma centralizada, la separación entre la detección y la aplicación de medidas en CrowdSec resulta muy útil. El motor de seguridad puede evaluar eventos procedentes de fuentes definidas, mientras que los componentes de corrección adecuados aplican las decisiones en los puntos protegidos correspondientes. CrowdSec también documenta para ello las implementaciones distribuidas y la integración junto con los flujos de registros centralizados.

Esto no reduce automáticamente los gastos de funcionamiento. En primer lugar, debe poder identificarse claramente, para cada fuente de registro, a qué servicio y a qué cliente está asignada. A continuación, cada «bouncer» necesita una conexión claramente delimitada a la API local, así como su propia clave de acceso. Un «bouncer» de proxy inverso, por ejemplo, no protege necesariamente un servicio SSH al que se puede acceder por separado; el Asignación de porteros debe seguir las rutas de datos reales.

Por lo tanto, el seguimiento debe incluir la gestión de tokens, la disponibilidad de la API, los registros de eventos y de errores, así como la comprobación de la eficacia del bloqueo. Una decisión no es más que un resultado de detección hasta que el componente previsto la recupere y la aplique. En caso de modificaciones en contenedores, proxies o reglas de cortafuegos, se debe volver a comprobar esta cadena para garantizar que una detección que funcione no pase desapercibida sin una reacción efectiva.

Si ya existen cadenas y reglas propias, el Firewall-Bouncer puede, en el Modo «solo configuración» gestionar exclusivamente conjuntos creados previamente. La responsabilidad sobre las reglas y las cadenas recae entonces, de forma deliberada, en el administrador. Esto se ajusta a los conceptos de cortafuegos controlados y a los requisitos de cumplimiento normativo, pero exige comprender el orden de las reglas existentes y no supone una simplificación para los principiantes.

Comprobar sistemáticamente los errores típicos

Si no se produce el bloqueo, es más útil seguir un orden de comprobación fijo que cambiar la herramienta de forma precipitada. En primer lugar, hay que aclarar si el evento esperado se recibe realmente con marcas de tiempo plausibles. A continuación, hay que comprobar que la dirección registrada sea realmente la IP del cliente. Solo entonces se puede comprobar de forma sensata si el filtro o el escenario reconocen el patrón y, a partir de ahí, se toma una decisión de bloqueo.

En Fail2Ban, tras la entrada en el registro se lleva a cabo la comprobación de la «jail», el filtro y el recuento de coincidencias. Una «jail» vincula un filtro con una o varias acciones; en el caso de las rutas de registro basadas en archivos, al inicio solo se tienen en cuenta los archivos ya existentes que se ajustan al patrón «glob». En el caso de los registros de systemd, hay que comprobar por separado el backend y los derechos de acceso. Una «jail» que parezca correcta no ofrece protección si no lee la fuente real.

Las expresiones regulares propias requieren especial precaución. La guía de filtros disponible está etiquetada como documentación de desarrollo para Fail2Ban 0.9.0.dev y no debe interpretarse como una referencia válida para la versión 1.1.1 de Fail2Ban. No obstante, su recomendación resulta útil para el desarrollo de filtros propios: comprueba primero los patrones con líneas de ejemplo anónimas y representativas, así como con líneas que no coincidan deliberadamente. De este modo, se pueden detectar variantes del formato de registro y posibles clasificaciones erróneas antes de que se aplique un bloqueo en producción.

En CrowdSec, tras una coincidencia con un escenario, también hay que comprobar toda la cadena de aplicación: si se genera una alerta, ¿puede la API local generar una decisión a partir de ella utilizando un perfil, y llega esta decisión al componente de corrección previsto? Sin un «bouncer» correctamente conectado, la decisión queda sin efecto si no va acompañada de un bloqueo activo. A continuación, hay que comprobar el funcionamiento del cortafuegos o del proxy en el punto de entrada adecuado, sin bloquearse el propio acceso administrativo.

Mantener la solución adecuada a largo plazo

Fail2Ban suele ser adecuado para un único servidor con patrones de registro locales bien definidos, como intentos fallidos repetidos de conexión SSH. Sus «jails», filtros y acciones pueden aplicarse directamente a un servicio concreto. CrowdSec resulta más interesante cuando hay que coordinar varias fuentes de registros, distintos puntos de aplicación o la protección web con un componente adecuado. Lo decisivo es la trazabilidad de los datos, no un juicio general sobre cuál es la herramienta más moderna.

Ambas soluciones requieren un proceso de modificación regulado: controlar las versiones de las configuraciones, comprobar primero los nuevos filtros o escenarios con ejemplos de registros conocidos y supervisar los bloqueos. Las actualizaciones merecen la misma atención. Fail2Ban 1.1.1 se publicó el 15 de agosto de 2026. Las adaptaciones locales y las acciones del cortafuegos que se aplican realmente deben compararse con el entorno de destino antes de realizar una actualización.

Prevención de intrusiones complementa la base de seguridad, pero no la sustituye: siguen siendo necesarias las actualizaciones puntuales, un inicio de sesión seguro y, a ser posible, en varias etapas, reglas de cortafuegos restrictivas, copias de seguridad y supervisión de registros. Especialmente en entornos de alojamiento web, también se debe mantener el tiempo de ejecución de las aplicaciones. El artículo sobre CloudLinux Alt-PHP y sus aspectos de seguridad muestra por qué las versiones de tiempo de ejecución independientes y bien mantenidas forman parte de un modelo operativo sólido.

En el caso de los servicios web, la documentación operativa debe incluir además la ruta completa desde el cliente, pasando por la CDN o el proxy inverso, hasta el servidor de origen. Los cambios en los protocolos y las rutas de entrega pueden influir en qué componente acepta las conexiones y qué dirección aparece en el registro. El artículo sobre HTTP/2 Server Push en el alojamiento web explica, a modo de ejemplo, cómo interactúan el navegador, la CDN y el servidor web durante la entrega. En cuanto a la lógica de bloqueo, lo fundamental —independientemente de ello— es que la dirección IP del cliente, transmitida de forma fiable, esté disponible en el punto de protección adecuado.

La elección a largo plazo debe poder revisarse: si cambian los formatos de registro, las rutas de proxy, los servicios o el número de servidores, un concepto que antes era adecuado puede presentar lagunas. Por eso, deja constancia de qué eventos deben detectarse, dónde se aplican las decisiones y quién autoriza las excepciones. Esto Disciplina laboral convierte el bloqueo de una dirección IP en una medida de protección controlable, en lugar de un cambio en el cortafuegos que se realiza sin supervisión.