Decision Processing
How the bouncer processes incoming CrowdSec decisions.
Processing flow
Section titled “Processing flow”-
Receive decision from LAPI
The bouncer fetches new and expired decisions from the CrowdSec Local API.
-
Check scope
Scope Action Example IpAdded directly to address list 192.168.1.1RangeAdded as CIDR to address list 10.0.0.0/24Other Logged as warning, skipped — -
Filter by origin
If
originsis configured, only decisions from allowed origins pass through. Unmatched decisions are discarded. -
Filter by scenario
If
scenariosis configured, only decisions matching the specified patterns pass through. Supports*and?wildcards. -
Apply action
- Ban → Add IP/range to the MikroTik address list
- Unban → Remove IP/range from the address list
Origin filtering
Section titled “Origin filtering”When origins is configured, the bouncer only processes decisions from the specified origins:
| Origin | Source |
|---|---|
crowdsec | Local CrowdSec engine detections |
cscli | Manual bans via cscli decisions add |
CAPI | CrowdSec Central API community blocklists |
lists:* | Third-party blocklist subscriptions |
crowdsec: origins: ["crowdsec", "cscli"] # Ignore CAPI community listsWhen origins is empty (default), all origins are accepted.
Scenario filtering
Section titled “Scenario filtering”When scenarios is configured, the bouncer only processes decisions matching the specified scenarios:
crowdsec: scenarios: - "crowdsecurity/ssh-bf" - "crowdsecurity/http-*"Pattern matching with * and ? wildcards is supported.
Duplicate IP handling
Section titled “Duplicate IP handling”When the same IP appears in multiple decisions (e.g., different scenarios or origins), the bouncer handles this efficiently:
- During bans: Uses the optimistic-add pattern — tries to add and silently handles “already exists” errors
- During unbans: Checks the in-memory cache first and only removes from MikroTik if the IP is actually present
- On startup: Decision collection pre-filters by deduplicating IPs before reconciliation