Security

Supported versions

Version	Supported
Latest release	✓
Previous minor	✓
Older versions	✗

Reporting vulnerabilities

1. Do not open a public issue

2. Contact privately

   Email the maintainer directly or use GitHub’s private vulnerability reporting feature.

3. Include details

   • Description of the vulnerability
   • Steps to reproduce
   • Potential impact
   • Suggested fix (if any)

We aim to respond within 48 hours and will work with you to understand and address the issue.

Security considerations

RouterOS API credentials

• Use a dedicated user with minimal permissions (only api, read, write policies)
• Use TLS when possible (mikrotik.tls: true)
• Store credentials securely (environment variables or secrets management)
• Never commit credentials to version control

CrowdSec LAPI connection

• Use TLS certificates for LAPI connections when available
• Restrict LAPI access to trusted networks
• Rotate bouncer API keys periodically

Metrics endpoint

Caution

The /metrics and /health endpoints do not require authentication. Restrict access via network segmentation or firewall rules. Do not expose the metrics port to the internet.

Docker security

• The official Docker image runs as a non-root user
• Use read-only filesystem mount where possible
• Limit container capabilities
• Use secrets management for credentials (Docker secrets, Kubernetes secrets)

Systemd hardening

The setup command writes a systemd unit with hardening enabled:

Setting	Purpose
NoNewPrivileges=yes	Prevents privilege escalation through exec transitions
ProtectSystem=strict	Mounts system paths read-only for the service
ProtectHome=yes	Blocks direct access to home directories
ReadWritePaths=/var/log	Allows log file writes when logging.file points under /var/log
PrivateTmp=yes	Gives the service an isolated temporary directory
LimitNOFILE=65536	Leaves headroom for RouterOS API sessions and HTTP endpoints

If you maintain a manual unit file, keep these settings unless your deployment has a specific reason to relax one.

Firewall rule integrity

• The bouncer identifies its rules by structured comments — do not modify these comments manually
• Use the comment_prefix option to avoid conflicts with other tools
• The bouncer performs cleanup on startup and shutdown to prevent stale rules
• Every bouncer rule also includes the fixed @cs-routeros-bouncer signature. This lets crash-recovery cleanup find old rules even if comment_prefix changes later.