CrowdSec + Traefik: IDS/IPS pentru aplicații web, fără appliance

Un IDS (Intrusion Detection System) observă traficul și semnalează comportamente ostile; un IPS (Intrusion Prevention System) face un pas în plus și le blochează. Pentru aplicațiile web, asta însemna tradițional un appliance dedicat sau un WAF comercial pus în fața serverelor. Dacă folosești deja un reverse proxy precum Traefik, ai la îndemână tot ce îți trebuie pentru o variantă software, open-source, care rulează lângă aplicații.

CrowdSec este un motor open-source de detecție bazat pe comportament. Citește loguri (de la Traefik, Nginx, SSH, sisteme de operare), le transformă în evenimente prin parsere și le trece prin scenarii — reguli de tip *leaky bucket* care numără evenimentele dintr-o fereastră de timp. Când un bucket se umple (de exemplu, prea multe cereri 404 către căi distincte de la același IP), CrowdSec emite o decizie: ban, captcha sau altă remediere, cu o durată.

Diferența față de un firewall clasic: CrowdSec nu se uită la pachete, ci la ce face clientul în aplicația ta. Asta îl face potrivit pentru scanări de vulnerabilități, brute-force pe formulare de login, crawling agresiv sau exploatarea unor CVE-uri cunoscute.

Ca să înțelegi unde poate merge ceva prost, ajută să separi cele trei roluri:

Fluxul unei cereri devine: client → entrypoint :443 → middleware-ul bouncer → router → aplicație. Bouncer-ul poate rula în modul live (întreabă LAPI la fiecare IP nou, cu cache) sau stream (descarcă periodic toată lista de decizii și decide local). Modul stream are latență mai mică pe cerere, dar o decizie nouă devine activă abia la următorul pull.

1. Activează access log-ul în configurația statică Traefik (accessLog cu filePath) și montează directorul de loguri read-only în containerul CrowdSec.
2. Instalează colecția potrivită: cscli collections install crowdsecurity/traefik aduce parserul și scenariile HTTP de bază. Adaugă colecții pentru CVE-uri web dacă expui aplicații populare.
3. Declară sursa în fișierul de achiziție (acquis.yaml): calea fișierului și eticheta type: traefik, ca logurile să ajungă la parserul corect.
4. Generează o cheie pentru bouncer: cscli bouncers add traefik-bouncer. Cheia apare o singură dată — păstreaz-o într-un secret, nu în cod.
5. Declară pluginul în configurația statică Traefik (secțiunea de plugin-uri) și creează în configurația dinamică un middleware care primește adresa LAPI, cheia și modul (live sau stream).
6. Atașează middleware-ul pe entrypoint-ul websecure sau pe fiecare router. Pe entrypoint e mai greu să uiți un site nou.
7. Verifică cap-coadă: adaugă o decizie de test pentru IP-ul tău (cscli decisions add --ip X.X.X.X --duration 5m), confirmă că primești 403, apoi șterge-o.

Scenariile din hub acoperă tiparele comune: sondarea căilor sensibile (/.env, /.git/config, wp-config.php), scanarea WordPress, brute-force pe login, crawling agresiv al paginilor non-statice, exploatări cunoscute pentru CVE-uri populare. Pentru atacuri de tip flood la nivel 7 există colecții separate, care merită activate abia după ce le-ai testat pe traficul tău real.

Un scenariu propriu e un fișier YAML cu un filtru (expresie pe câmpurile evenimentului), o cheie de grupare, o capacitate și o rată de scurgere. Două reguli practice:

• Grupează întotdeauna pe ceva — de regulă IP-ul sursă (groupby: evt.Meta.source_ip). Un scenariu fără grupare pune toate evenimentele într-un singur bucket comun și poate bana primul IP care îl umple, lăsând restul să treacă.
• Calibrează pragul pe date reale, nu pe intuiție: uită-te câte cereri face un vizitator legitim în cel mai rău caz și pune capacitatea peste acea valoare, cu marjă.

Prin Central API (CAPI), instanța ta primește un blocklist comunitar — IP-uri raportate de alte instalări pentru comportamente similare — și trimite la rândul ei semnalele pe care le detectează. Valoarea vine din efectul de rețea: un scanner care a lovit deja alte mii de servere poate fi blocat înainte să ajungă la tine.

Componenta AppSec adaugă capabilități de WAF: inspectează cererea înainte să ajungă la backend și aplică reguli de virtual patching pentru vulnerabilități cunoscute. Pluginul Traefik o poate interoga în paralel cu verificarea de decizii. Atenție la un detaliu: cererile refuzate de AppSec apar în access log ca răspunsuri ale proxy-ului, nu ale aplicației, deci nu vor alimenta automat scenariile bazate pe loguri — verifică separat cum se transformă o blocare AppSec repetată într-o decizie de ban.

Un IPS care banează clienți reali e mai rău decât unul care ratează un scanner. Sursele clasice de false pozitive:

• Crawlere legitime. Googlebot sau Bingbot pot face multe cereri distincte. Nu le identifica după User-Agent — acesta se falsifică trivial. Verifică operatorul prin reverse DNS confirmat sau prin intervalele de IP publicate, și folosește colecția de whitelist pentru actori buni.
• Bucla de amplificare. CrowdSec citește logul Traefik, inclusiv răspunsurile 403 date chiar de bouncer. Un IP banat care continuă să navigheze generează 403-uri, scenariile de probing le numără, iar banarea se reînnoiește la nesfârșit. Exclude prin parser răspunsurile produse de proxy, nu de aplicație.
• Prefetch și aplicații moderne. Framework-urile SPA pot trimite zeci de cereri distincte când se încarcă o pagină, fără acțiunea utilizatorului. Pentru un scenariu de crawling, asta arată ca un robot.
• Clienți care anulează cereri. Un browser mobil care închide conexiunile nu e un atac de tip slowloris.

Instrumentul de lucru este cscli explain --file linie.log --type traefik: arată pas cu pas ce parser a procesat linia și ce scenarii a atins. Testează în ambele sensuri — linia legitimă trebuie să rămână neatinsă, iar cererea de atac trebuie să declanșeze în continuare.

Când bouncer-ul nu poate contacta Local API, are două opțiuni: lasă traficul să treacă (fail-open, disponibilitate înainte de protecție) sau îl refuză (fail-closed, protecție înainte de disponibilitate). Fail-closed sună mai sigur, dar transformă orice problemă a CrowdSec — bază de date lentă, cheie invalidă după o reinstalare, container repornit — într-o pană totală a site-urilor. Alege conștient, monitorizează ultima sincronizare a bouncer-ului și nu seta intervalul de actualizare mai mic decât durata reală a unui pull complet, altfel cererile se pot suprapune sub încărcare.

Dacă pui CrowdSec în fața unor servicii esențiale, leagă-l și de restul controalelor tehnice cerute de NIS2 — vezi Art. 21 NIS2: controalele tehnice și hardening-ul serverelor Linux după CIS.