L’event handler è la macchina che trasforma i log in eventi: senza handler abilitati l’Event Monitor resta vuoto anche mentre i log arrivano. In 7.6 la GUI distingue due famiglie di handler, basic e correlation, e tiene fuori da entrambe due oggetti riusabili: i data selector e i notification profile.

Basic e correlation: la differenza è l’operatore fra le regole

Un basic handler contiene una o più regole in relazione OR: basta che una regola sia soddisfatta perché nasca un evento. Un correlation handler pretende invece che un insieme di regole si verifichi in sequenza, e ti lascia scegliere l’operatore fra una regola e la successiva: AND, AND_NOT, OR, FOLLOWED_BY e NOT_FOLLOWED_BY. Le ultime due chiedono anche un limite di tempo proprio. Sopra a tutto c’è la Threshold Duration dell’handler, in minuti: se la sequenza non si chiude entro quella finestra l’evento non esce, ed è il primo posto dove guardare quando un correlation handler non scatta mai.

Due vincoli valgono per entrambe le famiglie. Il primo: gli handler generano eventi solo dagli Analytics log, mai dagli Archive. Il secondo: in uno scenario di collaborazione fra Analyzer e Collector è l’Analyzer a valutare gli handler. Infine ogni ADOM ha i propri handler e la propria lista eventi: la risposta più frequente a «perché non vedo l’evento» è «sei nell’ADOM sbagliato».

Sul nome: in 7.6 si chiamano event handler. Il percorso in GUI oscilla nella documentazione stessa fra «Event Handlers» e «Handlers»: impara la posizione delle quattro tab — Data Selectors, Notification Profiles, Basic Handlers, Correlation Handlers — non la stringa del menu.

Dentro una regola: raggruppa, filtra, conta

Ogni regola si costruisce in tre passi. In Choose Your Logs scegli device type, log type ed eventuale subtype, poi il Log Field che serve da chiave di raggruppamento: se raggruppi per Source IP il sistema crea un gruppo per ogni IP sorgente e conta dentro ciascun gruppo, non sul totale. In Refine Your Logs applichi i filtri, in AND o in OR fra loro; il dropdown dei log field mostra solo i campi che appartengono al log type scelto, e gli operatori disponibili dipendono dal campo. In Define Event Conditions scegli la condizione di innesco: un gruppo contiene N o più occorrenze, oppure un campo ha N o più valori unici — con un toggle per invertirlo in «meno di N» — oppure la somma di una misura supera N. Quest’ultima serve a rilevare esfiltrazione di dati ed è supportata solo negli ADOM Fabric. In tutti i casi puoi imporre che i log cadano entro N minuti.

Quando il dropdown di un valore non accetta testo libero l’unica strada è il Generic Text Filter, che dentro l’handler si chiama Log Filter by Text: regex glibc in standard POSIX, con gli escape obbligatori:

dstip==192.168.1.168 and hostname ~ "facebook"
dstip==192.168.1.168 and ( dstport == 514 or dstport == 515 )
cfgpath=firewall\.policy

L’operatore ~ significa «matcha la regex», !~ il contrario; senza il backslash prima del punto il filtro sui cambi di configurazione non trova niente.

Data selector: il filtro che vive prima delle regole

Un data selector raccoglie tre cose: dispositivi, subnet e filtri. I suoi filtri sono applicati prima di ogni regola dell’handler, quindi non devi ripetere gli stessi criteri in ogni regola — è il motivo per cui esiste. Con Devices impostato su Local Device interroghi gli event log del FortiAnalyzer stesso: l’opzione compare solo nell’ADOM root e obbliga Log Type a Event Log con subtype Any.

Le subnet sono la parte che si sbaglia. Se scegli Specify compaiono Include Subnets ed Exclude Subnets, e in caso di conflitto vince l’exclude. Il filtro inoltre non distingue la direzione: scatta quando l’indirizzo sorgente oppure quello di destinazione cade nella subnet. Escludere la subnet dei server di backup non silenzia solo il traffico che parte da lì, ma anche quello diretto verso di loro. I data selector di default, usati da alcuni handler predefiniti, non si possono modificare né cancellare: clonali.

Correlazione, notifiche e ciclo di vita degli handler

Nel correlation handler la sequenza dice quando, i Correlation Criteria dicono su cosa. Ogni criterio lega due regole confrontando un campo della prima con un campo della seconda, e i campi selezionabili sono quelli usati come Group By nelle rispettive regole: se non hai raggruppato per utente, non potrai correlare per utente. Puoi annidare le regole in logic group, sempre con un operatore fra un gruppo e l’altro, e rileggerle con Show Raw Config.

Le notifiche stanno in un oggetto separato: un notification profile manda l’alert via email, trap SNMP, syslog o fabric connector. Gli handler predefiniti non notificano nulla finché non gli assegni un profilo, ed è una delle sorprese più comuni in produzione. L’Automation Stitch è un’altra cosa: quando è attivo, FortiAnalyzer notifica il framework di automazione del FortiGate. Perché produca un effetto servono due condizioni sul FortiGate — che stia loggando verso il FortiAnalyzer e che esista uno stitch con trigger Incoming Webhook corrispondente a quell’handler. Il predefinito Default-Botnet-Communication-Detection nasce già con lo stitch abilitato.

Infine la gestione: i predefiniti non si cancellano e campi come nome, descrizione e filtri non si editano, quindi il flusso è clonare e personalizzare; per un predefinito manomesso c’è il Factory Reset. Export e import replicano gli handler su altri ADOM o su un’altra unità.