RouterOS Bouncer

Cómo funciona

1. 01CrowdSec decideLa Local API tiene una decisión sobre una dirección.
2. 02El bouncer sincronizaLee las decisiones nuevas y da por vencidas las que terminaron.
3. 03RouterOS la aplicaLas direcciones llegan a una address-list que las reglas gestionadas usan.
4. 04Tú lo vigilasMétricas de Prometheus, endpoint de salud y panel de Grafana.

Por qué cs-routeros-bouncer v1.5.0

La mayoría de los bouncers para MikroTik regeneran una address-list desde un script programado. Este mantiene abierta una sesión y aplica cada decisión de CrowdSec como una sola llamada a la API de RouterOS.

Ningún comando manual en el router

Escribe las 8 reglas que necesita una configuración de partida al arrancar y las elimina al parar. Configuras el bouncer, no el router.

Una escritura por decisión (~1–3 ms/op)

Una dirección añadida al banear y una eliminada al desbanear, en torno a 1–3 ms cada una. Sin recargas masivas y sin duplicados.

Reconciliación, no confianza

Al arrancar y de forma periódica compara la Local API con lo que hay realmente en el router; después añade lo que falta y elimina lo obsoleto.

Observable mientras funciona

Métricas de Prometheus de decisiones, CPU de RouterOS y tráfico descartado; logs estructurados; endpoint de salud; panel de Grafana en el repositorio.

Un binario, licencia MIT

Compilado con Go 1.27 y publicado como 16 binarios precompilados para 4 sistemas operativos, más imágenes Docker multiarquitectura.

Lo que escribe en tu router

CrowdSec decide qué direcciones son hostiles. Este bouncer aplica esa decisión y nada más: no tiene detección, ni puntuación, ni criterio propio. Aplicarla significa escribir en un firewall en producción, así que aquí está todo lo que escribe y todo lo que no va a limpiar por ti.

Lo que escribe

Una configuración de partida deja 8 reglas en el router: 4 tipos, un juego por familia de protocolo. Estas, literalmente.

Reglas que escribe una configuración de partida

/ip/firewall/filter add chain=input action=passthrough comment="crowdsec-bouncer:filter-input-counting-v4 @cs-routeros-bouncer"
/ip/firewall/filter add chain=input action=drop src-address-list=crowdsec-banned comment="crowdsec-bouncer:filter-input-input-v4 @cs-routeros-bouncer"
/ip/firewall/raw add chain=prerouting action=passthrough comment="crowdsec-bouncer:raw-prerouting-counting-v4 @cs-routeros-bouncer"
/ip/firewall/raw add chain=prerouting action=drop src-address-list=crowdsec-banned comment="crowdsec-bouncer:raw-prerouting-input-v4 @cs-routeros-bouncer"
/ipv6/firewall/filter add chain=input action=passthrough comment="crowdsec-bouncer:filter-input-counting-v6 @cs-routeros-bouncer"
/ipv6/firewall/filter add chain=input action=drop src-address-list=crowdsec6-banned comment="crowdsec-bouncer:filter-input-input-v6 @cs-routeros-bouncer"
/ipv6/firewall/raw add chain=prerouting action=passthrough comment="crowdsec-bouncer:raw-prerouting-counting-v6 @cs-routeros-bouncer"
/ipv6/firewall/raw add chain=prerouting action=drop src-address-list=crowdsec6-banned comment="crowdsec-bouncer:raw-prerouting-input-v6 @cs-routeros-bouncer"

Las direcciones baneadas van a crowdsec-banned y crowdsec6-banned. Las dos reglas passthrough no coinciden con ninguna address-list ni toman ninguna decisión; cuentan los paquetes que evalúa el bloque, que es lo que hace que «evaluados» y «descartados» sean dos cifras distintas en las métricas.

Lo que no hace

Aplica; no decide

Todos los baneos vienen de CrowdSec. Sin CrowdSec no tiene nada que escribir: ni escenarios, ni puntuación, ni direcciones propias. Cómo una decisión se convierte en regla

Un tipo de decisión, no cuatro

De los tipos de decisión de CrowdSec, ban es el único que se aplica por defecto. El bouncer tiene exactamente una acción —poner la dirección en una lista que el firewall descarta— así que una decisión de captcha podría listarse en crowdsec.supported_decisions_types pero se aplicaría como bloqueo, que no es lo que significa un captcha. El ajuste está para tipos personalizados que sí signifiquen “bloquear”. Cómo se procesan las decisiones

Las reglas entran arriba del todo

Por defecto el bloque gestionado se inserta en lo alto de cada chain que toca, por encima de tus reglas existentes: firewall.rule_placement.strategy vale top por defecto. Para quien tiene su conjunto de reglas ordenado a conciencia esto es lo más determinante que le hace el bouncer, así que conviene decir que la ubicación es lo más configurable de todo esto, no lo menos: cinco estrategias (top, bottom, before_comment, after_comment, position), cada una redefinible por tabla y por familia de protocolo, con un fallback para cuando la regla ancla no existe. Ubicación de las reglas

La primera sincronización es una importación masiva

La primera reconciliación se trae todas las decisiones activas que tiene la Local API, incluidas las listas de bloqueo comunitarias CAPI de CrowdSec: crowdsec.origins está vacío por defecto, así que no se filtra ningún origen. Son decenas de miles de direcciones escritas de una sola vez, y en un router pequeño lo vas a ver pasar en la gráfica de CPU. Listas de bloqueo CAPI

Cada pasada de reconciliación cuesta CPU del router

No solo al arrancar, ni solo cuando hay desviación que reparar: la pasada corre en cada tick de crowdsec.reconciliation_interval y vuelve a leer la lista de direcciones entera, porque RouterOS resuelve las consultas de address-list con un escaneo lineal sin indexar. Medido en un RB5009 con 22.000 entradas, muestreado a 100 ms en el propio router: una meseta de ~2 segundos con una media del 31% frente a una base del 5%, con rebanadas de un solo core llegando al 50–100%, en cada ciclo. Con el intervalo por defecto de 15 minutos son cuatro transitorios por hora. Es probable que tu monitorización no lo vea: el OID SNMP estándar hrProcessorLoad reporta una media de un minuto, que aplana un pico de dos segundos hasta un 6% aproximado. Ajuste de rendimiento

Lo que el daemon deja atrás

Al apagarse elimina todas las reglas anteriores y ninguna entrada de las address-lists. Las entradas expiran por su propio timeout de MikroTik, que es la duración de la decisión de CrowdSec; la protección, por tanto, sobrevive al daemon lo que quede de ella.Advertencia: Una decisión cuya duración resuelve a cero o menos —CrowdSec sí emite duraciones restantes negativas— se escribe sin timeout alguno, así que esa entrada permanece en el router hasta que algo la elimine: la siguiente reconciliación, o tú. Una decisión que no trae campo de duración se descarta antes y nunca llega al router.

Requisitos

• CrowdSec 1.5+ con la Local API accesible desde el host donde corre el bouncer
• MikroTik RouterOS 7.x con el servicio API habilitado (puerto 8728, u 8729 para TLS)
• Un usuario dedicado de la API de RouterOS con permiso para leer y escribir reglas de firewall y address-lists

Preguntas frecuentes

¿Qué es cs-routeros-bouncer?

cs-routeros-bouncer es un bouncer de CrowdSec gratuito y de código abierto para MikroTik RouterOS. Sincroniza las decisiones de bloqueo/desbloqueo de CrowdSec con las reglas del firewall de RouterOS (filter y raw, IPv4 e IPv6) a través de la API de RouterOS, con reconciliación al inicio y periódica, métricas de Prometheus y limpieza segura de reglas.

¿Qué versiones de CrowdSec y RouterOS soporta?

Requiere CrowdSec 1.5+ con la Local API (LAPI) accesible desde el host del bouncer, y MikroTik RouterOS 7.x con el servicio API habilitado (puerto 8728, u 8729 para TLS), usando un usuario dedicado de la API de RouterOS con los permisos apropiados.

¿Es cs-routeros-bouncer gratuito y de código abierto?

Sí. cs-routeros-bouncer tiene licencia MIT, está escrito en Go, se distribuye como un único binario estático, con el código fuente completo en GitHub y sin planes de pago.

¿Soporta cs-routeros-bouncer IPv6?

Sí. Cada tipo de regla de RouterOS que gestiona (filter input, raw prerouting y opcionalmente filter output) tiene un equivalente IPv6, y la ubicación de las reglas IPv4/IPv6 puede configurarse de forma conjunta o sobrescribirse de forma independiente por protocolo.

¿En qué se diferencia cs-routeros-bouncer de los bouncers de CrowdSec para MikroTik basados en address-list o en scripts?

cs-routeros-bouncer se comunica directamente con la API de RouterOS y aplica cada bloqueo o desbloqueo como una llamada individual en tiempo real (alrededor de 1–3 ms), en lugar de regenerar periódicamente listas de direcciones mediante scripts programados. También ejecuta una reconciliación al inicio y periódica contra el estado real de MikroTik, de modo que las desviaciones se reparan automáticamente.

Explora la documentación

Inicio rápidoPonlo en marcha en 5 minutos con Docker o systemd.

Referencia de configuraciónTodas las opciones de configuración explicadas con ejemplos.

Monitorización y métricasMétricas de Prometheus, panel de Grafana y comprobaciones de salud.

Solución de problemasProblemas comunes y sus soluciones.