CROWDSEC · TECH
CrowdSec: open-source WAF with collaborative blocklist for SME servers
CrowdSec is the MIT-licensed intrusion detection with crowd-sourced threat intelligence from 100k+ servers. May 2026 SME market leader with AI Bouncer.
Researched & fact-checked by: DuneDive LLC · As of: 2026-05
What is CrowdSec?
CrowdSec is an open-source security engine that as of May 2026 ranks as the market leader for application-layer intrusion detection in the SME segment. Developed since 2020 by a French SAS headquartered in Paris, the software is released under MIT license and thus usable for commercial own-use without restrictions.
The decisive difference from classic tools like Fail2ban lies in the collaborative blocklist: each CrowdSec installation worldwide reports observed attacks (only an IP hash plus the matched attack pattern) anonymously to the central platform. As of May 2026, more than 100,000 servers worldwide are connected, jointly maintaining an active blocklist of 4 to 6 million malicious IPs. An IP attacking a WordPress login in Berlin is blocked on a server in Zurich within 90 seconds.
The architecture consists of three clearly separated components. The Agent reads log sources (nginx, sshd, postfix, custom applications), parses them into structured events, and decides based on YAML scenarios whether an attack is present. Bouncers are plugins that enforce the decision: cs-firewall-bouncer sets an iptables DROP rule, cs-nginx-bouncer returns HTTP 403, cs-cloudflare-bouncer enters the IP into the Cloudflare block list. The Console is the central dashboard that aggregates nodes and distributes the shared blocklist.
In May 2026 the key novelty is the AI Bouncer rolled out productively in Q1 2026. A light ML model runs locally on the agent and detects behavioral anomalies beyond classic rule thresholds: request rate, path sequences, user-agent drift, header anomalies. It catches attackers that stay under classic triggers (for example 1 login attempt per minute instead of 5 per minute) and are missed by Fail2ban or pure pattern-matching WAFs. The AI Bouncer is included free in the Community Edition.
Why it matters for Swiss SMEs and fiduciaries
Three arguments make CrowdSec a mandatory layer for every Swiss SME server with public reachability as of May 2026.
Threat landscape: a typical Hetzner or Infomaniak server sees 200 to 5000 failed login attempts per day, automated WordPress scans, SSH brute force from botnets, API token burn attacks. A pure network firewall (UFW/nftables) does not help because packets are formally valid and the application must respond. CrowdSec drops packets in iptables after 3 to 5 failed attempts before they reach the application. Server CPU load drops measurably; real incidents become visible in logs again.
Regulatory link: Art. 8 revFADP demands state-of-the-art protective measures. The FDPIC guideline explicitly lists firewall and brute-force protection under technical and organisational minimum measures. Anyone running a client portal without a documented intrusion-detection layer does not meet the duty of care under Art. 717 CO for board members. Cyber insurance (Helvetia, Mobiliar, AXA, Zurich) has required documented brute-force protection since 2025 -- CrowdSec delivers an auditable list via cscli decisions list.
Fiduciary fit: law firms and fiduciaries with professional-secrecy duties under Art. 321 SCC must prevent unauthorised third-party access to client files. An open nginx endpoint without brute-force protection does not meet this standard. The collaborative blocklist delivers an advantage local tooling can never match: botnets seen today on a server in France are already blocked at a Swiss client portal before they even start a first attempt. With over 2 million active IPs on the crowd list in May 2026, that covers the bulk of automated attack surface.
Architecture and Docker Compose setup
CrowdSec runs as a systemd service or Docker container. We show the productive Docker Compose setup we use at Fairlane for client deployments.
```yaml version: "3.8" services: crowdsec: image: crowdsecurity/crowdsec:latest container_name: crowdsec restart: unless-stopped environment: - COLLECTIONS=crowdsecurity/nginx crowdsecurity/sshd crowdsecurity/linux - GID=1000 volumes: - ./crowdsec-config:/etc/crowdsec - ./crowdsec-data:/var/lib/crowdsec/data - /var/log/nginx:/var/log/nginx:ro - /var/log/auth.log:/var/log/auth.log:ro ports: - "127.0.0.1:8080:8080" bouncer-firewall: image: crowdsecurity/firewall-bouncer:latest container_name: cs-firewall-bouncer restart: unless-stopped network_mode: host cap_add: - NET_ADMIN - NET_RAW volumes: - ./bouncer-config:/etc/crowdsec/bouncers ```
The agent container reads logs read-only via bind mounts. Acquis configuration in /etc/crowdsec/acquis.yaml defines log sources per service. Parsers decompose log lines via grok patterns into structured events (source_ip, request_path, status_code). Scenarios are YAML rules matching conditions -- the default http-bruteforce scenario fires on 10 failed logins within 60 seconds and bans the IP for 4 hours.
Console enrolment via cscli console enroll <key>. The node thereby joins the network: it receives the crowd blocklist (update every 15 minutes) and reports own decisions back anonymously. Community Edition is free up to 3 machines per account; from May 2026 with Premium Tier up to 25 machines without surcharge for small SME setups.
Important cscli commands: cscli decisions list shows active bans with source, duration, scenario. cscli alerts list lists historical incidents. cscli metrics shows processed events per parser and scenario. cscli bouncers add <name> registers a new bouncer with a unique token. cscli decisions delete --ip <ip> manually unblocks.
The AI Bouncer extension is added via cscli hub install crowdsecurity/ai-anomaly-detection and needs around 50 MB of additional storage. The model is retrained monthly based on global telemetry and then distributed to all nodes -- no outbound inference API calls, no client data leaves the server.
CrowdSec setup in 5 steps
- 01Harden the network firewall: ufw default deny incoming, ufw allow 22/2847/80/443, enable SSH public-key auth, whitelist office IP.
- 02Install CrowdSec via Docker Compose or curl -s https://install.crowdsec.net | sudo sh; install collections for nginx, sshd, linux.
- 03Set up bouncers: cs-firewall-bouncer for iptables DROP plus cs-nginx-bouncer for layer-7 block; generate bouncer tokens via cscli bouncers add.
- 04Connect Console via cscli console enroll <key>, activate crowd blocklist, install AI Bouncer via cscli hub install crowdsecurity/ai-anomaly-detection.
- 05Whitelist and observe mode: enter office IP, monitoring IPs, health-check endpoints under scenarios/whitelists.yaml; run AI Bouncer in observe mode for 1-2 weeks, then enforce.
When to deploy CrowdSec
CrowdSec belongs on every Linux server with public reachability and multiple applications. Concrete triggers for installation: (a) the server has a login endpoint (Nextcloud, Bitwarden, client portal, admin backend), (b) the server runs an API with paid calls (OpenAI, Anthropic, Stripe) where token burn attacks directly cause cost, (c) the server has a mail service (postfix) needing auth brute-force protection, (d) several servers should share threat intel.
Good fit for typical SME stacks: Hetzner Cloud with Docker Compose and n8n/Grafana/Qdrant; Infomaniak Public Cloud with custom apps; a self-hosted Nextcloud for client files; a fiduciary portal on Cloudron or Coolify. Compared to Fail2ban, CrowdSec brings three advantages: collaborative blocklist (90 percent of brute-force attempts are already blocked before reaching the server at all), clean separation of agent and bouncer (multiple bouncers in parallel possible), YAML scenarios instead of Fail2ban regex in INI files.
Explicitly recommended for May 2026: SMEs with 2-10 servers running heterogeneous workloads (web server plus API plus mail). Console sync ensures that an attack on the web server automatically yields a ban on the mail server. Enable AI Bouncer -- the added value over pure rule detection is significant in the Fairlane pilot (around 15 percent additional detection rate without false-positive increase).
When CrowdSec does not fit
Three cases where CrowdSec is not the right choice.
First: a pure static marketing site without login and without API behind Cloudflare. Cloudflare WAF already covers the attack patterns; an additional CrowdSec layer adds little value. UFW plus Cloudflare WAF is enough; CrowdSec would be overkill.
Second: mini VPS below 512 MB RAM or single-core with less than 0.5 vCPU. CrowdSec needs around 200 MB RAM and half a CPU core for a productive configuration with AI Bouncer. On a 512 MB VPS that is noticeable; for such micro setups Fail2ban remains the right choice.
Third: strict compliance with a prohibition on cloud API calls outside Switzerland. CrowdSec Community Edition sends anonymised telemetry (IP hash plus scenario name) to the Console in France. Anyone forbidden to allow this (FINMA high-risk mandates, certain law-firm constellations) can run CrowdSec in offline mode -- but loses the key crowd advantage and lies functionally at Fail2ban level.
General pitfalls we have seen with clients: (a) building scenarios so aggressive that they produce false positives -- the own health check trips a brute-force rule and the load balancer gets banned. (b) Activating a bouncer without protecting admin access via whitelist -- you lock yourself out as soon as your office VPN is rated as a Tor exit node match. (c) Activating AI Bouncer with direct block action instead of observe mode -- one to two weeks of observe mode with tagging instead of block is mandatory to calibrate false positives.
Trade-offs
STRENGTHS
- MIT license, fully commercially usable without license risk
- Collaborative blocklist with 4-6 million active IPs from 100k+ nodes
- AI Bouncer (Q1 2026) catches behavioural attacks below rule thresholds
- Clean separation of agent and bouncer, multiple bouncers in parallel possible
WEAKNESSES
- Hardware need around 200 MB RAM plus 0.5 vCPU, noticeable on minimal VPS
- Community Edition sends anonymised telemetry -- offline mode reduces value
- False positives possible with aggressive scenarios or without careful whitelist
- Console account hosted in France -- check offline mode for FINMA high-risk
FAQ
CrowdSec or Fail2ban -- what is the right choice in 2026?
For new installations in 2026 always CrowdSec. The collaborative blocklist with 2 million active IPs blocks attacks Fail2ban never sees. Fail2ban remains valid for minimalist single-service setups or as fallback under strict offline duty. Migration path: disable Fail2ban, set up CrowdSec with the same acquis sources, observe in parallel for 7 days, then remove Fail2ban.
What does CrowdSec send to the Console -- FADP-compliant?
Community Edition sends only hashes of attacker IPs plus scenario names. No client data, no plain-text logs, no own server IPs. Retention in the Console account is 7 days. CrowdSec is a French SAS subject to GDPR. Acceptable for Swiss SMEs; for FINMA high-risk or certain professional-secrecy constellations check offline mode.
How does the Q1 2026 AI Bouncer work?
A light ML model runs locally on the agent and analyses behavioural patterns: request rate, path sequences, user-agent drift, header anomalies. It catches attackers below classic scenario thresholds. Free in Community Edition, model runs locally (no inference API call). In Fairlane pilot: 15 percent additional detection rate without significant false-positive increase.
How long are attacker IPs banned?
Default for SSH and HTTP brute force: 4 hours. Crowd blocklist: 24 hours to 7 days depending on reputation. Persistent ban on severe incidents via custom scenario settable to 30 days or permanent. Values configurable in YAML. Manual unblock via cscli decisions delete --ip <ip> possible at any time.