Guida operativa basata su un caso verificato. Scenario applicativo CrowdSec verificato: riconoscimento di richieste con parametri ID sospetti, alert e decisione effettivamente presente in ipset.
Scenario reale
Un reverse proxy riceveva richieste HTTP anomale con combinazioni di identificatori numerici ripetuti, un User-Agent sospetto e nessun Referer. Si voleva bloccare il traffico senza penalizzare richieste ordinarie o crawler legittimi.
Individuare i segnali
La condizione aveva più caratteristiche contemporanee: almeno tre identificatori numerici, assenza del Referer, una determinata combinazione di User-Agent e un insieme di risposte HTTP. Aumentare la precisione dei criteri evita ban basati soltanto su un singolo URL.
Verifiche CrowdSec
crowdsec -t
cscli scenarios list
cscli alerts list
cscli decisions list
cscli metricsIl nome del parser e dei metadati deve corrispondere ai log realmente acquisiti. Le regole personalizzate vanno provate contro esempi innocui e sospetti.
Dalla decisione al firewall
Non basta vedere un alert CrowdSec: la decisione deve arrivare al bouncer e al set firewall. Nel caso verificato un IP di prova è comparso nella lista ipset con un timeout residuo di circa 24 ore, confermando l'effettiva applicazione del blocco.
Test controllato
ipset list -name
# Individuare il set gestito dal bouncer, poi:
ipset list NOME_SET | head -40
cscli decisions list --type banNon generare richieste massive verso sistemi terzi per provare il filtro; usare una sorgente autorizzata e un set di URL di test.
Conclusione
La corretta catena è log HTTP → parser → scenario → decisione LAPI → bouncer → ipset. La verifica di ogni anello riduce i falsi positivi e le false sensazioni di protezione.
Approfondimenti correlati
Comandi e percorsi riportano segnaposto generici; verificare versioni e backup prima di applicarli in produzione.