Syslog e Common Event Format (CEF) tramite connettori dell’agente di Monitoraggio di Azure per Microsoft Sentinel
I connettori dati Syslog tramite AMA e Common Event Format (CEF) tramite AMA per Microsoft Sentinel filtrano e inseriscono rapidamente messaggi Syslog, tra cui i messaggi in Common Event Format (CEF), da computer Linux e da dispositivi e appliance dispositivi di sicurezza e di rete. Questi connettori installano l'agente di Monitoraggio di Azure in qualsiasi computer Linux da cui si vogliono raccogliere messaggi Syslog e/o CEF. Questo computer potrebbe essere l'origine dei messaggi o un server d'inoltro che raccoglie messaggi da altri computer, ad esempio dispositivi di rete o dispositivi e appliance di sicurezza. Il connettore invia le istruzioni degli agenti in base alle Regole di raccolta dati (DCR) definite dall'utente. I controller di dominio specificano i sistemi da monitorare e i tipi di log o messaggi da raccogliere. Definiscono i filtri da applicare ai messaggi prima che vengano inseriti, per ottenere prestazioni migliori ed eseguire query e analisi più efficienti.
Syslog e CEF sono due formati comuni per la registrazione dei dati provenienti da dispositivi e applicazioni diversi. Consentono agli amministratori di sistema e agli analisti della sicurezza di monitorare e risolvere i problemi della rete e identificare potenziali minacce o eventi imprevisti.
Che cos'è Syslog?
Syslog è un protocollo standard per l'invio e la ricezione di messaggi tra diversi dispositivi o applicazioni in rete. È stato originariamente sviluppato per i sistemi Unix, ma è ora ampiamente supportato da varie piattaforme e fornitori. I messaggi Syslog hanno una struttura predefinita costituita da una priorità, un timestamp, un nome host, un nome applicazione, un ID processo e un testo del messaggio. I messaggi Syslog possono essere inviati tramite UDP, TCP o TLS, a seconda della configurazione e dei requisiti di sicurezza.
L'agente di Monitoraggio di Azure supporta le RFC Syslog 3164 e 5424.
Cos’è il Common Event Format (CEF)?
CEF, o Common Event Format, è un formato indipendente dal fornitore per la registrazione dei dati provenienti da dispositivi e dispositivi di sicurezza di rete e dispositivi, ad esempio firewall, router, soluzioni di rilevamento e risposta e sistemi di rilevamento delle intrusioni, nonché da altri tipi di sistemi come i server Web. Un'estensione di Syslog, è stata sviluppata soprattutto per soluzioni SIEM (Security Information and Event Management). I messaggi CEF hanno un'intestazione standard che contiene informazioni quali il fornitore, il prodotto e la versione del dispositivo, la classe, la gravità e l'ID dell’evento. I messaggi CEF hanno anche un numero variabile di estensioni che forniscono altri dettagli sull'evento, ad esempio gli indirizzi IP di origine e di destinazione, il nome utente, il nome file o l'azione eseguita.
Raccolta di messaggi Syslog e CEF con AMA
I diagrammi seguenti illustrano l'architettura della raccolta di messaggi Syslog e CEF in Microsoft Sentinel, usando il Syslog tramite AMA e Common Event Format (CEF) tramite i connettori AMA.
Questo diagramma mostra i messaggi Syslog raccolti da una singola macchina virtuale Linux in cui è installato l'agente di Monitoraggio di Azure.
Il processo di inserimento dati con l'agente di Monitoraggio di Azure usa i componenti e i flussi di dati seguenti:
Le Origini log sono le varie macchine virtuali Linux nell'ambiente che producono messaggi Syslog. Questi messaggi vengono raccolti dal daemon Syslog locale sulla porta TCP o UDP 514 (o un'altra porta in base alle preferenze).
Il daemon Syslog locale (
rsyslogosyslog-ng) raccoglie i messaggi di log sulla porta TCP o UDP 514 (o un'altra porta in base alle preferenze). Il daemon invia quindi questi log all'agente di Monitoraggio di Azure in due modi diversi, a seconda della versione AMA:- Le versioni AMA 1.28.11 e successive ricevono i log sulla porta TCP 28330.
- Le versioni precedenti di AMA ricevono i log tramite socket di dominio Unix.
Se si vuole usare una porta diversa da 514 per la ricezione di messaggi Syslog/CEF, assicurarsi che la configurazione della porta nel daemon Syslog corrisponda a quella dell'applicazione che genera i messaggi.
L'agente di Monitoraggio di Azure installato in ogni macchina virtuale Linux da cui si vogliono raccogliere messaggi Syslog configurando il connettore dati. L'agente analizza i log e li invia all'area di lavoro Microsoft Sentinel (Log Analytics).
L'area di lavoro Microsoft Sentinel (Log Analytics): i messaggi Syslog inviati qui finiscono nella tabella Syslog, in cui è possibile eseguire query e analisi sui log per rilevare e rispondere alle minacce alla sicurezza.
Processo di installazione per raccogliere messaggi di log
Dall’Hub contenuti in Microsoft Sentinel, installare la soluzione appropriata per Syslog o Common Event Format. Questo passaggio installa i rispettivi connettori dati Syslog tramite AMA o CEF (Common Event Format) tramite il connettore dati AMA. Per altre informazioni, vedere Individuare e gestire contenuti predefiniti di Microsoft Sentinel.
Come parte del processo di installazione, creare una regola di raccolta dati e installare l'agente di Monitoraggio di Azure (AMA) nel server d'inoltro dei log. Eseguire queste attività usando il portale di Azure o Microsoft Defender o l'API di inserimento dei log di Monitoraggio di Azure.
Quando si configura il connettore dati per Microsoft Sentinel nel portale di Azure o Microsoft Defender, è possibile creare, gestire ed eliminare controller di dominio per area di lavoro. L’AMA viene installato automaticamente sulle macchine virtuali che si selezionano nella configurazione del connettore.
In alternativa, inviare richieste HTTP all'API di inserimento dei log. Con questa configurazione è possibile creare, gestire ed eliminare diverse DCR. Questa opzione è più flessibile rispetto al portale. Ad esempio, con l'API è possibile filtrare in base a livelli di log specifici. Nel portale Azure o Defender, è possibile selezionare solo un livello di log minimo. Lo svantaggio dell'uso di questo metodo è che è necessario installare manualmente l'agente di Monitoraggio di Azure nel server d'inoltro dei log prima di creare un registro DCR.
Dopo aver creato il DCR e aver completato l’installazione dell'AMA, eseguire lo script di "installazione" nel server d'inoltro dei log. Questo script configura il daemon Syslog per l'ascolto dei messaggi da altri computer e aprire le porte locali necessarie. Configurare quindi i dispositivi o le appliance di sicurezza in base alle esigenze.
Per altre informazioni, vedere gli articoli seguenti:
- Inserire messaggi Syslog e CEF in Microsoft Sentinel con l'agente di Monitoraggio di Azure
- CEF tramite il connettore dati AMA - Configurare un'appliance o un dispositivo specifico per l'inserimento dati di Microsoft Sentinel
- Syslog tramite il connettore dati AMA - Configurare un'appliance o un dispositivo specifico per l'inserimento dati di Microsoft Sentinel
Prevenzione della duplicazione dell'inserimento dati
L’uso della stessa struttura per i messaggi Syslog e CEF potrebbe comportare la duplicazione dell'inserimento dati tra le tabelle CommonSecurityLog e Syslog.
Per evitare questo scenario, ricorrere a uno dei seguenti metodi:
Se il dispositivo di origine permette la configurazione della struttura di destinazione: in ogni computer di origine che invia i log al server d'inoltro dei log in formato CEF, modificare il file di configurazione di Syslog per rimuovere le funzionalità per l'invio di messaggi CEF. In questo modo, le strutture inviate in CEF non verranno inviate anche in Syslog. Assicurarsi che ogni controller di dominio configurato usi rispettivamente la funzionalità pertinente per CEF o Syslog.
Per un esempio di come disporre un DCR per inserire messaggi Syslog e CEF dallo stesso agente, passare a flussi Syslog e CEF nello stesso DCR.
Se la modifica della funzionalità per l'appliance di origine non è applicabile: dopo aver creato il DCR, aggiungere la trasformazione del tempo di inserimento per filtrare i messaggi CEF dal flusso Syslog per evitare la duplicazione. Vedere Esercitazione: Modificare una regola di raccolta dati (DCR). Aggiungere una trasformazione KQL simile all'esempio seguente:
"transformKql": " source\n | where ProcessName !contains \"CEF\"\n"