Risolvere i problemi relativi a CEF e Syslog tramite i connettori AMA

Questo articolo fornisce indicazioni per la risoluzione dei problemi relativi alla raccolta di dati CEF (Common Event Format) e Syslog tramite l'agente di monitoraggio Azure (AMA) in Microsoft Sentinel. Usare questa guida per diagnosticare e risolvere i problemi di inserimento con i computer di inoltro del log. I comandi e le configurazioni devono essere eseguiti nei computer di inoltro del log in cui sono installati AMA e RSyslog/Syslog-ng.

Prima di iniziare la risoluzione dei problemi, acquisire familiarità con gli articoli seguenti:

Panoramica dell'architettura

Il diagramma seguente illustra il flusso di dati dalle origini di log alle aree di lavoro Microsoft Sentinel/log analytics tramite RSyslog e l'agente di monitoraggio Azure.

Diagramma che mostra il flusso di dati dall'origine a Log Analytics tramite RSyslog e AMA.

Componenti chiave:

  • RSyslog/Syslog-ng: riceve i log sulla porta 514 e li inoltra ad AMA
  • agente di monitoraggio Azure: elabora i log in base alle regole di raccolta dati (DCR)
  • Regola raccolta dati: definisce quali log raccogliere e dove inviarli

Passaggi di verifica iniziali

Verificare che i log vengano ricevuti

La visualizzazione dei log in Microsoft Sentinel dopo la configurazione può richiedere fino a 20 minuti.

  1. Eseguire tcpdump per verificare che i log arrivino al server d'inoltro:

    sudo tcpdump -i any port 514 -A -vv

  2. Verificare che l'origine del log sia configurata per inviare messaggi all'indirizzo IP del server d'inoltro corretto.

  3. Verificare la presenza di componenti dell'infrastruttura che potrebbero influire sulla connettività:

    • Firewall
    • Servizi di bilanciamento del carico
    • Gruppi di sicurezza di rete

Controllare Azure stato dell'estensione dell'agente di monitoraggio

  1. Nella portale di Azure passare alla macchina virtuale del server d'inoltro di log.
  2. Selezionare Estensioni e applicazioni.
  3. Selezionare l'estensione AzureMonitorLinuxAgent .
  4. Verificare che Stato mostri il provisioning completato.

Verificare la versione dell'agente

  1. Nel pannello dell'estensione AzureMonitorLinuxAgent controllare il campo Versione .
  2. Verificare che la versione sia una delle versioni 2-3 più recenti. Per le versioni più recenti, vedere i dettagli della versione AMA .

Nota

L'implementazione delle nuove versioni può richiedere fino a 5 settimane dopo la versione iniziale.

Risoluzione dei problemi a livello di agente

Assicurarsi che l'agente e i servizi RSyslog siano in esecuzione.

sudo systemctl status azuremonitoragent
sudo systemctl status rsyslog
sudo systemctl status syslog-ng.service # If using Syslog-ng

Verificare la configurazione di RSyslog

La configurazione di /etc/rsyslog.conf RSyslog è costituita da file e in /etc/rsyslog.d/.

  1. Verificare la configurazione della porta:

    grep -E 'imudp|imtcp' /etc/rsyslog.conf

    Output previsto:

    module(load="imudp")
input(type="imudp" port="514")
module(load="imtcp")
input(type="imtcp" port="514")

  2. Verificare che la configurazione di inoltro AMA esista:

    cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf

    Il file deve iniziare con:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Verificare lo stato della porta

Verificare che le porte necessarie siano in ascolto:

sudo ss -lnp | grep -E "28330|514"

Output previsto:

udp   UNCONN 0      0      0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=5))
tcp   LISTEN 0      10     127.0.0.1:28330     0.0.0.0:*    users:(("mdsd",pid=1424,fd=1363))
tcp   LISTEN 0      25     0.0.0.0:514         0.0.0.0:*    users:(("rsyslogd",pid=12289,fd=7))

Ciò conferma quanto segue:

  • RSyslog è in ascolto sulla porta 514 (TCP e UDP)
  • MDSD (componente AMA) è in ascolto sulla porta 28330 (TCP)

Verificare la configurazione della regola di raccolta dati

Controllare se il DCR è configurato correttamente nell'agente.

Per i log CEF:

sudo grep -i -r "SECURITY_CEF_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

Per i log di Cisco ASA:

sudo grep -i -r "SECURITY_CISCO_ASA_BLOB" /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks

L'output deve mostrare una stringa JSON contenente la configurazione DCR.

Esaminare le regole del firewall

Assicurarsi che le regole del firewall consentano la comunicazione tra:

  • Origine log e RSyslog (porta 514)
  • RSyslog e AMA (porta 28330)
  • AMA e endpoint Azure

Configurazione delle regole di raccolta dati

Abilitare tutte le funzionalità per la risoluzione dei problemi

Per la risoluzione dei problemi iniziale:

  1. Nella portale di Azure passare alla regola di raccolta dati.
  2. Abilitare tutte le funzionalità syslog.
  3. Selezionare tutti i livelli di log.
  4. Se disponibile, abilitare la raccolta di messaggi senza funzionalità o gravità.

Per altre informazioni, vedere Selezionare le strutture e le gravità.

Convalida CEF (Common Event Format)

Requisiti di formato CEF

CEF usa Syslog come meccanismo di trasporto con questa struttura:

<Priority>Timestamp Hostname CEF:Version|Device Vendor|Device Product|Device Version|Device Event Class ID|Name|Severity|[Extension]

Esempio:

Jan 18 11:07:53 host CEF:0|Vendor|Product|1.0|100|EventName|5|src=10.0.0.1 dst=10.0.0.2

Problemi comuni di formattazione CEF

Formato di intestazione non corretto

  • Verificare che sia presente la versione CEF: CEF:0|
  • Tutti i campi di intestazione devono essere presenti e delimitati da caratteri pipe (|)

Escape di caratteri non corretto

  • I caratteri pipe (|) nei valori di intestazione devono essere preceduti da caratteri di escape: \|
  • Le barre rovesciate () devono essere precedute da caratteri di escape: \\
  • I segni di uguale (=) nelle estensioni devono essere preceduti da caratteri di escape: \=

Valori mancanti o non mappati

Per la specifica CEF completa, cercare la documentazione relativa all'implementazione del formato cef (Common Event Format) di ArcSight.

Risoluzione avanzata dei problemi

Abilitare la traccia diagnostica

Avviso

Abilitare i flag di traccia solo per le sessioni di risoluzione dei problemi. I flag di traccia generano una registrazione completa che può riempire rapidamente lo spazio su disco.

  1. Modificare il file di configurazione ama:

    sudo vim /etc/default/azuremonitoragent

  2. Aggiungere flag di traccia alla riga MDSD_OPTIONS:

    export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"

  3. Riavviare l'agente:

    sudo systemctl restart azuremonitoragent

  4. Riprodurre il problema e attendere alcuni minuti.

  5. Esaminare le informazioni di debug in /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Rimuovere il flag di traccia e riavviare l'agente dopo la risoluzione dei problemi.

Monitorare l'elaborazione dei log in tempo reale

Visualizzare i log in ingresso durante l'elaborazione:

tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Filtrare per tipi di log specifici:

sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.* | grep -a "CEF"

Esaminare i log di funzionalità specifici:

grep local0.info /var/opt/microsoft/azuremonitoragent/log/mdsd.info

Verificare che l'elaborazione dei log sia riuscita

Quando i flag di traccia sono abilitati, è possibile verificare che i log vengano elaborati correttamente esaminando l'output di debug.

Esempio di inserimento del log ASA

Per i log di Cisco ASA, l'elaborazione corretta viene visualizzata nei log come segue:

2022-01-18T22:00:14.8650520Z: virtual bool Pipe::SyslogCiscoASAPipeStage::PreProcess(std::shared_ptr<CanonicalEntity>) (.../mdsd/PipeStages.cc +604) [PipeStage] Processing CiscoASA event '%ASA-1-105003: (Primary) Monitoring on 123'

2022-01-18T22:00:14.8651330Z: virtual void ODSUploader::execute(const MdsTime&) (.../mdsd/ODSUploader.cc +325) Uploading 1 SECURITY_CISCO_ASA_BLOB rows to ODS.

2022-01-18T22:00:14.8653090Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CISCO_ASA_BLOB. Payload: {"DataType":"SECURITY_CISCO_ASA_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:28:49.775619Z","HostIP":"127.0.0.1","Message":" (Primary) Monitoring on 123","ProcessId":"","Severity":"info","Host":"localhost","ident":"%ASA-1-105003"}]}. Uncompressed size: 443. Request size: 322

Indicatori chiave dell'elaborazione riuscita:

  • L'evento è riconosciuto come evento CiscoASA
  • Il log viene caricato in ODS (Operations Data Service)
  • Viene generato un ID richiesta per il rilevamento
  • Il payload contiene dati JSON formattati correttamente

Esempio di inserimento del log CEF

Per i log CEF, l'elaborazione completata viene visualizzata come segue:

2022-01-14T23:09:13.9087860Z: int ODSUploader::UploadFixedTypeLogs(const string&, const string&, const std::function<void(bool, long unsigned int, int, long unsigned int)>&, int, uint64_t) (.../mdsd/ODSUploader.cc +691) Uploading to ODS with request 3333-44dd-555555eeeeee Host https://00001111-aaaa-2222-bbbb-3333cccc4444.ods.opinsights.azure.com for datatype SECURITY_CEF_BLOB. Payload: {"DataType":"SECURITY_CEF_BLOB","IPName":"SecurityInsights","ManagementGroupId":"00000000-0000-0000-0000-000000000002","sourceHealthServiceId":"2c2c2c2c-3333-dddd-4444-5e5e5e5e5e5e","type":"JsonData","DataItems":[{"Facility":"local0","SeverityNumber":"6","Timestamp":"2022-01-14T23:08:49.731862Z","HostIP":"127.0.0.1","Message":"0|device1|PAN-OS|8.0.0|general|SYSTEM|3|rt=Nov 04 2018 07:15:46 GMTcs3Label=Virtual","ProcessId":"","Severity":"info","Host":"localhost","ident":"CEF"}]}. Uncompressed size: 482. Request size: 350

Indicatori chiave dell'elaborazione CEF riuscita:

  • Il tipo di dati è SECURITY_CEF_BLOB
  • La richiesta di caricamento include un endpoint valido
  • La struttura dei messaggi CEF viene mantenuta nel payload
  • Le metriche di compressione mostrano che i dati sono ottimizzati per il trasferimento

Importante

Ricordarsi di disabilitare i flag di traccia dopo aver completato l'indagine per evitare un utilizzo eccessivo del disco.

Raccogliere informazioni di diagnostica

Prima di aprire un caso di supporto, raccogliere le informazioni seguenti:

Eseguire lo strumento di risoluzione dei problemi di AMA

Lo script può essere eseguito con flag specifici per tipi di log diversi.

  • --cef: per i log common event format
  • --asa: per i log di Cisco ASA
  • --ftd: per i log di Cisco Firepower Threat Defense

L'output viene salvato in /tmp/troubleshooter_output_file.log.

sudo wget -O Sentinel_AMA_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/Syslog/Sentinel_AMA_troubleshoot.py && sudo python3 Sentinel_AMA_troubleshoot.py [--cef | --asa | --ftd]

Contenuto correlato

  • Last updated on