Skip to content

Decision Processing

How the bouncer processes incoming CrowdSec decisions.

  1. Receive decision from LAPI

    The bouncer fetches new and expired decisions from the CrowdSec Local API.

  2. Check scope

    ScopeActionExample
    IpAdded directly to address list192.168.1.1
    RangeAdded as CIDR to address list10.0.0.0/24
    OtherLogged as warning, skipped
  3. Filter by origin

    If origins is configured, only decisions from allowed origins pass through. Unmatched decisions are discarded.

  4. Filter by scenario

    If scenarios is configured, only decisions matching the specified patterns pass through. Supports * and ? wildcards.

  5. Apply action

    • Ban → Add IP/range to the MikroTik address list
    • Unban → Remove IP/range from the address list

When origins is configured, the bouncer only processes decisions from the specified origins:

OriginSource
crowdsecLocal CrowdSec engine detections
cscliManual bans via cscli decisions add
CAPICrowdSec Central API community blocklists
lists:*Third-party blocklist subscriptions
crowdsec:
origins: ["crowdsec", "cscli"] # Ignore CAPI community lists

When origins is empty (default), all origins are accepted.

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.

When the same IP appears in multiple decisions (e.g., different scenarios or origins), the bouncer handles this efficiently:

  1. During bans: Uses the optimistic-add pattern — tries to add and silently handles “already exists” errors
  2. During unbans: Checks the in-memory cache first and only removes from MikroTik if the IP is actually present
  3. On startup: Decision collection pre-filters by deduplicating IPs before reconciliation