Router Setup

This guide covers the MikroTik RouterOS configuration required for cs-routeros-bouncer.

API Service

The bouncer communicates with MikroTik via the RouterOS API. Ensure the API service is enabled:

/ip/service/print

You need either:

• api (port 8728) — plaintext connection
• api-ssl (port 8729) — TLS-encrypted connection Recommended

To enable:

# Enable plaintext API
/ip/service/enable api

# Enable TLS API (recommended)
/ip/service/enable api-ssl

Production recommendation

Use TLS (port 8729) for production deployments. Configure the bouncer with mikrotik.tls: true.

API User

Create a dedicated RouterOS user with minimal permissions:

1. Create a group with only the required policies

   /user/group/add name=crowdsec policy=read,write,api,!sensitive,!ftp,!local,!ssh,!reboot,!policy,!test,!password,!sniff,!romon,!rest-api

2. Create the API user

   /user/add name=crowdsec group=crowdsec password=YOUR_SECURE_PASSWORD

Required policies

Policy	Why
read	Read firewall rules and address lists
write	Create/modify/delete firewall rules and address lists
api	Access the RouterOS API

Denied policies

All other policies are explicitly denied to follow the principle of least privilege:

!sensitive, !ftp, !local, !ssh, !reboot, !policy, !test, !password, !sniff, !romon, !rest-api

Denying !policy is safe even though the bouncer runs a script for each bulk chunk: through /execute on RouterOS 7.8rc1 and later, and as a temporary /system/script before that. RouterOS only requires the policy permission to run a script whose own policy set exceeds the caller’s; /execute runs with the caller’s policies, and a script created over the API inherits them — so read,write,api is sufficient. Verified with groups carrying no more than these policies, against RouterOS 7.24.1 for the stored script and 7.24.4 for /execute: bulk adds go through and are not degraded to per-address writes.

sensitive is not needed either: it reveals passwords, keys and other secrets, and the bouncer reads none. Verified against RouterOS 7.24.4 with a group carrying only read,write,api: filter and raw rules for IPv4 and IPv6 (input, output, whitelist, reject) created and removed, every bulk-add path (/execute, the stored script, api), live bans and unbans, and the router metrics.

Firewall access

If you have firewall rules restricting API access, allow connections from the bouncer host:

# For plaintext API (port 8728)
/ip/firewall/filter/add chain=input protocol=tcp dst-port=8728 src-address=BOUNCER_IP action=accept comment="Allow CrowdSec bouncer API access" place-before=0

# For TLS API (port 8729) — if using tls: true
/ip/firewall/filter/add chain=input protocol=tcp dst-port=8729 src-address=BOUNCER_IP action=accept comment="Allow CrowdSec bouncer API-SSL access" place-before=0

Replace BOUNCER_IP with the IP address of the machine running the bouncer.

Security

Restrict API access to only the bouncer host IP. Never expose the API port to the internet.

TLS Configuration

For TLS connections:

1. Ensure your router has a valid certificate (self-signed or CA-signed)

2. Enable the api-ssl service

   /ip/service/enable api-ssl

3. Configure the bouncer

   mikrotik:
     address: "192.168.0.1:8729"
     tls: true
     tls_insecure: false # Keep false after installing trust; true disables verification for troubleshooting only

Verification

After setup, verify the API user can connect:

# Test plaintext API connectivity
nc -vz ROUTER_IP 8728
# Test TLS API connectivity (if using api-ssl)
openssl s_client -connect ROUTER_IP:8729 -servername ROUTER_IP </dev/null

Or use the bouncer’s health endpoint after starting:

curl http://localhost:2112/health
# {"status":"ok","routeros_connected":true,"version":"vX.Y.Z"}

Next: InstallationDeploy the bouncer using Docker, systemd, or build from source.