CrowdSec op Linux: Moderne Inbraakpreventie met Collaboratieve Bedreigingsintelligentie in 2026

Brute-force aanvallen, credential stuffing en geautomatiseerde scans nemen elk jaar verder toe — en eerlijk gezegd, het wordt er niet rustiger op. Traditionele tools zoals Fail2Ban doen prima werk, maar ze beschermen één server tegelijk en zien nooit het volledige aanvalsbeeld. CrowdSec verandert die aanpak compleet door lokale detectie te combineren met een wereldwijde, collaboratieve threat intelligence-laag. Met andere woorden: zodra één node een aanvaller signaleert, profiteert de hele community.

In deze gids laat ik je zien hoe je CrowdSec in 2026 op productie-Linux servers uitrolt — van installatie en scenario's tot bouncers, nftables-integratie, de Console en wat geavanceerdere tuning. Alle commando's heb ik getest op Debian 12, Ubuntu 24.04 LTS en Rocky Linux 9, met CrowdSec 1.6.x. Laten we erin duiken.

Wat is CrowdSec en waarom zou je het in 2026 kiezen?

CrowdSec is een open-source (en gratis) IPS, oftewel een Intrusion Prevention System, dat verdachte gedragingen detecteert door je logs te parsen. De reactie op die detectie wordt afgehandeld door bouncers: losse processen die acties uitvoeren zoals een IP blokkeren in nftables, een captcha tonen in Nginx, of een 403 sturen vanuit een Cloudflare worker.

De belangrijkste verschillen met klassieke tools zijn:

• Modulair: detectie (de crowdsec agent) staat los van remediatie (de bouncers). Je kunt dus prima op één host detecteren en op een andere blokkeren.
• Collaboratief: bevestigde aanvallers worden naar de Central API gestuurd en — na consensus — in een community blocklist gezet die alle gebruikers kunnen consumeren.
• Schaalbaar: gebouwd in Go, met YAML-scenario's en buckets in plaats van eindeloze regex-loops over logfiles. Het geheugen- en CPU-verbruik ligt aanzienlijk lager dan bij Fail2Ban onder load.
• Multi-source: parsers voor SSH, Nginx, Apache, Traefik, Postfix, Kubernetes audit logs, journald, MySQL, PostgreSQL en nog veel meer via de Hub.

CrowdSec vs Fail2Ban: wanneer kies je wat?

Eigenschap	Fail2Ban	CrowdSec
Architectuur	Monolithisch (Python)	Agent + bouncers (Go)
Threat intel sharing	Nee	Ja (opt-in, Central API)
Configuratie	jail.local + filters	YAML-scenario's, parsers, hub
Geheugen onder load	Hoog (regex per regel)	Laag (event buckets)
Multi-host coördinatie	Handmatig	Native (LAPI/PAPI)
Visualisatie	Geen	Console (cloud) + cscli metrics
Captcha-remediatie	Nee	Ja (web bouncers)

Voor één geïsoleerde VPS zonder web-frontend blijft Fail2Ban prima — geen reden om alles om te gooien als het werkt. Maar voor multi-host omgevingen, reverse proxies of containerclusters is CrowdSec aantoonbaar krachtiger. Ik draai het zelf op een handvol kleine VPS'jes plus een wat groter cluster, en het verschil in zichtbaarheid alleen al was de overstap waard.

CrowdSec installeren op Linux

Debian / Ubuntu

curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install -y crowdsec
sudo systemctl enable --now crowdsec

RHEL / Rocky / AlmaLinux

curl -s https://install.crowdsec.net | sudo sh
sudo dnf install -y crowdsec
sudo systemctl enable --now crowdsec

Verifieer de installatie

sudo cscli version
sudo cscli metrics
sudo systemctl status crowdsec

De agent registreert zichzelf automatisch bij de lokale Local API (LAPI) op 127.0.0.1:8080. Standaard worden /var/log/auth.log, /var/log/syslog en — als ze bestaan — Nginx- en Apache-logs gemonitord. Niets te doen, het werkt gewoon out of the box.

Scenario's en collecties begrijpen

CrowdSec werkt met drie hoofdconcepten in de Hub:

• Parsers: vertalen ruwe logregels naar gestructureerde events.
• Scenario's: beschrijven gedragingen die verdacht zijn (bijvoorbeeld "5 mislukte SSH-pogingen in 60s").
• Collecties: bundels van bovenstaande die je in één commando installeert.

# Bekijk geinstalleerde collecties
sudo cscli collections list

# Voeg Nginx-bescherming toe
sudo cscli collections install crowdsecurity/nginx

# Voeg generieke HTTP CVE-bescherming toe
sudo cscli collections install crowdsecurity/base-http-scenarios

# Voeg Postfix toe als je een mailserver draait
sudo cscli collections install crowdsecurity/postfix

# Herlaad de agent zonder herstart
sudo systemctl reload crowdsec

De eerste bouncer installeren: nftables-blokkering

Een bouncer is wat aanvallers daadwerkelijk tegenhoudt — zonder bouncer detecteer je alleen, en daar koop je weinig voor. De firewall bouncer in nftables-modus is veruit de meest gebruikte op moderne Linux-systemen.

sudo apt install -y crowdsec-firewall-bouncer-nftables

Het pakket configureert zichzelf, registreert een API-key bij de lokale CrowdSec-agent en maakt twee nftables-sets aan: crowdsec-blacklists (IPv4) en crowdsec6-blacklists (IPv6). Vergeet IPv6 dus niet, want dat is in 2026 echt geen exotische edge case meer.

# Verifieer dat de bouncer draait
sudo systemctl status crowdsec-firewall-bouncer

# Bekijk de aangemaakte sets
sudo nft list ruleset | grep -A2 crowdsec

# Toon actieve API-clients
sudo cscli bouncers list

Vanaf nu wordt elk IP dat door een scenario wordt gebanned, binnen enkele seconden in de nftables-set opgenomen en gedropt nog vóór het de service bereikt.

De Community Blocklist activeren

Dit is wat mij persoonlijk het meest enthousiast maakt over CrowdSec: de gratis community blocklist met op dit moment ~75.000 actieve aanvallers, geverifieerd door consensus van duizenden nodes wereldwijd. Bescherming tegen IP's die je nog nooit hebt gezien — voor je server zelfs wist dat ze bestonden.

# Registreer deze instance bij de Central API
sudo cscli capi register

# Inschrijven op de community blocklist
sudo cscli console enroll <jouw-enroll-key>

# Forceer een sync
sudo systemctl reload crowdsec

# Verifieer ontvangen decisions
sudo cscli decisions list --origin lists

De Console (gratis tier) op app.crowdsec.net geeft je daarna real-time inzicht in aanvallen, geografische spreiding, top scenario's en de status van al je bouncers. Eerlijk: de eerste keer dat je dat dashboard opent, is best confronterend.

Aanvallen testen en simuleren

Voer een gecontroleerde test uit om te bevestigen dat detectie en blokkering ook echt werken:

# Simuleer SSH brute-force vanaf een test-IP
for i in {1..10}; do
  ssh -o StrictHostKeyChecking=no -o ConnectTimeout=2 \
      [email protected] 2>/dev/null
done

# Bekijk alerts
sudo cscli alerts list

# Bekijk actieve banlist
sudo cscli decisions list

# Verwijder een test-ban
sudo cscli decisions delete --ip 1.2.3.4

Geavanceerde tuning: whitelists en eigen scenario's

Whitelist je eigen IP-ranges

Stap één — en doe dit nu, niet later: voorkom dat je jezelf buitensluit door beheer-IP's expliciet te whitelisten. Maak /etc/crowdsec/parsers/s02-enrich/whitelists.yaml:

name: crowdsecurity/whitelists
description: "Whitelist beheer-netwerken"
whitelist:
  reason: "vertrouwde beheer-IP's"
  ip:
    - "127.0.0.1"
    - "::1"
  cidr:
    - "10.0.0.0/8"
    - "192.168.0.0/16"
    - "203.0.113.0/24"   # vervang met je VPN/office subnet

sudo systemctl reload crowdsec

Een aangepast scenario schrijven

Stel: je hebt een API-endpoint /api/login dat je wilt beschermen tegen meer dan 10 mislukte requests in 5 minuten. Maak dan /etc/crowdsec/scenarios/api-login-bf.yaml:

type: leaky
name: mijnbedrijf/api-login-bf
description: "Brute-force op /api/login"
filter: "evt.Meta.log_type == 'http_access-log' && evt.Meta.http_path == '/api/login' && evt.Meta.http_status in ['401','403']"
groupby: "evt.Meta.source_ip"
capacity: 10
leakspeed: "60s"
blackhole: 5m
labels:
  service: api
  type: bruteforce
  remediation: true

Test het scenario altijd voordat je herlaadt:

sudo cscli scenarios inspect mijnbedrijf/api-login-bf
sudo systemctl reload crowdsec

CrowdSec integreren met Nginx (captcha-bouncer)

Voor publieke websites is een captcha-bouncer vaak vriendelijker dan een harde blokkade — legitieme gebruikers achter een gedeeld IP (denk aan kantoor- of mobiele NAT) blijven gewoon toegankelijk.

sudo apt install -y crowdsec-nginx-bouncer

# Configureer hCaptcha of reCaptcha keys
sudo nano /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf
# Vul site_key en secret_key in

sudo nginx -t && sudo systemctl reload nginx

De bouncer voegt een Lua-module aan Nginx toe die elke request verifieert tegen de LAPI; verdachte IP's krijgen een captcha, bevestigde aanvallers krijgen gewoon een 403.

Multi-host setup: één LAPI, meerdere agents

In een vlootopstelling laat je één centrale LAPI alle decisions beheren, terwijl agents op edge-nodes alleen detecteren. Dit is waar CrowdSec écht gaat schitteren ten opzichte van Fail2Ban.

Op de centrale LAPI-server

# Bind LAPI op alle interfaces (achter een firewall!)
sudo sed -i 's/listen_uri: 127.0.0.1:8080/listen_uri: 0.0.0.0:8080/' \
  /etc/crowdsec/config.yaml

# Maak een machine-credential voor een remote agent
sudo cscli machines add edge-node-01 --auto

sudo systemctl restart crowdsec

Op elke edge-agent

# Verwijder de lokale LAPI
sudo systemctl disable --now crowdsec  # tijdelijk

# Pas /etc/crowdsec/config.yaml aan:
# api:
#   server:
#     enable: false
#   client:
#     credentials_path: /etc/crowdsec/local_api_credentials.yaml

# Vul credentials in van de centrale LAPI
sudo nano /etc/crowdsec/local_api_credentials.yaml

sudo systemctl enable --now crowdsec
sudo cscli lapi status

Monitoring en metrics

CrowdSec exporteert Prometheus-metrics op :6060/metrics. Een minimale Prometheus-scrape ziet er zo uit:

scrape_configs:
  - job_name: crowdsec
    static_configs:
      - targets: ['10.0.0.5:6060']

Belangrijke metrics om op te alerten:

• cs_bucket_overflowed_total — aantal scenario-overflows (oftewel: bans)
• cs_lapi_decisions_ko_total — gefaalde decision-pushes
• cs_active_decisions — momentane omvang van de banlist
• cs_parser_hits_ko_total — parsing-fouten (vaak een indicator van een configfout)

Troubleshooting checklist

1. Geen alerts ondanks aanvallen? Check eerst sudo cscli metrics — staat de juiste log_type op >0 hits? Zo niet, dan ontbreekt waarschijnlijk een acquisition (zie /etc/crowdsec/acquis.yaml).
2. Bouncer blokkeert niet? Verifieer met sudo cscli bouncers list dat hij verbonden is, en met sudo nft list set inet crowdsec crowdsec-blacklists dat IPs ook echt in de set staan.
3. Te veel false positives? Tune de scenario-capaciteit naar boven, of voeg een whitelist-parser toe voor specifieke User-Agents of paden.
4. Hoog geheugengebruik? Beperk history_size in config.yaml en draai een keer sudo cscli hub upgrade voor de laatste optimalisaties.

Veelgestelde vragen (FAQ)

Wat is het verschil tussen CrowdSec en Fail2Ban?

Fail2Ban is een lokale, monolithische tool die regex-filters op logs toepast. CrowdSec heeft daarentegen een agent/bouncer-architectuur, gebruikt event-buckets in plaats van regex-loops, deelt threat intelligence collaboratief en integreert native met meerdere remediatie-targets (firewall, Nginx, Cloudflare, AWS WAF). Voor multi-host of web-omgevingen is CrowdSec krachtiger; voor één geïsoleerde VPS volstaat Fail2Ban vaak nog prima.

Is CrowdSec gratis?

Ja — en dat is geen marketingtrucje. De agent, alle bouncers, de Hub-content en de Console (Personal-tier) zijn volledig gratis. Betaalde tiers ontgrendelen extra premium blocklists, langere data-retentie en team-features, maar voor de meeste self-hosted setups heb je die echt niet nodig.

Stuurt CrowdSec mijn logs naar de cloud?

Nee. CrowdSec deelt enkel signals: het IP, het scenario en een timestamp van een bevestigde aanval — pas nadat lokale consensus is bereikt en alleen als je cscli capi register hebt uitgevoerd. Logregels en payloads blijven 100% lokaal. De Console-feature is volledig opt-in.

Kan CrowdSec naast Fail2Ban draaien?

Technisch gezien wel, maar het wordt afgeraden (en terecht). Beide tools schrijven naar je firewall en kunnen elkaars regels overschrijven of dubbele bans veroorzaken. Migreer dus in één run: stop fail2ban, installeer CrowdSec met de bijpassende collecties (crowdsecurity/sshd, crowdsecurity/iptables) en de firewall-bouncer.

Werkt CrowdSec in containers en Kubernetes?

Ja. Er is een officiële Docker-image en een Helm-chart voor Kubernetes met aparte agent- en LAPI-deployments. Voor Kubernetes biedt de crowdsecurity/k8s-audit-collectie parsers voor de audit log, en de Ingress-bouncers integreren met Traefik, Nginx-Ingress en HAProxy.

Conclusie

CrowdSec brengt moderne, collaboratieve threat intelligence binnen handbereik van élke Linux-beheerder — zonder licentiekosten en met een duidelijk pad van one-host tot enterprise-fleet. Door agent en bouncer netjes te scheiden krijg je flexibiliteit die Fail2Ban nooit kan bieden, en de community blocklist geeft je vanaf dag één bescherming tegen tienduizenden bekende aanvallers.

Mijn advies? Begin klein. Installeer de agent, voeg de firewall-bouncer en de basis-collecties toe, registreer bij de Console en breid daarna uit met aangepaste scenario's, captcha-bouncers en multi-host coördinatie naarmate je vloot groeit. Binnen een middag heb je iets draaien wat een paar jaar terug nog enterprise-software was.