Fra il momento in cui un FortiGate genera un evento e quello in cui tu lo trovi in Log View ci sono parecchi passaggi. Sapere in quale ti trovi è metà del troubleshooting: un log «mancante» sta quasi sempre fermo in una fase precisa, e ogni fase si diagnostica in modo diverso.

Il trasporto: OFTP, due flussi e una sorpresa

FortiGate e FortiAnalyzer si parlano con OFTP, protocollo proprietario Fortinet usato per connettività, health check, trasferimento file e visualizzazione dei log lato FortiGate. Resta in ascolto su TCP514 e UDP514.

Qui arriva la sorpresa che sfugge a molti. Nella configurazione predefinita i flussi sono due e non hanno lo stesso trattamento: la comunicazione OFTP viaggia su TCP514 con TLS ed è cifrata, mentre la comunicazione dei log viaggia su UDP514 e non lo è. Vedere il tunnel OFTP «up e in TLS» non significa quindi che i log siano protetti: per spostarli su canale sicuro devi abilitare il logging affidabile lato FortiGate:

config log fortianalyzer setting
    set reliable enable
end

Da quel momento i log passano su TCP514 in TLS. Il prezzo è dichiarato: il trasferimento sicuro su TCP impatta le prestazioni di logging. Il guadagno, oltre alla riservatezza, è il caching: se la connessione cade il FortiGate mette i log in cache e li invia quando torna.

Seconda trappola, stesso terreno. Dalla 6.2 tutti i log dei dispositivi Fortinet via OFTP devono essere cifrati, e la regola sui livelli è asimmetrica: la cifratura del FortiAnalyzer deve essere uguale o inferiore a quella del dispositivo che invia. Se alzi enc-algorithm sul FortiAnalyzer sopra quello del FortiGate i log smettono di essere accettati, e la causa non si vede guardando il FortiGate.

Tre fasi, non due

I log su FortiAnalyzer vivono in una di tre fasi, e confonderle porta a diagnosi sbagliate.

I real-time log sono appena arrivati e non ancora inseriti nel database SQL: stanno in Archive, in un file non compresso. Gli Archive log sono quelli il cui file real-time è stato completamente inserito: a quel punto il file viene compresso ed è considerato offline. Gli Analytics log, o log storici, sono indicizzati nel database SQL e sono online.

Quando un file raggiunge il limite viene «rollato»: FortiAnalyzer lo rinomina nella forma xlog.N.log, dove la lettera indica il tipo di log e N è un numero univoco legato alla prima riga ricevuta. In Log View, Logs > All mostra i real-time oppure gli storici, mentre Log Browse legge sia il file attivo sia quelli compressi. Custom View e Chart Builder esistono solo nella vista storica: se ti mancano, sei in real-time.

La normalizzazione avviene all’inserimento

FortiAnalyzer 7.6 usa un database SQL ClickHouse, e i database SQL remoti non sono supportati.

Il pezzo che conta è questo: gli Analytics log vengono «sezionati» durante l’inserimento e i sottotipi finiscono in una categoria propria. Un log di web filtering viene inviato e archiviato come Traffic log, ma in fase di Analytics i campi di web filtering vengono estratti in una tabella dedicata. Ecco perché la stessa riga si comporta diversamente in Log Browse e in Log View: nell’archivio è un traffic log, nel database è già scomposta.

Attenzione ai campi temporali, tre e non intercambiabili. itime è il timestamp UTC di quando il log è arrivato al FortiAnalyzer; dtime è l’ora del dispositivo, cioè epoch di creazione più l’offset di fuso in secondi; eventtime è in nanosecondi alla generazione sul FortiGate. Con FortiGate in fusi diversi sullo stesso FortiAnalyzer conviene itime, indipendente dal fuso; dtime serve per mostrare l’ora locale o calcolare durate.

Il parsing SIEM per tutto il resto

I Fabric log sono una funzione a licenza: le capacità SIEM analizzano, normalizzano e correlano i log dei prodotti Fortinet, dei web server Apache e Nginx e dei security event log di host Windows e Linux tramite Fabric Agent.

Il parsing è predefinito e non richiede configurazione manuale. I parser si gestiscono da Incidents & Events > Log Parser, con due schede: Log Parsers li elenca, Assigned Parsers mostra l’abbinamento fra device, applicazione e parser corrente. Le azioni utili sul campo sono Validate — incolli un log grezzo e vedi il Parse Result, un parser alla volta — e Reorder, che cambia la priorità. Un parser predefinito non si cancella, e uno assegnato e in uso non si disabilita. Import ed export lavorano in JSON: per farne uno custom, esporta un predefinito e usalo come modello. Per isolare i log di un parser, filtra Log View > Logs > All per Data Parser Name.

Una nota che vale un ticket: il database SIEM nasce da solo negli ADOM Fabric quando la licenza è applicata e i device Fabric iniziano a loggare, ma i log passati e i file importati non vi rientrano.

Quando il flusso si inceppa

Per default non è applicato alcun rate limit in ricezione. Impostandolo a mano puoi definire un limite di default e uno per device o per ADOM: se si sovrappongono vince quello per device. Per vedere cosa succede davvero:

diagnose test application fortilogd 17
diagnose test application oftpd 17
diagnose fortilogd lograte-adom <nome-adom>

Se devi dimostrare che un file non è stato alterato dopo la ricezione, FortiAnalyzer calcola un checksum MD5 per file di log — ma il default è nessun checksum: va abilitato prima con log-checksum e verificato poi con execute log-integrity.