Nuovo appuntamento relativo al mondo Log Analytics, in cui andremo a parlare di come recuperare i log provenienti dai firewall Fortinet, per memorizzare le attività amministrative, ma anche per tenere sotto controllo eventuali problemi.
Prima di cominciare è necessario aver configurato una macchina Linux che si occupi di fare log forwarding verso Log Analytics. I passaggi per configurare sono riportati nel seguente articolo – Azure Arc: configurare un Linux rsyslog verso Log Analytics – WindowServer.it
Configurazione FortiGate
L’integrazione passa da due step: attivazione del syslog e configurazione di cosa inviare al syslog. Il primo passaggio si effettua sia da CLI che da UI, però con il primo metodo possiamo specificare anche la facility da utilizzare. I comandi da lanciare all’interno della console sono i seguenti:
config log syslogd setting
set status enable
set port 514
set server “x.x.x.x”
set format cef
set facilicy local4
end
NB: chiaramente l’indirizzo IP del server sarà quello della macchina Linux configurata con Azure Arc.
La seconda configurazione consiste nell’indicare quali log inviare e questa operazione è possibile farla dalla UI del Fortigate.
Il consiglio che posso dare è di non attivare I log relativi al traffico, questo perchè a noi serve sapere se vengono fatte modifiche all’interno del device, o se avvengono attività particolari, e non cosa succede nel traffico – cosa che già viene gestita dal firewall stesso.
Al limite, potreste pensare di attivare i log in inbound, per un periodo breve, per vedere se qualcuno provare a farvi degli attacchi ma anche in questo caso è meglio demandare la cosa all’interfaccia del firewall.
Prova in Log Analytics
Se avete seguito correttamente il precedente articolo, e magari avete già attivato un i syslog per un altro scopo, dovrete solo attivare la facility LOG_USER4 – o quella usata nel punto precedente – all’interno della Data Collection Rule, per attivare la cattura dei nuovi log.
A questo punto potreste già fare una prova per verificare se il vostro dispositivo sta inviando correttamente i log, attraverso una query KQL come questa: Syslog | where Computer contains “fw01” | project EventTime, SeverityLevel, SyslogMessage, ProcessName – dove nel valore Computer dovete inserire il nome del vostro firewall.
Come si può però notare, la colonna Message appare un po’ confusionaria, mentre il ProcessName risulta essere CEF, mentre noi stiamo chiamando una query tramite Syslog. Questo succede perché, il formato di salvataggio dei log avviene appunto standard CEF, quindi è necessario normalizzare i dati prima di fare l’ingestion.
Integrazione con Microsoft Sentinel
Per fare questa normalizzazione è necessario utilizzare una delle solution presenti all’interno di Microsoft Sentinel. Questa soluzione si trova all’interno del Content Hub e prende il nome il Common Event Format via AMA, che richiede anche una configurazione dedicata di una diversa Data Collection Rule, specifica per questo scopo.
Come si può notare dall’immagine, la, o le, facilities da scegliere sono le stesse che sono state configurate all’interno dei vai apparati di rete (LOG_LOCAL4 nel nostro caso).
Conclusa la procedura, sarà possibile lanciare la seguente query KQL – CommonSecurityLog – per avere un risultato come il seguente.
Fortinet Solution
Il vantaggio di Microsoft Sentinel è fornire non solo delle regole di detection, per notificare proattivamente dei pericoli o dei comportamenti anomali, ma anche rendere disponibili degli Azure Workbook contenenti informazioni utili per capire cosa sta succedendo. Per quanto riguarda Fortinet, esiste una soluzione all’interno del Content Hub.
All’interno della soluzione, esistono due Data Connector deprecati, chiamati Fortinet via AMA e Legacy Agent, perché sostituiti dal più standard Common Event File via AMA.
Come si può notare dall’immagine, la solution contiene anche dei Playbook che possono andare ad eseguire operazioni di vario genere.
Azure Workbook
Incluso nella soluzione Fortinet, troviamo anche un Azure Workbook che offre una serie di informazioni necessarie a capire cosa sta succedendo al nostro firewall.
Performance Monitoring
Una delle cose più interessanti, offerta da questa integrazione, è legata al fatto che il firewall restituisce anche alcune informazioni sull’utilizzo delle risorse, come CPU e RAM. Questi valori, tuttavia, si trovano nella colonna Message e devono essere estratte; la query utile a questo scopo è la seguente:
CommonSecurityLog | where Computer contains “fw01” | where DeviceEventClassID contains “40704” | extend CPU = toint(extract(“average CPU: (\\d+)”, 1, Message)) | extend Memory = toint(extract(“memory:\\s+(\\d+)”, 1, Message)) | project TimeGenerated, CPU, Memory | render timechart
Conclusioni
L’integrazione dei vari device con Microsoft Log Analystics e Microsoft Sentinel, permettono di avere non solo uno stato sulle attività svolte, e prevenire attacchi o operazioni pericolose, ma anche di avere informazioni utili a capire le performance – importanti per capire se i nostri dispositivi sono in sofferenza o non stanno performando correttamente.