CrowdSec 1.6 & nftables 2026: Byt fail2b…

Q: Vad är CrowdSec i korthet?

CrowdSec är ett open source IDS/IPS-verktyg som analyserar loggar lokalt, blockerar attackerande IP-adresser via bouncers och delar signaler med ett globalt community för att skapa en gemensam blocklista. Det ses som en modernare, distribuerad efterföljare till fail2ban.

Q: Hur skiljer sig CrowdSec från fail2ban?

Fail2ban är en monolit som ser bara sina egna attacker och skriver linjära brandväggsregler. CrowdSec separerar detektering från blockering, använder O(1)-uppslag i nftables-set, korrelerar över flera händelser med expr-språket och delar hotdata med ett community på ~1,3 miljoner aktiva IP:er.

Q: Är CrowdSec gratis?

Ja, agenten, LAPI och bouncers är open source under MIT-licens. CrowdSec Console har en gratis nivå för upp till tre maskiner och 30 dagars historik. Premium-blocklistor och större flottor kräver betald plan från €29/månad.

Q: Kan CrowdSec integreras med nftables?

Ja. Paketet crowdsec-firewall-bouncer-nftables skapar ett dedikerat inet crowdsec -table med ett ipv4_addr -set med timeout. Uppslagen är O(1) och kan hantera hundratusentals bannade IP:er utan mätbar prestandapåverkan.

Q: Fungerar CrowdSec på RHEL 10 och Rocky Linux 10?

Ja. CrowdSec distribuerar officiella RPM-paket via sitt eget YUM-repo som stöder RHEL 8/9/10, Rocky, AlmaLinux och Fedora 38+. På RHEL 10 rekommenderas nftables-bouncern (iptables-legacy är deprecated).

Uppdaterad: 8 september 2026

CrowdSec är ett open source-verktyg för intrångsdetektering och blockering (IDS/IPS) som analyserar loggar lokalt, delar signalerna till ett globalt community och distribuerar blocklistor tillbaka till alla anslutna noder. Det gör det till en modernare ersättare för fail2ban på Linux 2026. Där fail2ban ser en attack per server, ser CrowdSec 1.6 attackerna som drabbar tusentals servrar samtidigt. Den här guiden visar hur du installerar CrowdSec på Debian 12 och Ubuntu 24.04, kopplar in en nftables-bouncer, integrerar med SIEM och trimmar scenarier för att minimera falska positiva.

CrowdSec 1.6 (stabil sedan 2024, senaste 1.6.11 släpptes juli 2026) separerar detektering (agent) från blockering (bouncers) via ett lokalt REST-API (LAPI).
Community-blocklistan innehåller runt 1,3 miljoner aktiva IP-adresser klassificerade som ondskefulla, och du konsumerar den gratis efter registrering på CrowdSec Console.
Standardinstallationen skyddar SSH, HTTP och exponerade paneler ur lådan. Scenarier och parsers hämtas från Hub som versionerade YAML-paket.
Nftables-bouncern kan lägga in beslut som en atomär set med timeout, långt effektivare än fail2bans iptables -I per IP.
CrowdSec Agent kan strömma händelser till Elasticsearch, Splunk eller Loki i JSON, vilket passar in i befintlig SIEM-pipeline utan verktygsbyte.
Migrera stegvis: kör fail2ban och CrowdSec parallellt i två veckor, jämför beslut, avaktivera sedan fail2ban-jails ett i taget.

Vad är CrowdSec och hur skiljer det sig från fail2ban?

CrowdSec är en agent skriven i Go som läser loggar (via tail, journald eller Windows Event Log), matchar dem mot deklarativa YAML-scenarier och skickar beslut till en lokal SQLite- eller PostgreSQL-databas. En separat process, en bouncer, hämtar besluten och verkställer dem i brandväggen, webbservern, applikationen eller molntjänsten. Modellen skiljer sig från fail2ban på tre viktiga sätt.

För det första: fail2ban är en monolit där både detektering och blockering körs i samma Python-process. En krasch tar ner båda delarna. CrowdSec delar upp ansvaret så att agenten kan startas om utan att blockerings-set nollställs, och en misskonfigurerad bouncer stör inte detekteringen. För det andra: fail2ban letar med regex mot enskilda loggrader. CrowdSec parsear först loggen till strukturerad data (med grok-liknande mönster) och kör sedan uttrycksspråket expr för att korrelera flera händelser över tid, per IP, per URI eller per user-agent.

För det tredje: fail2ban är helt isolerat. Varje server ser bara sina egna attacker. CrowdSec-agenten kan opt-in dela anonymiserade signaler till Central API, och konsumera community-blocklistan tillbaka. En IP som scannat 20 andra WordPress-installationer den senaste timmen blir blockerad hos dig innan den ens knackar på port 22. Community-effekten är den tydligaste anledningen till migrering på 2026-produktionssystem, särskilt för mindre team utan dedikerad SOC.

Ärligt talat: det var just den detaljen som fick mig att byta. På ett projekt förra året körde vi fail2ban på tolv edge-noder och såg identiska brute-force-mönster dyka upp på nod efter nod, med några timmars fördröjning. När vi rullade CrowdSec i simuleringsläge fångade den 30 % fler unika angripare första veckan, enbart tack vare CAPI-listan.

CrowdSec-arkitekturen: agent, LAPI och bouncers

Installationen består av tre komponenter som alla lever i separata paket. Agenten (crowdsec) läser loggar, kör parsers och scenarier och skriver beslut. LAPI (Local API) är ett REST-API som exponeras på 127.0.0.1:8080 som standard. Det talar HTTP+JSON och skyddas av API-nycklar. Bouncers är fristående binärer eller plugin som pollar LAPI var 10:e sekund (justerbart) och verkställer besluten i sitt eget lager.

Följande tabell jämför de vanligaste bouncerna som är stabila i 2026:

Bouncer	Blockeringslager	Best fit	Prestanda
cs-firewall-bouncer (nftables)	Kernel netfilter	Generell edge, ~alla protokoll	Miljontals paket/sek, O(1) uppslag
cs-firewall-bouncer (iptables)	Kernel netfilter (legacy)	Äldre RHEL/CentOS-servrar	Linjär, degraderar över 5k regler
cs-nginx-bouncer	Nginx via Lua/openresty	Reverse proxies, WAF	<1 ms per request
cs-cloudflare-bouncer	Cloudflare Firewall Rules API	Edge-blockering före ursprung	API-latens, batchar 1k IP
cs-appsec (WAF)	Applikationslager (HTTP body)	Regel-baserad WAF, Coraza-motor	~2 ms per request

Att separera detektering från verkställande är också det som gör multi-server-topologier möjliga. Du kan köra en central LAPI-nod och peka alla agenter (t.ex. tio webbservrar) mot den. Då korreleras händelserna över hela flottan och besluten distribueras till alla bouncers. På en enskild server kör LAPI och agent i samma crowdsec.service, medan bouncern körs i sin egen enhet så att den kan startas om utan att tappa detekteringen. För en grundlig genomgång av arkitekturen, se CrowdSec-dokumentationens architecture-avsnitt.

Så installerar du CrowdSec på Ubuntu 24.04 och Debian 12

CrowdSec distribuerar egna APT- och YUM-repositorier som uppdateras snabbare än distributionens paket. På Ubuntu 24.04 och Debian 12 räcker det med tre kommandon för en färdig grundinstallation som skyddar SSH och nginx omedelbart.

# Lägg till CrowdSec-repot (verifierar signatur med hkp-nyckel)
curl -s https://install.crowdsec.net | sudo sh

# Installera agenten + LAPI
sudo apt install crowdsec

# Installera nftables-bouncer
sudo apt install crowdsec-firewall-bouncer-nftables

# Verifiera status
sudo cscli metrics
sudo systemctl status crowdsec crowdsec-firewall-bouncer

Installations-skriptet identifierar automatiskt vilka tjänster som körs (sshd, nginx, apache, mariadb och så vidare) och registrerar deras loggfiler i /etc/crowdsec/acquis.yaml. Ett typiskt utdrag ser ut så här:

---
filenames:
  - /var/log/auth.log
labels:
  type: syslog
---
filenames:
  - /var/log/nginx/access.log
  - /var/log/nginx/error.log
labels:
  type: nginx

type-etiketten avgör vilken parser som körs på loggen. Om du kör tjänster med icke-standardformat (t.ex. Traefik med JSON-loggning) lägger du till en egen sektion. På system med journald läses systemenheter direkt utan filsökväg:

source: journalctl
journalctl_filter:
 - "_SYSTEMD_UNIT=ssh.service"
labels:
  type: syslog

Scenarier och parsers: hämta paket från Hub

Där fail2ban har jails skrivna i INI-filer använder CrowdSec versionerade YAML-paket från CrowdSec Hub. Ett scenario är en signatur som beskriver ett angreppsmönster, till exempel "10 misslyckade SSH-inloggningar från samma IP inom 10 minuter" eller "ny WordPress-user-agent + login-brute". Parsers är regex- och grok-mönster som förvandlar råloggrader till strukturerade fält.

Hämta och lista installerade paket:

# Uppdatera Hub-indexet
sudo cscli hub update

# Uppgradera alla installerade paket
sudo cscli hub upgrade

# Lista scenarier och deras status
sudo cscli scenarios list

# Installera ytterligare skydd (exempel: WordPress-brute-force)
sudo cscli scenarios install crowdsecurity/wordpress-bf
sudo cscli collections install crowdsecurity/wordpress

En collection är ett metapaket som drar in ihopkopplade parsers, scenarier och postoverflows. crowdsecurity/linux installeras alltid som grund och innehåller SSH, sudo-missbruk och grundläggande systemhändelser. För webbservrar lägger du till crowdsecurity/nginx eller crowdsecurity/apache2. Fullständig lista finns i Hub-katalogen, där paketen sorteras efter typ och kompatibla loggkällor.

Efter varje ändring krävs en agent-omstart för att ladda scenarier: sudo systemctl reload crowdsec. Reload triggar en re-parse av acquis.yaml och en Hub-integritetsverifiering, så signaturer valideras mot Hubbens ed25519-nyckel och ett komprometterat mirror kan inte skjuta in falska scenarier.

Nftables-bouncer: blockera IP-adresser atomiskt

Fail2bans stora prestandanackdel är att den bygger brandväggsregler linjärt. Varje bannad IP blir en egen iptables -I INPUT -s x.x.x.x -j REJECT. Vid 5 000 aktiva beslut måste kärnan iterera igenom hela kedjan för varje inkommande paket. CrowdSecs nftables-bouncer använder istället ett set med typen ipv4_addr och timeout, och uppslag är O(1) och kan hantera hundratusentals IP:er utan mätbar overhead.

Konfigurationen bor i /etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml och ser typiskt ut så här:

mode: nftables
update_frequency: 10s
log_mode: file
log_dir: /var/log/
log_level: info
api_url: http://127.0.0.1:8080/
api_key: ${CS_API_KEY}

# Nftables-specifika inställningar
nftables:
  ipv4:
    enabled: true
    set-only: false
    table: crowdsec
    chain: crowdsec-chain
    priority: -10
  ipv6:
    enabled: true
    set-only: false
    table: crowdsec6
    chain: crowdsec6-chain

deny_action: DROP
deny_log: false

Efter start skapar bouncern följande nftables-struktur som du kan inspektera med sudo nft list ruleset:

table inet crowdsec {
    set crowdsec-blacklists {
        type ipv4_addr
        flags timeout
        elements = { 45.155.205.233 timeout 3h50m }
    }
    chain crowdsec-chain {
        type filter hook input priority -10; policy accept;
        ip saddr @crowdsec-blacklists drop
    }
}

Notera prioriteten -10: kedjan körs före din vanliga inputfilter-kedja så att beslut verkställs utan att kollidera med existerande nftables-policies. Vill du köra CrowdSec bredvid en manuellt hanterad ruleset (vanligt vid migration) sätt set-only: true så skapar bouncern bara set:et, och du refererar till det själv från din primära brandväggsregel. Se vår guide till nftables på Linux 2026 för mönster som integrerar externa set på ett hållbart sätt.

Community-blocklistor och CrowdSec Console

Registrera din agent på gratis-nivån av CrowdSec Console för att aktivera community-blocklistan. Registreringen är enkelriktad. Du delar aggregerade signaler (IP + attackstyp + tidsstämpel) men aldrig loggrader eller privata data. I gengäld får du access till en löpande uppdaterad lista på ~1,3 miljoner IP-adresser som setts angripa andra CrowdSec-noder de senaste 24 timmarna.

# Registrera agenten mot Central API
sudo cscli console enroll ${ENROLL_KEY}

# Prenumerera på community-blocklistan
sudo cscli decisions list --origin CAPI | head -20

# Aktivera premium-blocklistor (t.ex. Firehol Level 1)
sudo cscli blocklists list
sudo cscli blocklists add crowdsecurity/http-cve

Console-vyn visar realtidsdashboards med geo-heatmaps, top-scenarier och per-bouncer-statistik. För flerservers-flottor pekar du varje agent mot samma Console-organisation och får en aggregerad översikt. Kostnadsfri nivå tillåter upp till tre maskiner och 30 dagars loghistorik; betalda planer startar från €29/månad för större flottor.

En vanlig fråga är om community-blocklistan riskerar falska positiva. Svaret är: mycket få. En IP hamnar på listan först efter att flera oberoende agenter har rapporterat samma typ av attack (konsensus-tröskel plus reputationsvikt). CrowdSec publicerar sin metodik på GitHub och alla algoritmer är öppna. Om du ändå ser en legitim IP på listan (t.ex. delad hostingpool) kan du whitelista den lokalt utan att påverka det globala beslutet.

Integrera CrowdSec med SIEM (Elasticsearch, Loki, Splunk)

CrowdSec loggar alla beslut och alerts i JSON till /var/log/crowdsec.log och /var/log/crowdsec_api.log. Alerts har följande struktur, vilket är perfekt för indexering i Elasticsearch, Loki eller Splunk:

{
  "@timestamp": "2026-09-08T09:14:22Z",
  "scenario": "crowdsecurity/ssh-bf",
  "source_ip": "185.220.101.42",
  "source_country": "DE",
  "source_as_number": 43350,
  "events_count": 6,
  "leakspeed": "10s",
  "capacity": 5,
  "decisions": [{"type":"ban","duration":"4h"}]
}

För Elasticsearch använder du Filebeat eller Vector med en JSON-parser. En minimal Vector-konfiguration:

[sources.crowdsec]
type = "file"
include = ["/var/log/crowdsec.log"]

[transforms.crowdsec_parse]
type = "remap"
inputs = ["crowdsec"]
source = '. = parse_json!(.message)'

[sinks.elastic]
type = "elasticsearch"
inputs = ["crowdsec_parse"]
endpoints = ["https://siem.internal:9200"]
mode = "bulk"
bulk.index = "crowdsec-%Y.%m.%d"

Alternativt exponerar CrowdSec en Prometheus-endpoint på http://127.0.0.1:6060/metrics, vilket är perfekt för Grafana-dashboards som visar beslut per scenario, top-source-countries och parser-genomströmning. Vår artikel om auditd och SIEM-integration går igenom mönster som fungerar identiskt för CrowdSecs alert-ström.

Så migrerar du från fail2ban utan att tappa täckning

En stabil migration tar cirka två veckor och sker i fyra faser. Undvik att stänga av fail2ban innan CrowdSec har verifierats i observationsläge. Jag hade otur på en migration där vi hoppade över steg två och slog av fail2ban för tidigt, och missade en Nagios-blip som CrowdSec-parsern inte hade kalibrerats för. Nu kör jag alltid parallellt hela vägen.

Vecka 1, dag 1–3: Installera CrowdSec parallellt med fail2ban. Sätt bouncern i simulation: true-läge, så loggar den beslut men verkställer inget. Fail2ban fortsätter blockera som vanligt.
Vecka 1, dag 4–7: Jämför besluten. Kör cscli alerts list mot fail2ban-client status sshd. CrowdSec bör se ≥95 % av fail2bans träffar plus en del utöver (community + fler scenarier).
Vecka 2, dag 8–11: Vitlista servertjänsternas egna IP-block (monitorings-noder, kontor-VPN) i /etc/crowdsec/parsers/s02-enrich/whitelists.yaml. Sätt bouncern i simulation: false, och CrowdSec verkställer nu parallellt med fail2ban.
Vecka 2, dag 12–14: Avaktivera fail2ban-jails en i taget (fail2ban-client stop sshd). Övervaka SSH-loggen i 24 timmar mellan varje jail. När sista jailen är av: sudo systemctl disable --now fail2ban.

Under hela migrationsperioden bör du köra cscli metrics dagligen. Den visar hur många rader varje parser läst, hur många alerts som triggats och om bouncern hunnit synka. Om parsed är noll för en logg är parsern felkonfigurerad. Vanligast är fel type-label, eller att journald-filtret inte matchar unitnamnet.

Trimma bort falska positiva med whitelists

Falska positiva uppstår oftast från övervakningssystem som Nagios, Zabbix eller Prometheus blackbox-exporter som gör upprepade probes. CrowdSec whitelistar via YAML-filer i /etc/crowdsec/parsers/s02-enrich/. En minimal fil för att skydda internt monitoringnät:

name: crowdsecurity/whitelists
description: "Whitelist events from internal monitoring"
whitelist:
  reason: "internal monitoring subnets"
  ip:
    - "10.20.30.10"
    - "10.20.30.11"
  cidr:
    - "192.168.100.0/24"
  expression:
    - evt.Meta.source_ip in ['1.2.3.4', '5.6.7.8']
    - evt.Parsed.request contains '/health'

Expression-fältet använder samma expr-språk som scenarierna, så du kan whitelista på godtyckliga villkor: user-agent, HTTP-status, cookie-innehåll eller till och med tid på dygnet. Efter ändring: sudo systemctl reload crowdsec.

Om en IP redan blivit blockerad tar du bort beslutet med cscli decisions delete --ip x.x.x.x. Vill du permanentbanna en IP oavsett scenarier: cscli decisions add --ip x.x.x.x --duration 8760h --reason "manual ban". Alla manuella beslut visas separat från automatiska i Console-dashboarden så att auditspår hålls rent. För djupare runtime-observation på nätverkslager, se vår guide till eBPF-baserad runtime-säkerhet med Falco och Tetragon. Den är en bra komplementär detektor för anomalier som inte lämnar logspår.

Vanliga frågor

Vad är CrowdSec i korthet?