Una notifica CrowdSec su Discord informa che si è verificato un evento; da sola non dimostra che il traffico sia stato bloccato. Per fidarmi della pipeline verifico la catena completa: acquisizione dei log, rilevamento, decisione, applicazione del blocco e consegna del messaggio.
Nei runbook Romiltec CrowdSec compare insieme ai componenti che applicano le decisioni e a un notifier HTTP per Discord. È un’integrazione utile quando il canale viene seguito dalle persone responsabili del servizio. La scelta del canale, però, deve partire dall’organizzazione degli interventi.
Seguire un evento attraverso i componenti
Il motore di rilevamento legge e interpreta i log. Gli scenari riconoscono comportamenti e producono alert; i profili determinano decisioni e notifiche. Un bouncer applica la remediation nel punto per cui è stato configurato.
Per HTTP, SSH e altri servizi il punto di blocco può essere diverso. Il controllo deve raggiungere proprio il servizio protetto: trovare un IP nell’elenco delle decisioni non dimostra che il bouncer corretto l’abbia acquisito.
In un’installazione con più host, annoterei anche quale API riceve gli alert e quali componenti la consultano. La condivisione delle decisioni richiede una configurazione esplicita; non deriva semplicemente dall’aver installato lo stesso pacchetto su più macchine.
Configurare e provare il notifier
La documentazione delle notifiche CrowdSec descrive configurazioni e collegamento ai profili. Per Discord il payload deve rispettare il formato JSON atteso dal webhook, con il relativo Content-Type. L’URL del webhook è un segreto operativo e va escluso dal repository pubblico.
Partirei dal template della versione installata e lo proverei prima con un alert, poi con più alert e decisioni. I cicli del template possono produrre virgole mancanti, campi assenti o JSON invalido: il file YAML leggibile non prova che il messaggio risultante sia valido.
La CLI offre comandi per elencare, ispezionare e testare i notifier. Il test di consegna è il primo passaggio; dopo controllerei che un alert attraversi davvero il profilo previsto. Un template corretto ma mai richiamato rimane silenzioso.
Decidere quali messaggi richiedono attenzione
Nel messaggio metterei servizio interessato, scenario, decisione, durata e un riferimento che permetta di trovare l’alert nei log. Eviterei di riversare il contenuto completo delle richieste: può includere dati o token che non servono al triage.
Distinguerei un riepilogo del traffico già gestito da un evento che richiede una persona. Se ogni ban genera una menzione urgente, il canale può diventare difficile da seguire proprio quando c’è un problema importante.
Per valutare la notifica registrerei se è stata consegnata e quando qualcuno ha preso in carico l’evento. Non attribuirei una riduzione dei tempi di risposta al cambio di chat senza misurare entrambi i periodi.
Un falso positivo richiede una diagnosi
In una sessione operativa interna, molte connessioni SSH separate hanno coinciso con un blocco dell’indirizzo usato per amministrare il server. Il runbook successivo ha introdotto il riuso della connessione tramite multiplexing. Il caso ricorda che anche il traffico di manutenzione va incluso nelle prove.
Prima di allargare un’eccezione, guarderei log, scenario e decisione specifica. Non trasformerei l’incidente in una regola generale secondo cui tutte le autenticazioni ripetute sono ostili, o in un’autorizzazione permanente per una rete troppo ampia.
Per i crawler, nome nell’user-agent e appartenenza a un grande cloud non bastano. Google documenta la verifica delle proprie richieste tramite intervalli IP pubblicati o controlli DNS coerenti. Un’eccezione deve identificare il soggetto che si vuole consentire.
Controllare il percorso dietro la CDN
Se il sito passa da Cloudflare, il firewall dell’origine vede connessioni del proxy. Il trattamento dell’IP del visitatore e il punto di remediation devono essere coerenti; la remediation Cloudflare è una delle integrazioni da considerare.
Concluderei il collaudo con un evento controllato da una sorgente di test, osservando blocco, scadenza e successivo accesso. Manterrei un accesso amministrativo alternativo per la prova. Ho approfondito questo rapporto tra proxy e protezione nel caso Mattermost self-hosted.