Le di memoria a Fail2Ban: la historia de ARE y la noche en que terminé baneándome a mí mismo

Fail2Ban hacía su trabajo, pero había situaciones en las que el resultado no me convencía. A veces bloqueaba lo que no debía y otras veces no parecía detectar lo que realmente me preocupaba.

No quería sumar otra herramienta de seguridad a la lista. Quería resolver algo que, desde mi punto de vista, faltaba: que el servidor pudiera recordar el comportamiento de una IP y tomar decisiones teniendo en cuenta su historial, no solamente el último evento registrado.

De esa idea nació ARE, Abuse Reputation Engine.

🇬🇧 English version of this article: https://dev.to/hernan_valero/i-gave-fail2ban-a-memory-the-story-of-are-and-the-night-i-ended-up-banning-myself-292f

Si preferís verlo antes que leerlo, 60-90s del escalado en vivo (WATCH → FILTER → TEMP_BAN):

No quería construir otro Fail2Ban

Desde el principio tuve algo claro: no quería reinventar Fail2Ban ni escribir otro detector que hiciera prácticamente lo mismo.

Fail2Ban ya cumplía una función útil. Analizaba registros, detectaba patrones de actividad sospechosa y podía aplicar sus propias sanciones. Lo que yo quería era aprovechar las detecciones y los informes de las herramientas que ya estaban funcionando en el servidor, no duplicar su trabajo.

La idea detrás de ARE era reunir esas señales en un historial de reputación, relacionarlas con su categoría y gravedad, y dejar que el motor evaluara el conjunto antes de decidir cómo actuar.

Fail2Ban y los demás sensores aportan detecciones; ARE añade contexto, mantiene la reputación y toma decisiones según sus propias políticas.

No significa que Fail2Ban deje de aplicar sus reglas ni que todas las herramientas tengan exactamente la misma función. Significa que yo quería una capa adicional capaz de evaluar el comportamiento acumulado de una IP, en lugar de depender únicamente de decisiones tomadas por separado.

Una detección aislada no siempre cuenta toda la historia. Pero cuando se combina con otros eventos y con lo que esa dirección ha venido haciendo a lo largo del tiempo, puede adquirir un significado distinto.

No necesitaba otro detector compitiendo con los que ya tenía. Necesitaba una capa que pudiera aprovechar sus resultados, relacionarlos y tomar decisiones con una perspectiva más amplia.

El problema que quería resolver

Las herramientas de seguridad que utilizamos habitualmente tienen una función concreta. Fail2Ban analiza eventos y aplica sanciones según las reglas configuradas. ModSecurity inspecciona peticiones HTTP y puede bloquear las que coinciden con determinadas reglas. Un firewall controla el tráfico según sus políticas.

No tengo nada en contra de esas herramientas. Al contrario, forman parte de una buena defensa. El problema aparece cuando intentamos interpretar un comportamiento que no cabe fácilmente en una regla aislada.

Un intento fallido de acceso puede ser un error legítimo. Una petición extraña puede ser un escáner. Una sucesión de intentos distribuidos en el tiempo puede revelar algo más preocupante que cualquiera de esos eventos por separado.

¿Cómo distinguirlos?

Me preocupaban dos escenarios. Por un lado, alguien que distribuye sus intentos para mantenerse por debajo de determinados umbrales. Por otro, un usuario legítimo que termina bloqueado porque una conexión inestable o una sucesión de peticiones normales se parece demasiado a un abuso.

No pretendía resolver todos los problemas de seguridad con una sola herramienta. Quería añadir una pieza que ayudara a interpretar el contexto.

La idea era sencilla: que una IP no empezara de cero cada vez que generaba un evento.

Así empezó a tomar forma ARE.

ARE: reputación en lugar de reacciones aisladas

Desde el principio tuve claro que no quería introducir una infraestructura innecesariamente compleja. La idea era construir un motor que pudiera funcionar sobre un servidor Linux, apoyándose en herramientas conocidas y sin depender de un servicio externo.

Bash, SQLite, IPSet y systemd. Componentes sencillos, accesibles y relativamente fáciles de inspeccionar.

No necesitaba otro agente escrito en un lenguaje de moda ni una plataforma que obligara a mantener una infraestructura adicional. Necesitaba que la lógica de decisión fuera comprensible y que pudiera saber por qué el sistema había tomado una decisión determinada.

El núcleo de ARE gira alrededor de varios principios.

No todos los eventos significan lo mismo

Uno de los problemas que quería evitar era tratar todos los eventos sospechosos como si tuvieran la misma importancia.

No es lo mismo detectar reconocimiento de puertos que registrar un intento de explotación. Tampoco es lo mismo una anomalía de protocolo que un intento de obtener credenciales.

Por eso ARE organiza los eventos en nueve categorías: RECON, EXPLOIT, CREDENTIAL, PROTOCOL, BOT, ANOMALY, MALWARE, DOS y SOCIAL.

Cada categoría contribuye a la reputación de acuerdo con su propia puntuación. De esta forma, una actividad habitual de exploración no pesa necesariamente lo mismo que una señal de explotación.

Me interesaba conservar esa distinción. Si todo acaba convertido en un único número sin contexto, se pierde información que puede ser importante para decidir qué hacer.

El tiempo también importa

La reputación no puede ser completamente estática. Una dirección IP puede cambiar de usuario, pertenecer a una conexión compartida o ser reutilizada. Mantener una sanción indefinidamente sin considerar el paso del tiempo puede terminar perjudicando a quien no tiene relación con los eventos originales.

Pero tampoco quería que una IP recuperara su reputación de un momento a otro simplemente porque dejó de generar actividad durante unos minutos.

ARE aplica una pérdida gradual de peso (decay) a la reputación. El historial se conserva, mientras su influencia disminuye con el tiempo.

La intención es encontrar un equilibrio: recordar lo suficiente como para detectar persistencia, sin convertir un comportamiento pasado en una condena eterna.

Primero observar, después restringir

Otra decisión de diseño fue establecer una respuesta escalonada:

ALLOW → WATCH → FILTER → TEMP_BAN → BANNED

No todas las IP sospechosas deben terminar baneadas. El sistema puede pasar de permitir el tráfico a vigilarlo, filtrarlo y aplicar restricciones más severas a medida que aumenta la reputación.

La persistencia importa, pero también importa la gravedad de lo observado. La secuencia representa los estados de decisión definidos por ARE; no significa que cualquier IP tenga que recorrer todas las etapas en ese orden.

La reputación no se reinicia porque una jaula libere una IP

Esta es una parte importante de la idea original.

Fail2Ban puede retirar un baneo cuando se cumple la política de una jaula. Eso significa que terminó esa sanción concreta; no demuestra por sí solo que todo el historial de la IP haya dejado de ser relevante.

ARE está pensado para conservar y evaluar su propia reputación. La liberación de una jaula no debería confundirse automáticamente con una rehabilitación global de la dirección: el motor debe valorar el conjunto de señales que conoce y aplicar su propia política.

En mi diseño, esta separación de responsabilidades importa mucho. Los sensores detectan y las herramientas existentes pueden actuar dentro de sus reglas; ARE aporta una evaluación más amplia del historial. La forma exacta en que se coordinan los bloqueos y las liberaciones depende de la integración configurada, y es un aspecto que debe comprobarse en cada despliegue.

ARE también contempla compartir reputación entre servidores propios, utilizando categorías y puntuaciones como criterios de selección, sin depender de una plataforma de terceros.

El objetivo no es sustituir todo lo que ya existe. Es añadir una capa de contexto y decisión a las herramientas que ya realizan la detección.

La prueba que decidí hacer en mi propio VPS

Y una noche decidí ponerlo a prueba de una manera bastante directa: intentar que mi propio servidor se defendiera de mí. Una cosa es diseñar un sistema sobre el papel y otra comprobar cómo se comporta cuando recibe actividad real.

ARE ya estaba funcionando en mi VPS de producción. Así que decidí realizar una prueba controlada desde una IP propia, sin involucrar a terceros y utilizando únicamente peticiones no destructivas.

Hay un detalle importante: el servidor no estaba protegido por una única barrera.

En el borde tenía Cloudflare, que presenta desafíos ante determinados tipos de tráfico. Después, ModSecurity, entre otras herramientas, inspeccionaba las peticiones que llegaban al servidor. Finalmente, en el origen estaba ARE, trabajando con los eventos que sus sensores registraban.

Para evaluar ARE necesitaba que mi tráfico de prueba llegara al origen. Por eso utilicé una excepción controlada para mi propia IP en la capa perimetral.

Una vez preparado el escenario, probé patrones habituales de reconocimiento y explotación: intentos de SQL injection, local file inclusion (LFI), path traversal, XSS e inyección de comandos. Todo de forma no destructiva, sin intentar modificar datos ni comprometer información.

Era mi servidor, sí, pero también estaba en producción y tenía clientes reales. No tenía ningún sentido convertir una prueba de seguridad en un incidente que yo mismo hubiera provocado.

ModSecurity comenzó a responder con códigos HTTP 403 ante las firmas que reconocía.

Hasta ahí, todo estaba dentro de lo esperado.

Entonces fui a revisar qué había registrado ARE.

Los números y el momento en que pensé que algo fallaba

En la primera ronda, la reputación de mi IP aparecía así:

Exploit 9 · Credential 2 · Anomaly 7
Total 18 · Riesgo: LOW · Decisión: WATCH

La primera reacción que tuve fue mirar el resultado desde el otro lado: el navegador seguía recibiendo respuestas HTTP 200 en algunas peticiones.

Mi interpretación inicial fue que ARE no estaba reaccionando.

Pero había cometido un error bastante habitual cuando uno está probando su propio sistema: estaba esperando una respuesta inmediata de un proceso que trabaja por ciclos.

Los sensores registran los eventos y ARE los procesa conforme a su ciclo de evaluación. Si consulto el estado antes de que ese ciclo termine, puedo estar viendo una situación que todavía no refleja toda la actividad que acabo de generar.

Un código HTTP 200 tampoco demuestra, por sí solo, que una petición haya tenido éxito desde el punto de vista del ataque. Indica que el servidor respondió con ese código; para interpretar el resultado hay que mirar qué respondió y qué ocurrió después.

Esperé, volví a comprobar el estado y lancé una segunda ronda, más intensa.

Minutos después, los números habían cambiado:

Exploit 12 · Anomaly 13 · Total 27 · Riesgo: MEDIUM

La línea de decisión reflejaba la progresión:

WATCH (18, LOW)
    ↓
FILTER (27, MEDIUM)
    ↓
BAN

La IP terminó bloqueada.

Y esa IP era la de mi propia conexión doméstica.

Me había baneado a mí mismo.

Tuve que recuperar el acceso mediante la consola fuera de banda de mi VPS. Precisamente para eso existe ese tipo de acceso: poder administrar una máquina cuando las vías de conexión habituales dejan de estar disponibles.

No fue el resultado más cómodo de la noche, pero sí una de las comprobaciones más útiles que podía hacer. La política de bloqueo no se había quedado en una cifra o una alerta: había producido una consecuencia real.

Qué aprendí de la prueba

No voy a decir que una prueba de este tipo demuestra que un sistema de reputación está perfectamente calibrado. Sería exagerar lo que realmente comprobé.

Lo que sí pude observar fue cómo ARE acumulaba las señales, cómo cambiaba la evaluación después de una nueva ronda de actividad y cómo terminaba aplicando una restricción efectiva.

También me dejó varias lecciones.

La primera: hay que distinguir entre un fallo y un retraso.

Mi impresión inicial de que ARE no reaccionaba se adelantó a los datos disponibles. El tiempo de procesamiento importaba. Antes de modificar la lógica del motor, tenía que comprobar si había terminado el ciclo de evaluación.

La segunda: sumar eventos no significa necesariamente sumar riesgo de manera indiscriminada.

El reconocimiento básico no debe tratarse igual que una secuencia de señales de explotación. Si elevamos demasiado el peso de la actividad exploratoria, podemos terminar bloqueando tráfico legítimo. Si lo reducimos demasiado, podemos perder señales útiles. La calibración requiere observar resultados y revisar los umbrales, no limitarse a declarar que funcionan.

La tercera: una herramienta puede hacer bien su trabajo sin tener toda la información.

ModSecurity bloqueó las peticiones que reconoció. ARE evaluó los eventos que recibió y terminó tomando su propia decisión. Son funciones distintas y complementarias.

La seguridad por capas no consiste en instalar varias herramientas que hacen exactamente lo mismo, sino en combinar mecanismos que cubren partes diferentes del problema.

Y la cuarta: un bloqueo real vale más que una línea bonita en un registro.

Ver una puntuación aumentar es útil. Comprobar que la política termina aplicándose también lo es. Pero ambas cosas deben acompañarse de pruebas adicionales: falsos positivos, recuperación del acceso, persistencia de las sanciones y comportamiento ante IP compartidas o reutilizadas.

Que el sistema me haya bloqueado durante esta prueba es una señal de que el mecanismo de respuesta funcionó en ese escenario. No es una garantía de que vaya a acertar siempre.

Dónde está ARE hoy

ARE está en producción, en su rama 2.8.x, y también lo están utilizando algunos colegas.

El proyecto cuenta con documentación sobre su arquitectura, su diseño y el ciclo de vida de los baneos. Su objetivo sigue siendo el mismo que me llevó a escribir las primeras líneas: incorporar una capa de reputación persistente a la seguridad del servidor, utilizando las señales que ya producen las herramientas existentes.

No lo presento como un reemplazo de Fail2Ban ni de CrowdSec. Son proyectos con objetivos y mecanismos propios. ARE busca cubrir otro espacio: evaluar el comportamiento acumulado de una IP, mantener reputación por categorías y utilizar esa información para decidir cuándo observar, filtrar o bloquear.

Todo ello con Bash, SQLite y herramientas que un administrador puede inspeccionar sin tener que desplegar una infraestructura adicional.

¿Es la solución definitiva? No. Todavía hay decisiones de puntuación, decaimiento y respuesta que deben validarse en diferentes escenarios. Y una herramienta que interviene directamente en el acceso a un servidor siempre necesita políticas prudentes y una vía de recuperación.

Pero el hecho de que pueda ejecutarlo en producción, observar su comportamiento y probarlo de manera controlada me permite avanzar sobre algo más que una idea.

Por qué comparto esto

ARE nació porque había algo en la forma de gestionar los baneos que no me convencía. No quería acumular herramientas ni repetir el trabajo que ya hacían las que tenía. Quería que las detecciones pudieran convertirse en decisiones basadas en un historial.

Quería que una IP tuviera contexto. Que un evento no se interpretara siempre de manera aislada. Que el sistema pudiera distinguir entre una señal puntual y un comportamiento que se repite, sin convertir cada anomalía en una sentencia.

Esa noche terminé recuperando el acceso a mi VPS por la consola fuera de banda porque ARE había bloqueado mi propia IP. No es una prueba definitiva de que el modelo sea correcto, pero sí una experiencia real que me permitió comprobar cómo respondía el sistema.

Ahora me interesa contrastar ese enfoque con otros administradores y desarrolladores. No porque considere que ARE ya tiene todas las respuestas, sino porque quiero descubrir dónde funciona bien, dónde puede equivocarse y qué debería mejorar.

Si trabajas con servidores Linux, sistemas de detección de intrusiones o mecanismos de reputación de IP, me gustaría conocer tu opinión sobre el modelo de puntuación por categorías, el decaimiento de la reputación y la política de baneos escalonados.

¿Qué escenarios te preocuparía que este enfoque pasara por alto? ¿Dónde ves mayor riesgo de falsos positivos? ¿Cómo abordarías la reutilización de direcciones IP y la reputación compartida entre servidores?

El código está disponible bajo licencia GPL-3.0:

Repositorio de ARE: https://github.com/hvalero2001-commits/ARE

Toda crítica técnica fundamentada es bienvenida. Quiero seguir probando ARE en escenarios reales, revisar lo que ocurre y corregir lo que haga falta.