Syslog e Common Event Format (CEF) tramite connettori AMA per Microsoft Sentinel

I connettori dati Syslog tramite AMA e Common Event Format (CEF) tramite AMA per Microsoft Sentinel filtrano e acquisiscono i messaggi Syslog, inclusi i messaggi in Common Event Format (CEF), da computer Linux e da dispositivi e appliance di rete e sicurezza. Questi connettori installano l'agente di monitoraggio Azure (AMA) in qualsiasi computer Linux da cui si desidera raccogliere messaggi Syslog e/o CEF. Questo computer potrebbe essere l'originatore dei messaggi o un server d'inoltro che raccoglie messaggi da altri computer, ad esempio dispositivi e appliance di rete o di sicurezza. Il connettore invia le istruzioni degli agenti in base alle regole di raccolta dati definite dall'utente. I DCR specificano i sistemi da monitorare e quali tipi di log o messaggi raccogliere. Definiscono i filtri da applicare ai messaggi prima che vengano acquisiti, per migliorare le prestazioni e rendere più efficienti le query e l’analisi.

Syslog e CEF sono due formati comuni per la registrazione dei dati da dispositivi e applicazioni diversi. Consentono agli amministratori di sistema e agli analisti della sicurezza di monitorare e risolvere i problemi di rete e identificare potenziali minacce o eventi imprevisti.

Che cos'è Syslog?

Syslog è un protocollo standard per l'invio e la ricezione di messaggi tra dispositivi o applicazioni diversi tramite una rete. È stato originariamente sviluppato per 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 dell'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 Azure supporta i messaggi Syslog formattati in base a RFC 3164 (BSD Syslog) e RFC 5424 (IETF Syslog).

Che cos'è Common Event Format (CEF)?

CEF, o Common Event Format, è un formato indipendente dal fornitore per la registrazione dei dati da dispositivi e appliance di rete e di sicurezza, ad esempio firewall, router, soluzioni di rilevamento e risposta e sistemi di rilevamento delle intrusioni, nonché da altri tipi di sistemi, ad esempio server Web. Estensione di Syslog, è stato sviluppato in particolare per le soluzioni siem (Security Information and Event Management). I messaggi CEF hanno un'intestazione standard che contiene informazioni quali il fornitore del dispositivo, il prodotto del dispositivo, la versione del dispositivo, la classe di evento, la gravità dell'evento e l'ID evento. I messaggi CEF hanno anche un numero variabile di estensioni che forniscono maggiori 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 dei messaggi Syslog e CEF in Microsoft Sentinel, utilizzando i connettori Syslog tramite AMA e Common Event Format (CEF) tramite AMA.

Questo diagramma mostra i messaggi Syslog raccolti da una singola macchina virtuale Linux, in cui è installato l'agente di monitoraggio Azure (AMA).

Diagramma della raccolta Syslog da una singola origine.

Il processo di inserimento dei dati tramite l'agente di monitoraggio Azure usa i componenti e i flussi di dati seguenti:

  • Le origini dei log sono le varie macchine virtuali Linux presenti nel tuo ambiente che producono messaggi Syslog. Questi messaggi vengono raccolti dal daemon Syslog locale sulla porta TCP o UDP 514 (o da un'altra porta in base alle proprie preferenze).

  • Il daemon Syslog locale ( rsyslog o syslog-ng) raccoglie i messaggi di log sulla porta TCP o UDP 514 (o su un'altra porta in base alle proprie preferenze). Il daemon invia quindi questi log all'agente di monitoraggio 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 il 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 Azure installato in ogni macchina virtuale Linux da cui si desidera raccogliere i messaggi syslog configurando il connettore dati. L'agente analizza i log e li invia all'area di lavoro Microsoft Sentinel (Log Analytics).

  • Area di lavoro Microsoft Sentinel (Log Analytics): i messaggi Syslog inviati qui si ritrovano nella tabella Syslog, in cui è possibile eseguire query sui log ed eseguire analisi su di essi per rilevare e rispondere alle minacce alla sicurezza.

Nota

Quando si acquisiscono dati syslog utilizzando un agente di inoltro dei log e Monitoraggio di Azure Agent (AMA), possono verificarsi incoerenze tra i campi TimeGenerated e EventTime.

  • TimeGenerated indica l'ora UTC in cui il messaggio syslog è stato elaborato dalla macchina che ospita il servizio di inoltro dei log o il collettore.
  • EventTime viene estratto dall'intestazione syslog, che non include le informazioni sul fuso orario e viene convertito in formato UTC usando l'offset del fuso orario locale dell'agente di inoltro/agente di raccolta.

Ciò può causare differenze tra i due campi quando il server d'inoltro/agente di raccolta e il dispositivo che genera il log si trovano in fusi orari diversi.

Processo di installazione per la raccolta dei messaggi di log

Dal Hub contenuto in Microsoft Sentinel, installa la soluzione appropriata per Syslog o Common Event Format. Questo passaggio installa i rispettivi connettori dati Syslog tramite AMA o Common Event Format (CEF) tramite il connettore dati AMA. Per ulteriori informazioni, vedere Individuare e gestire il contenuto predefinito di Microsoft Sentinel.

Come parte del processo di installazione, creare una regola di raccolta dati e installare l'agente di monitoraggio Azure (AMA) nel server d'inoltro del log. Eseguire queste attività usando il portale di Azure o Microsoft Defender o l'API di inserimento dei log di monitoraggio Azure.

  • Quando si configura il connettore dati per Microsoft Sentinel nel portale di Azure o di Microsoft Defender, è possibile creare, gestire ed eliminare le DCR (regole di raccolta dati) per area di lavoro. L'AMA viene installato automaticamente nelle macchine virtuali selezionate nella configurazione del connettore.

  • In alternativa, inviare richieste HTTP all'API di inserimento log. Con questa configurazione è possibile creare, gestire ed eliminare i DCR. Questa opzione è più flessibile rispetto al portale. Ad esempio, con l'API è possibile filtrare in base a livelli di log specifici. Nella Azure o nel portale di Defender è possibile selezionare solo un livello di log minimo. L'aspetto negativo dell'uso di questo metodo consiste nel fatto che è necessario installare manualmente l'agente di monitoraggio Azure nel server d'inoltro del log prima di creare un DCR.

Dopo aver creato il DCR e installato AMA, esegui lo script "installation" sul server di inoltro dei log. Questo script configura il daemon Syslog per l'ascolto dei messaggi provenienti da altri computer e per 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:

Prevenzione della duplicazione nell'acquisizione dei dati

L'uso della stessa funzionalità per i messaggi Syslog e CEF potrebbe comportare la duplicazione dell'inserimento dei dati tra le tabelle CommonSecurityLog e Syslog.

Per evitare questo scenario, usare uno di questi metodi:

  • Se il dispositivo di origine abilita la configurazione della funzionalità di destinazione: in ogni computer di origine che invia i log al server d'inoltro del log in formato CEF, modificare il file di configurazione Syslog per rimuovere le funzionalità usate per inviare messaggi CEF. In questo modo, le funzionalità inviate in CEF non vengono inviate anche in Syslog. Assicurarsi che ogni DCR configurato usi rispettivamente la funzionalità pertinente per CEF o Syslog.

    Per vedere un esempio di come disporre un DCR per inserire sia messaggi Syslog che CEF dallo stesso agente, passare ai 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 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:

    Nota

    A partire dalla versione 1.41 di AMA, il campo ProcessName potrebbe non contenere in modo attendibile "CEF" per i messaggi provenienti da produttori i cui messaggi non sono conformi al formato dell'intestazione syslog RFC 3164/RFC 5424. Per assicurarsi che i messaggi CEF siano filtrati correttamente, controllare sia ProcessName che SyslogMessage.

    "transformKql": "  source\n    |  where ProcessName !contains \"CEF\" and SyslogMessage !contains \"CEF:0\"\n"

Passaggi successivi

Configurare i connettori dati

  • Last updated on