Usare Logstash per inviare i log a Microsoft Sentinel tramite API basata su DCR
La data ingestion dei log attraverso la funzionalità descritta nell’articolo è attualmente in Anteprima Pubblica.
Il nuovo plug-in di Logstash di Microsoft Sentinel supporta le trasformazioni delle pipeline e la configrazione avanzata tramite regole di raccolta dati (DCR, Data Collection Rule). IL plug-in inoltra qualsiasi tipo di log di origini esterne in tabelle personalizzate o standard in Log Analytics o Microsoft Sentinel.
In questo articolo quindi vedremo insieme come configurare il plug-in Logstash per trasmettere i dati a Microsoft Sentinel usando le Data Collection Rule (DCR), avendo un controllo completo sullo schema di Output.
Con il nuovo plug-in messo a disposizione dalla casa di Redmond è possibile:
- Controllare la configurazione il nome delle colonne delle tabelle e del tipo delle stesse
- Eseguire “Trasformation” in fase di inserimento dati, come ad esempio filtri o arricchimenti
- Inserire log personalizzati in una tabella personalizzata o inserire un flusso di input Syslog nella Tabella Syslog di Log Analytics
Figura 1: Schema funzionamento di Logstash per Microsoft Sentinel
Il motore di Logstash è formato da tre componenti fondamentali:
- Plug-in di Input: che svolge la funzione di “raccolta” dati che provengono dalle fonti che collegheremo
- Plug-in di filtro: utile a “manipolare” e normalizzare i dati in base ai criteri che andremo a scegliere
- Plug-in di Output: permette l’invio dei dati “trasformati” alle diverse destinazioni
E’ bene inoltre specificare che Logstash per Microsoft Sentinel invia i dati in formato JSON al Workspace di Sentinel usando l’API di inserimento dei Log e questi dati vengono inseriti in Log Custom o in Tabelle Standard.
Prerequisiti
Per poter sfruttare questa funzionalità dovrete rispettare diversi prerequisiti, che per comodità vi riporto.
- Microsoft supporta solo il plug-in di Output di Logstash fornito da Sentinel che potete trovare al seguente Link Azure-Sentinel/DataConnectors/microsoft-sentinel-log-analytics-logstash-output-plugin at master · Azure/Azure-Sentinel · GitHub
- Microsoft non supporta plug-in Logstash di terze parti
- Subscription di Microsoft Azure per l’utilizzo di Workspace di Microsoft Sentinel
Inoltre dovrete rispettare i prerequisiti delle versioni relative al Plug-in che supporta le seguenti versioni di Logstash:
- 7.0 – 7.17.13
- 8.0 – 8.9
- 8.11 – 8.13
NB: Se utilizzate Logstash 8, è fortemente consigliato disabilitare ECS all’interno della pipeline
Svolgimento
Per darvi evidenza dell’installazione del plug-in di Logstash io utilizzerò una Virtual Machine di Libra Esva (Email Security Gateway), se volete approfondire la log collection di questa appliance vi rimando all’articolo presente al seguente link Eseguire il Parsing degli Audit Log di Libra Esva in Microsoft Sentinel – ICT Power ,che invierà i log ed una macchina in cui installerò logstash con sistema operativo Linux Ubuntu.
Figura 2: Workspace di Microsoft Sentinel che utilizzerò per l’ingestion dei Log
Figura 3: Macchina “FW-Linux” in cui installerò il plug-in di Logstash
Figura 4: Appliance Libra Esva che invierà i log
Ora procederò a darvi evidenza di come installare il plug-in all’interno della macchina Ubuntu, nel mio caso in Hosting presso Azure.
Accedo alla macchina Linux (FW-Linux) nel mio caso essendo solo ed esclusivamente a riga di comando procederò ad avviare Putty per il collegamento.
Figura 5: Putty in cui inseriamo IP della macchina Linux su porta 22 (SSH) per il collegamento
Figura 6: Accesso a macchina Linux effettuato con successo
Ora eseguirò il comando “sudo -i” in modo tale che qualsiasi comando eseguo sarà in modalità root
Figura 7: Comando sudo -i eseguito con successo e quindi ora ho diritti di root sulla macchina
Ora possiamo procedere ad installare logstash e successivamente procedere alla sua configurazione, vi riporto quindi i comandi che andremo ad eseguire nei passaggi successivi
- wget -qO – https://artifacts.elastic.co/GPG-KEY-elasticsearch | gpg –dearmor | sudo tee /etc/apt/trusted.gpg.d/elastic.gpg >/dev/null
- echo “deb https://artifacts.elastic.co/packages/8.x/apt stable main” | sudo tee -a /etc/apt/sources.list.d/elastic-8.x.list >/dev/null
- sudo apt-get update && sudo apt-get install logstash=1:8.14.1-1
- sudo apt-mark hold logstash
Figura 8: Installazione di Logstash direttamente dal repository di Elastic
Figura 9: Copiano i Package dal repository di Elastic all’interno della nostra cartella di installazione della macchina Ubuntu
Figura 10: Installazione della versione 8.14.1 di Logstash e aggiornamento delle librerie Ubuntu per recepire le modifiche necessarie
Figura 11: Fase di installazione di Logstash con relativa percentuale all’interno della macchina Ubuntu
Figura 12: Comando che permette di “bloccare” gli aggiornamenti di un pacchetto specifico, nel nostro caso quelli relativi a Logstash
Ora avrete completato l’installazione di Logstash all’interno della vostra macchina Ubuntu, è inoltre importante ricordarvi dove risiedono i file di configurazione di questo servizio:
- /usr/share/logstash/bin/ à file bin di Logstash
- /etc/logstash/ à file di configurazione di Logstash
- /etc/logstash/conf.d/ à Pipeline di Logstash
Ora possiamo proseguire installando il plugin di Logstash per Microsoft Sentinel tramite il seguente comando “sudo /usr/share/logstash/bin/logstash-plugin install microsoft-sentinel-logstash-output-plugin”
Figura 13: Comando per installazione Plugin di Logstash specifico per Microsoft Sentinel
Figura 14: Installazione Plugin Microsoft Sentinel in corso
Figura 15: Installazione Plug-in Microsoft Sentinel installato con successo
Ora possiamo verificare il funzionamento di Logstash per Microsoft Sentinel creando un file di esempio, per farlo creiamo una cartella temporanea, in cui verrà salvato il file in formato JSON tramite il comando “sudo mkdir /tmp/logstash” io ho scelto la cartella /tmp/logstash ma sceglietene una a vostro piacimento.
Figura 16: Creazione cartella temporanea in cui salverò il file di esempio per verificare il funzionamento di Logstash
Per verificare ora il corretto funzionamento procediamo a creare la prima Pipeline contente il file di esempio, per farlo eseguiamo il seguente comando: “sudo nano /etc/logstash/conf.d/syslog-to-dcr-based-sentinel-sample.conf”
Figura 17: Creazione Pipeline con file di esempio
Figura 18: Apertura del file di configurazione in modalità edit
Ora copiamo il seguente contenuto per far generare il file di esempio:
1 2 3 4 5 6 7 8 9 10 11 |
input { syslog { port => 514 } } output { microsoft-sentinel-logstash-output-plugin { create_sample_file => true sample_file_path => "/tmp/logstash/" } } |
NB: Sostituire “/tmp/logstash/” con la cartella temporanea da voi creata nei passaggi precedenti
Figura 19: Comandi copiati all’interno della Pipeline per generare il file di esempio
Ora procedete a salvare il file con la serie di comandi CTRL+X e Y.
Figura 20: Comandi CTRL+X che ci chiede se voler procedere al salvataggio del file
Ora potrete eseguire il comando “sudo /usr/share/logstash/bin/logstash -f /etc/logstash/conf.d/syslog-to-dcr-based-sentinel-sample.conf” in questo modo verrà eseguito Logstash in modalità interactive e vedrete che ad un certo punto si attenderà un Syslog sulla prota 514 come indicato nel file di configurazione, lo noterete perché all’interno del terminale ci sarà la seguente riga:
- syslog – Starting syslog tcp listener
Successivamente aprite una nuova sessione con Putty ed eseguite il comando “logger -p local4.warn –rfc3164 –tcp -t CEF: “0|NETWORK|YOURFAVORITEFIREWALL|DnsProxyLog|Datacenter|proxy|10.73.4.7|48454|113.1.15.87|443|123|OUT|eu-v20.events.data.microsoft.com|TCP|ALLOW” -P 514 -d -n 127.0.0.1″ utile per simulare un log proveniente da CEF sulla porta 514 come indicato all’interno della Pipeline.
Figura 21: Comando per eseguire in modalità interattiva logstash
Figura 22: Comando per simulare un log CEF sulla porta 514 come indicato nel file di esempio della Pipeline creata in precedenza
Figura 23: Macchina che rimane in ascolto in attesa dei log
Figura 24: Dopo che logstash recepisce il comando di test scrivo il log nella cartella che avremo indicato all’interno della Pipeline
Figura 25: Contenuto del file Json generato dalla Pipeline di esempio
Ora che avrete verificato il corretto funzionamento dell’installazione di Logstash e della Pipeline, potrete procedere a recarvi all’interno del portale di Azure per la creazione di:
- EntraID Application: per permettere a sentinel di avere i log inviati da Logstash
- DCR (Data Collection Rule): per permettere di collezionare i log necessari
- Custom Table in cui ospitare i log che Logstash passa a Microsoft Sentinel
Creazione EntraID Application
Accedete al portale Microsoft Entra admin center
Figura 26: Portale Microsoft Entra Admin Center per la creazione della App
Figura 27: Scelta di un nome per l’applicazione e salvataggio della configurazione
Figura 28: Application ID e Tenant id che dovrete salvare perché saranno necessarie per la configurazione di Logstash
Figura 29: Creazione Certificato applicazione che permetterà il corretto funzionamento di Logstash per Microsoft Sentinel
Figura 30: Copiare la Value del certificato e segnatevi la data di scadenza per un eventuale rinnovo
Ora per la creazione della Custom Table basata su DCR (Data Collection Rule) servirà il file Json di esempio, io utilizzando la logingestion da parte di Libra Esva farò generare un file di esempio (come abbiamo fatto in precedenza) ma questa volta facendo ricevere i log direttamente dall’appliance di Libra Esva, di cui vi fornisco l’esempio.
Accediamo all’appliance di Libra Esva
Figura 31: Accesso con utenza Admin all’appliance di Libra Esva per la configurazione Syslog
Figura 32: Inseriamo i dati, come IP indico quello pubblico della mia macchina Linux e salvo la configurazione
Ora all’interno della macchina Linux dobbiamo eseguire il comando per avviare Logstash attraverso la Pipeline creata in precedenza
Figura 33: Esecuzione del comando per eseguire logstash secondo la Pipeline creata (passando nel comando il file di configurazione)
Ora il sistema resterà in ascolto in attesa di log provenienti dall’appliance Libra Esva e genererà il file di esempio
Figura 34: File di esempio Generato
Ora tramite il tools WinSCP scarico il file all’interno del mio Computer
Figura 35: Download del file di esempio all’interno del mio dispositivo
Il primo passaggio è creare un Data Collection Endpoint
Figura 36: Creazione Data Collection Endpoint
Figura 37: Scegliamo un nome per l’endpoint, il resource group in cui inserirlo e la region Azure con relativa Subscription in cui salvare il nostro Endpoint
Figura 38: Endpoint presente dopo la creazione dello stesso
Ora potete procedere alla creazione di una Tabella Custom all’interno del vostro Log Analytics Workspace che ospiterà quindi i log provenienti da Logstash
Figura 39: Click sul vostro Log Analytics Workspace, che nel mio caso si chiama “WorkSpaceSentinel”
Figura 40: Creazione di una Custom Table nel workspace, basata su DCR (Data Collection Rule)
Figura 41: Scegliamo un nome per la tabella ed una descrizione parlante per identificarla in futuro, inoltre selezioniamo l’endpoint creato in precedenza e diamo un nome dalla DCR
Figura 42: Proseguiamo con la configurazione della tabella
Figura 43: Selezioniamo il file che abbiamo scaricato in precedenza dalla macchina Linux che funzionerà da Custom Trasformation dei log
Figura 44: Errore relativa alla colonna TimeGenerated che è obbligatoria, ma non presente nel mio file di esempio
Per poter risolvere l’errore segnalato dovremo utilizzare il “Trasformation Editor” in cui, nel mio caso per il parsing degli Audit log di Libra Esva ESG, sarà la seguente KQL (Kusto Query):
source
| extend TimeGenerated = ls_timestamp
Figura 45: KQL per la trasformazione, nel mio caso relativo agli Audit log di Libra Esva ESG
Figura 46: Proseguiamo con la configurazione salvando quanto fatto fino ad ora
Figura 47: Review della configurazione effettuata e salvataggio della DCR
Figura 48: Custom Table presente all’interno del Workspace successivamente alla sua creazione
Figura 49: Copiarsi l’Immutable ID della DCR che avete creato in quanto servirà nel file di configurazione di Logstash
Ora come ultimo passaggio dovremmo recuperare il link del “Data Collection Endpoint” anche esso andrà inserito all’interno della Pipeline di Logstash
Figura 50: Recuperiamo il link per la Log Ingestion del Data Collection Endpoint
L’ultima operazione da eseguire è concedere all’applicazione di EntraID creata i permessi di Monitoring Metrics Publisher all’interno della Data Collection Rule
Figura 51: Diamo i permessi alla APP di EntraID di accedere alla data collection Rule per la log ingestion
Figura 52: Assegniamo il ruolo di Monitoring Metrics Publisher
Figura 53: Assegniamo e selezioniamo l’applicazione corretta per la log ingestion di Microsoft Sentinel
Figura 54: Salvataggio dell’applicazione dei permessi
Figura 55: Applicazione che ora ha i permessi corretti all’interno della DCR
Dovrete assegnare i permessi di “Monitoring Metrics Publisher” anche al Data Collection Endpoint, come fatto per la DCR
Figura 56: Assegnazione permessi al Data Collection Endpoint
Figura 57: Assegnazione permessi al Data Collection Endpoint
Figura 58: Selezionate l’applicazione di EntraID e concedete ad essa i permessi al Data Collection Endpoint
Ora possiamo ritornare nella nostra macchina Ubuntu in cui è presente logstash e modificare il file di Pipeline, modificando il file di configurazione per mandare i log a Sentinel invece che creare un file di esempio, sostituendo i seguenti campi con quelli recuperati durante la configurazione della custom Table:
- Client_app_id
- Client_app_secret
- Tenant_id
- Data_collection_endpoint
- Dcr_immutable_id
- Dcr_Stream_name
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
input { syslog { port => 514 } } output { microsoft-sentinel-logstash-output-plugin { client_app_Id => "<APPID>" client_app_secret => "<APPSECRET>" tenant_id => "<TENANTID>" data_collection_endpoint => "https://<DCEURI>.westeurope-1.ingest.monitor.azure.com" dcr_immutable_id => "dcr-<IMMUTABLEID>" dcr_stream_name => "Custom-<TABLENAME>" } } |
Accediamo quindi con putty alla nostra macchina Linux con installato Logstash:
Figura 59: Apriamo in Modalità Edit il file di Configurazione
Figura 60: Rimozione della parte evidenzata che serviva per generare il file di esempio
Nel mio caso inserisco i valori nel Notepad del mio dispositivo per poi incollarli all’interno del file di configurazione per comodità
Figura 61: File della pipeline compilato in Notepad adesso procederò ad inserirlo all’interno della Pipeline
Figura 62: File di Pipeline modifica per inviare i log a Sentinel, salviamolo con la combinazione di tasti CTRL+X – Y – Invio
Ora è tutto pronto e possiamo eseguire Logstash con la nuova Pipeline
Figura 63: Esecuzione di logstash con la nuova Pipeline
Figura 64: Verifica che dalla macchina Logstash i dati vengono correttamente inviati a Microsoft Sentinel
NB: Prima di poter visualizzare i log nella tabella Custom, la documentazione ufficiale parla di 15 minuti, ma nel mio caso ci sono volute più di due ore, quindi se non visualizzati dati nella tabella non preoccupatevi aspettate che arriveranno
Ora per leggere i dati rechiamoci in Microsoft Sentinel
Figura 65: Selezioniamo il nome della nostra tabella Custom e troveremo tutti i nostri log di Libra Esva con il parsing e le trasformation create
Ottimizzazioni di configurazione
Vorrei anche darvi evidenza di una ottimizzazione che è possibile attuare nella configurazione, riguarda la modalità ECS di Logstash per ridurre in modo considerevole l’Ingestion dei log riducendo di fatto i log doppi ECS in Logstash | Logstash Reference [8.4] | Elastic
Per disabilitare ECS in Logstash versione 8.X come consigliato da Microsoft è possibile modificare il file di configurazione Logstash.yml con il seguendo comando “pipeline.ecs_compatibility: disabled”
Figura 66: Apertura in modalità edit del file logstash.yml per configurare ECS
Figura 67: Disabilitazione ECS, salviamo il file con il solito comando CTRL+X – Y – Invio
Conclusioni
Questa configurazione, anche se attualmente in Preview, aiuterebbe molto nella configurazione di invio log da diverse fonti Syslog e CEF Log, come nel mio caso di Libra Esva, perché permette tramite una semplice configurazione di Logstash di avere a disposizione uno strumento che vi aiuta ad ottimizzare la log Ingestion riducendo in modo considerevole il numero di Log, e questo in Microsoft Sentinel vuol dire anche un risparmio economico.
Un altro vantaggio è quello di poter inviare i log in tabelle Custom, magari creando più pipeline e inviando i log in tabelle divise per apparati e quindi avere una situazione molto ordinata e utile anche e soprattutto agli analisti per la ricerca dei dati durante le analisi.
Un altro vantaggio è anche quello di poter eseguire il parsing e la trasformazione dei dati prima che essi arrivino all’interno delle tabelle.
Uno step veramente importante a mio avviso per rendere ancora più performante il SIEM e SOAR di casa Redmond.