Un event handler è la regola che trasforma un flusso di log in un evento su cui qualcuno deve decidere qualcosa. In 7.6 si chiamano così: il nome alert handler arriva con la 8.0 e in questa GUI non lo troverai. Ne esistono due famiglie, e la differenza non è cosmetica.

Basic e correlation

In un basic handler l’evento nasce quando una qualsiasi delle regole è soddisfatta: sono in OR fra loro. In un correlation handler nasce quando un insieme di regole è soddisfatto in sequenza, e definisci sia le regole sia gli operatori: AND, AND_NOT, OR, FOLLOWED_BY e NOT_FOLLOWED_BY, questi ultimi due con un limite di tempo. Le regole si riordinano trascinandole e si raccolgono in logic group. Una Threshold Duration in minuti dice entro quanto la sequenza deve completarsi, e le Correlation Criteria collegano due regole confrontando un campo dell’una con uno dell’altra, scelti fra i campi del loro Group By.

Due vincoli di ambito: gli handler generano eventi solo dagli Analytics log, mai dagli Archive, e in una collaborazione Analyzer-Collector è l’Analyzer a valutarli. Ogni ADOM ha i propri handler e la propria lista di eventi; per replicarli altrove usa export e import.

Gli handler predefiniti non si cancellano e non ti lasciano toccare nome, descrizione e filtri: clonane uno e lavora sulla copia. Se ne hai già alterato uno, Factory Reset lo riporta com’era.

Le tre fasi di una regola

Choose Your Logs: Log Device Type, modificabile solo in un ADOM Security Fabric, poi Log Type ed eventualmente Log Subtype. Il Log Field qui non è un filtro, è il criterio di raggruppamento. Se scegli Source IP, i log con srcip 192.168.1.1, .2 e .3 finiscono in tre gruppi distinti e le soglie si contano per gruppo: è l’errore più comune al primo handler custom.

Refine Your Logs: i Log Filters si combinano con All Filters oppure Any One of the Filters. La tendina dei campi mostra solo quelli del log type scelto: Botnet IP compare con Log Type DNS e non con Event Log. Gli operatori dipendono dal campo. Se non c’è tendina digiti il valore, che deve corrispondere al log grezzo; se c’è ma non accetta valori personalizzati, l’unica via è il generic text filter.

Define Event Conditions: tre forme. Un gruppo contiene N o più occorrenze; dentro un gruppo un campo ha N o più valori unici, con un toggle per invertire in meno di N; oppure la somma di una misura supera una soglia, forma pensata per l’esfiltrazione e supportata solo negli ADOM Fabric. In tutti i casi aggiungi la finestra in minuti entro cui i log devono essere stati generati.

Il data selector: il filtro che sta a monte

I filtri di un data selector vengono applicati prima di ogni regola dell’handler: non serve ripetere gli stessi criteri dentro ciascuna, li scrivi una volta e assegni il selector, riusabile su più handler.

Porta tre cose: Devices (All Devices, Specify, oppure Local Device, disponibile solo nell’ADOM root per interrogare gli event log della FortiAnalyzer stessa, con Log Type obbligatoriamente Event Log e Log Subtype Any), Subnets con liste di inclusione ed esclusione, e una lista di filtri ciascuno col proprio Generic Text Filter.

Due regole sulle subnet che l’esame ama: se una subnet finisce sia in include sia in exclude vince exclude, e il filtro scatta quando SRCIP oppure DSTIP cade nella subnet, perché sorgente e destinazione condividono gli stessi filtri. I data selector predefiniti non sono modificabili né cancellabili.

Generic text filter

Nella regola si chiama Log Filter by Text, nel data selector Generic Text Filter. Usa la libreria regex glibc secondo lo standard POSIX per gli operatori che accettano espressioni regolari; le parole chiave non sono case sensitive, and e AND sono equivalenti.

Il modo veloce è andare in Log View, aprire Tools > Raw Log, copiare la stringa e incollarla. Due avvertenze: usa i nomi grezzi dei campi, mem e non memory, setuprate e non setup-rate, e ricorda l’escape.

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

Gli operatori sono = o == per la corrispondenza esatta, != per la non corrispondenza, ~ e !~ per contiene e non contiene, più i confronti numerici.

Cosa succede quando l’evento nasce

Ogni regola porta una Event Severity fra Critical, High, Medium e Low. L’Event Status può essere fissato o lasciato ad Allow FortiAnalyzer to choose: in quel caso un log IPS o AV con action=pass diventa Unhandled, action=quarantine Contained, action=block o drop Mitigated. I Tags alimentano le default view dell’Event Monitor, che però si popolano solo se il predefinito corrispondente è abilitato. Puoi aggiungere fino a cinque indicatori e personalizzare l’Event Message con $groupby1 e $groupby2.

Automatically Create Incident alza un incidente al primo alert; gli eventi con lo stesso subject vengono attaccati a quello, e uno nuovo nasce solo se cambia il subject o se il precedente è chiuso. Li riconosci da Auto-Raised nella colonna Incident Reporter.

Automation Stitch notifica l’evento al framework di automazione del FortiGate. La trappola: sul FortiGate servono il logging verso la FortiAnalyzer e un trigger per ogni handler con lo stitch attivo, incluso il predefinito Default-Botnet-Communication-Detection che lo ha già abilitato. Le notifiche agli umani passano invece dal notification profile: email, SNMP trap, syslog server o fabric connector.