CrowdSec pe Linux în 2026: IPS Comunitar și Alternativă Modernă la Fail2ban

CrowdSec e un IPS open-source pentru Linux care combină detecție locală cu blocklist-uri comunitare. Ghid de instalare, integrare cu nftables, nginx, Cloudflare și comparație cu Fail2ban în 2026.

CrowdSec pe Linux 2026: Ghid IPS și Fail2ban

Actualizat: 12 septembrie 2026

CrowdSec este un motor open-source de detectare și prevenire a intruziunilor (IPS) pentru Linux, care analizează jurnalele locale, decide când o adresă IP se poartă ostil și partajează verdictele cu o rețea globală de instanțe pentru a crea liste comune de blocare. Practic, e un Fail2ban modern scris în Go, cu inteligență de amenințări colaborativă și cu o decuplare clară între detecție și blocare. În 2026, versiunea stabilă este seria 1.6, iar componenta AppSec aduce un WAF real în același agent. Ghidul de față arată cum îl instalezi, cum îl legi de nftables, nginx și Cloudflare și când are sens să înlocuiești Fail2ban cu el.

  • CrowdSec 1.6 separă detecția (agentul) de remedierea (bouncerii), spre deosebire de Fail2ban, care le combină într-un singur proces.
  • Componenta AppSec, introdusă stabilă la sfârșitul lui 2024 și extinsă în 2025 și 2026, permite rularea unui WAF cu reguli tip Coraza sau ModSecurity direct în agent.
  • Blocklist-ul comunitar (CTI) livrează aproximativ 1 milion de IP-uri active zilnic; consumul lui gratuit se face prin bouncer, după autentificarea agentului la Central API.
  • Scenariile și parserii se instalează din hub cu cscli collections install, iar deciziile pot fi trimise nativ către nftables, iptables, HAProxy, Traefik, nginx și Cloudflare.
  • Modelul de amenințare acoperă atacurile de tip brute-force, scanarea, exploit-urile web și abuzul de credențiale; nu înlocuiește un HIDS complet precum Wazuh, ci îl completează.

Ce este CrowdSec și cum funcționează?

CrowdSec e alcătuit din trei piese care rulează independent: agentul (numit intern crowdsec), Local API (LAPI) și bouncerele. Agentul citește surse de jurnale (fișiere text, journalctl, syslog, docker sau kafka), le trece printr-un lanț de parseri pentru a extrage câmpuri normalizate și le evaluează în raport cu scenariile (reguli scrise în YAML peste un DSL propriu, expr). Când un scenariu se declanșează, agentul creează o alertă și o decizie (de obicei ban pentru N ore), pe care le stochează în LAPI.

Bouncerele sunt procese separate care rulează lângă nginx, Traefik, nftables sau la marginea rețelei. Ele interoghează LAPI la fiecare câteva secunde și aplică decizia (drop pachete, 403, captcha, redirect). Simplu ca principiu, dar diferența față de Fail2ban se vede la primele incidente reale.

Separarea aceasta e intenționată și rezolvă o slăbiciune structurală a Fail2ban: dacă parserul se blochează, blocarea rămâne activă; dacă bouncerul cade, deciziile există în continuare și pot fi replayate. Agentul se autentifică opțional la Central API (CAPI) de la crowdsec.net și primește în schimb un flux de IP-uri raportate de întreaga comunitate. De aceea instalările noi capătă protecție împotriva scanerilor cunoscuți în minute, nu în zile. Honestly, prima dată când am pornit un agent pe un VPS „gol”, aveam deja peste 300 de IP-uri banate în prima jumătate de oră, fără să fi primit trafic legitim, doar din blocklist-ul comunitar.

CrowdSec vs Fail2ban: comparație directă

Întrebarea „merită să migrez de la Fail2ban?” apare des în forumuri, iar răspunsul depinde de raza de acțiune. Fail2ban rămâne excelent pentru sisteme minimale, cu un singur serviciu de protejat (SSH pe un bastion, de exemplu). CrowdSec câștigă atunci când ai mai multe surse de log, servicii HTTP expuse public sau flote de servere unde vrei să partajezi deciziile. Tabelul de mai jos rezumă diferențele care contează în producție în 2026:

DimensiuneCrowdSec 1.6Fail2ban 1.1
Limbaj și performanțăGo, single-binary, ~40 MB RAMPython cu subprocese, ~80 pâna la 150 MB RAM
Model arhitecturalDetecție separată de remediere (LAPI plus bouncere)Monolitic (parser și acțiune în același proces)
Inteligență comunitarăDa, blocklist CAPI gratuit (~1M IP-uri)Nu, doar detecție locală
Suport HTTP/WAF nativDa, prin AppSec ComponentNu, doar log-parsing
Integrărinftables, iptables, nginx, Traefik, HAProxy, Cloudflare, AWS WAF, Crowdsec Blocklist Mirroriptables, nftables, firewalld, mail
Curbă de învățareMedie (YAML, expr DSL, hub)Redusă (jail-uri, filter regex)
Console web / metriciDa, gratuit până la 3 instanțe; Prometheus nativNu, doar CLI și log
LicențăMIT plus componente comerciale opționaleGPL-2

Pe scurt: dacă ai deja o infrastructură Fail2ban ajustată pentru protecția împotriva atacurilor brute force pe SSH, nu o smulge doar de dragul modei. Poți rula CrowdSec în paralel, lăsând Fail2ban pe SSHD și CrowdSec pe web sau API. Ajung să convieșească fără conflict, pentru că lucrează pe log-uri diferite și scriu în lanțuri de firewall diferite. Voi arăta pattern-ul mai jos.

Cum instalez CrowdSec pe Linux în 2026?

CrowdSec livrează pachete oficiale pentru Debian/Ubuntu, RHEL/Rocky/Alma, openSUSE și Alpine, plus binare statice. În 2026, versiunea recomandată pentru producție este 1.6.x. Pentru un server proaspăt Debian 12 sau Ubuntu 24.04 LTS, pașii de bază sunt:

# 1. Adaugă repository-ul oficial
curl -s https://install.crowdsec.net | sudo sh

# 2. Instalează agentul (LAPI e inclus by default)
sudo apt update
sudo apt install -y crowdsec

# 3. Verifică versiunea și starea
cscli version
sudo systemctl status crowdsec --no-pager

# 4. Înregistrează instanța la Central API pentru blocklist-ul comunitar
sudo cscli capi register
sudo systemctl restart crowdsec

Pentru RHEL/Rocky/Alma 9, secvența e identică, cu dnf install crowdsec. Instalatorul detectează automat serviciile deja prezente (SSH, nginx, apache, postfix) și îți propune colecții relevante; poți accepta implicitul sau alege manual mai târziu prin cscli.

După instalare, verifică că agentul citește sursele corecte:

sudo cscli metrics
sudo cscli hub list
sudo cscli collections list

Prima comandă îți arată câte linii pe secundă intră în fiecare parser și câte alerte s-au generat. Dacă valoarea de la Acquisition Metrics pentru sshd rămâne zero timp de câteva minute sub trafic real, e semn că sursa de log nu e citită corect. Cauza cea mai frecventă e rotația fișierului sau un pattern greșit în /etc/crowdsec/acquis.yaml. (Am pierdut o dimineață întreagă pe un cluster nou pentru un simplu *.log care nu prindea syslog.1.)

Configurarea bouncerelor și blocarea IP-urilor

Agentul singur nu blochează nimic; el doar scrie decizii în LAPI. Ca să vezi efecte în firewall, ai nevoie de un bouncer. Cel mai comun pe Linux este crowdsec-firewall-bouncer, care poate opera peste nftables (default pe Debian 12+ și RHEL 9+) sau iptables clasic. Instalarea:

# Instalare bouncer pentru nftables
sudo apt install -y crowdsec-firewall-bouncer-nftables

# Verifică că bouncerul e înregistrat la LAPI
sudo cscli bouncers list

# Ban manual, ca test rapid
sudo cscli decisions add --ip 203.0.113.42 --duration 4h --reason "test manual"
sudo nft list set inet crowdsec crowdsec-blacklists

În câteva secunde, IP-ul apare în setul crowdsec-blacklists și traficul de pe el e dropat. Pentru infrastructuri cu firewall nftables configurat pentru securizare completă, bouncerul creează propriul tabel inet crowdsec, cu un set IPv4 și un set IPv6, populate dinamic din LAPI. Dacă rulezi deja un firewall stateful, verifică ordinea: setul CrowdSec trebuie evaluat înaintea regulilor de accept, altfel decizia nu are efect.

Pentru servicii HTTP, bouncerul de nginx e diferit: el nu scrie în firewall, ci decide la nivel de request, servind 403 sau captcha. Instalare tipică:

sudo apt install -y crowdsec-nginx-bouncer

# Verifică configul generat
sudo cat /etc/crowdsec/bouncers/crowdsec-nginx-bouncer.conf | head

# Reîncarcă nginx și testează
sudo nginx -t && sudo systemctl reload nginx

Bouncerul nginx e implementat ca un modul Lua (via OpenResty sau nginx-plus-lua) și rulează în worker. Suportă modul stream (blocare TCP) și modul live (interogare LAPI la fiecare request), cu cache local pentru IP-urile deja evaluate. Pentru Cloudflare, bouncerul propriu cs-cloudflare-bouncer publică deciziile ca reguli WAF în tenant-ul tău Cloudflare. E util când vrei blocare la marginea rețelei, înainte ca traficul să atingă originea.

Scenarii, parseri și colecții din CrowdSec Hub

Inteligența agentului stă în hub, un repository comunitar de parseri, scenarii și colecții, curat de echipa CrowdSec și de contributori externi. O colecție e un pachet care leagă un parser (extrage IP-ul și evenimentul din log-ul brut) cu unul sau mai multe scenarii (definesc când se declanșează alerta). Cele mai instalate colecții în 2026 sunt crowdsecurity/sshd, crowdsecurity/nginx, crowdsecurity/http-cve, crowdsecurity/base-http-scenarios și crowdsecurity/appsec-virtual-patching. Le instalezi și le actualizezi cu:

sudo cscli collections install crowdsecurity/nginx
sudo cscli collections install crowdsecurity/http-cve
sudo cscli hub upgrade
sudo systemctl reload crowdsec

Scenariile folosesc un DSL bazat pe expr (proiectul expr-lang/expr) și un motor de tip leaky bucket: fiecare eveniment adaugă o picătură într-o găleată, iar depășirea capacității declanșează alerta. Un scenariu tipic anti-brute-force SSH arată așa:

type: leaky
name: crowdsecurity/ssh-bf
description: "Detect ssh bruteforce"
filter: "evt.Meta.log_type == 'ssh_failed-auth'"
leakspeed: "10s"
capacity: 5
groupby: "evt.Meta.source_ip"
blackhole: 1m
labels:
  service: ssh
  type: bruteforce
  remediation: true

Se traduce astfel: „acordă o toleranță de 5 eșecuri de autentificare per IP; dacă un nou eșec apare mai des decât o dată la 10 secunde, umple găleata și declanșează ban”. Poți scrie scenarii proprii pentru API-urile tale (de exemplu, o rută /login care primește mai mult de 20 de POST-uri/min de la același IP). Deciziile locale rămân locale; dacă vrei să le împărtășești, activezi „Sharing Signals” în config și ele merg către CAPI.

AppSec Component: WAF integrat cu CrowdSec

Componenta AppSec a fost adăugată stabilă la finalul lui 2024 și, în 2026, e alegerea implicită pentru echipele care vor un WAF fără complexitatea unui ModSecurity separat. AppSec rulează în același proces cu agentul CrowdSec și expune un endpoint HTTP la care reverse-proxy-urile (nginx, Traefik, HAProxy) trimit requestul înainte de a-l servi. Motorul de reguli e un port de Coraza WAF, compatibil cu setul de reguli OWASP Core Rule Set (CRS) versiunea 4.x, plus reguli proprii CrowdSec pentru CVE-uri active (virtual patching).

Configurarea minimă cere trei fișiere: un AppSec Config (definește portul, timeout-urile, blocarea implicită), un AppSec Rule Set (regulile aplicate) și un Acquisition care leagă componenta de agent. Exemplu simplificat:

# /etc/crowdsec/acquis.d/appsec.yaml
appsec_config: crowdsecurity/appsec-default
labels:
  type: appsec
listen_addr: 127.0.0.1:7422
source: appsec
name: crowdsec-appsec

În nginx, redirecționezi cererea către AppSec cu un modul auth_request sau cu ajutorul bouncerului OpenResty. Latența adăugată e de aproximativ 1 până la 3 ms per request pentru un set CRS standard, ceea ce e acceptabil pentru majoritatea API-urilor. Diferența majoră față de un WAF clasic e că AppSec primește și deciziile comunitare, așa că un IP raportat de altă instanță pentru abuz web e blocat înainte ca regulile CRS să fie evaluate.

Monitorizare, metrici și integrare Prometheus

Un IPS pe care nu-l poți observa e la fel de folositor ca o alarmă fără difuzor. CrowdSec expune metrici Prometheus pe http://127.0.0.1:6060/metrics pentru agent și pentru fiecare bouncer separat. Metricele importante sunt cs_parser_hits_total (câte log-uri intră în fiecare parser), cs_bucket_overflowed_total (câte scenarii au declanșat) și cs_active_decisions (câte decizii sunt active). Un dashboard Grafana oficial e disponibil în hub-ul CrowdSec și se importă cu ID-ul 15125.

# /etc/prometheus/prometheus.yml — snippet
- job_name: crowdsec
  static_configs:
    - targets: ['crowdsec-host:6060']
- job_name: crowdsec-firewall-bouncer
  static_configs:
    - targets: ['crowdsec-host:60601']

Pentru echipele care rulează deja Wazuh pentru detectarea intruziunilor pe Linux, poți trimite alertele CrowdSec către Wazuh printr-un notification plugin tip HTTP sau file-based. Combinația funcționează bine: CrowdSec dă blocare rapidă pe rețea, Wazuh dă corelare pe termen lung și dovezi pentru audit. Nu se suprapun; se completează.

Consola web gratuită (app.crowdsec.net) îți dă o vedere agregată peste toate instanțele înregistrate, util pentru flote mici. Peste 3 instanțe intri în planul plătit, dar poți rula un Blocklist Mirror local (proiect open-source separat) care oglindește deciziile pentru un număr nelimitat de agenți.

Model de amenințare: ce cedează primul?

Am obiceiul să întreb la fiecare deploy: „ce sparge primul?”. Pentru CrowdSec, punctele de ruptură clasice sunt:

  • LAPI expus fără TLS. Un atacator care ajunge la portul 8080 poate crea decizii, șterge decizii sau înregistra bouncere false. Blast radius: întregul lanț de blocare devine controlabil de atacator. Mitigare: TLS reciproc și firewall pe interfața LAPI.
  • Chei bouncer scurse în git. Cheile de API au drepturi de citire a deciziilor și de heartbeat. Nu dau permisiune de scriere, dar identifică bouncer-ul și îl pot deconecta. Mitigare: cscli bouncers add pentru fiecare host, stocare în secrets manager (Vault, sops-age), rotire trimestrială.
  • Fals-pozitive pe rețele NAT. Un ban pe un IP corporate poate scoate toată clădirea de pe API. Mitigare: allowlists statice pentru range-urile cunoscute (VPN, birou) și decizii cu captcha în loc de ban pe rutele expuse consumerilor.
  • Dependența de CAPI. Dacă CAPI cade, agentul continuă cu deciziile locale, dar nu mai primește blocklist-ul comunitar. Nu e single-point-of-failure pentru site-ul tău, dar e pentru semnalul comunitar. Mitigare: dublează CTI-ul cu o sursă alternativă (Firehol, Spamhaus, listă proprie).
  • Bouncer nginx în modul stream cu cache prea lung. Un utilizator legitim ban-uit rămâne blocat până expiră cache-ul, chiar dacă decizia a fost revocată în LAPI. Mitigare: TTL cache ≤ 30 s și monitorizare pe rata de 403 per X-Forwarded-For.

Pentru echipele care fac și securizare SSH pe Linux cu vulnerabilități și configurare, CrowdSec e un al doilea strat, nu un substitut. Cheile ed25519, dezactivarea autentificării cu parolă, port-knocking sau ProxyJump rămân prima linie. CrowdSec preia atacatorii care totuși ajung la lista de IP-uri publice și le taie propagarea către alte servicii.

Ca diagramă mentală: gândește-te la un inel de senzori (agenții) care șoptesc între ei prin CAPI, un creier central (LAPI) care ia decizia și niște mâini (bouncerele) care execută. Fiecare piesă poate cădea izolat fără să dărâme întreg sistemul. Graceful degradation e proiectată în arhitectură, spre deosebire de Fail2ban, unde o eroare de regex în filtru oprește întreg jail-ul.

Întrebări frecvente

Pot rula CrowdSec și Fail2ban pe același server?

Da, dacă nu se calcă pe log-uri sau pe lanțuri de firewall. Recomand să dedici Fail2ban unui serviciu simplu (ex. SSH) și să lași CrowdSec pentru web, API și inteligența comunitară. Ambele scriu în nftables, dar în tabele diferite dacă folosești tabelul crowdsec generat automat de bouncer.

Este CrowdSec cu adevărat gratuit pentru uz comercial?

Agentul, LAPI, bouncerele și AppSec sunt MIT open-source și pot fi folosite comercial fără taxă. Blocklist-ul comunitar (CTI) este gratuit până la volume rezonabile; abonamentele plătite deblochează liste premium, mai multe instanțe în consolă și suport comercial.

Cât consumă CrowdSec pe un VPS mic?

Pe un VPS de 1 vCPU și 1 GB RAM, agentul cu 3 sau 4 colecții și un firewall-bouncer consumă tipic 40 până la 70 MB RAM și sub 1% CPU în stare de repaus. Sub atac, spike-ul de CPU depinde de rata log-urilor, dar rareori depășește 10% pentru un site web tipic.

Cum văd ce IP-uri sunt blocate de CrowdSec?

Rulează sudo cscli decisions list pentru deciziile active locale sau sudo cscli alerts list pentru istoricul alertelor. Pentru vizualizare grafică, conectează instanța la consola app.crowdsec.net sau importă dashboard-ul Grafana oficial (ID 15125).

Ce fac dacă CrowdSec îmi blochează un utilizator legitim?

Elimină decizia cu sudo cscli decisions delete --ip <IP> și adaugă IP-ul în allowlist-ul static din /etc/crowdsec/parsers/s02-enrich/whitelists.yaml. Pentru range-uri corporate (VPN, birou), configurează whitelist-ul o dată și trimite reload agentului cu sudo systemctl reload crowdsec.

Documentație oficială și referințe: docs.crowdsec.net, note de lansare CrowdSec pe GitHub și colecții din CrowdSec Hub.

Aisha Okonkwo
Despre Autor Aisha Okonkwo

Infrastructure security architect at a hyperscaler. Spends her days on Zero Trust, secrets management, and yelling at unencrypted backups.