Resolver problemas do CEF e do Syslog através de conectores AMA

Este artigo fornece orientações de resolução de problemas para a recolha de dados do Common Event Format (CEF) e do Syslog com o Agente do Azure Monitor (AMA) no Microsoft Sentinel. Utilize este guia para diagnosticar e resolver problemas de ingestão com os computadores reencaminhadores de registos. Os comandos e configurações devem ser executados nos computadores do reencaminhador de registos onde o AMA e o RSyslog/Syslog-ng estão instalados.

Antes de começar a resolução de problemas, familiarize-se com os seguintes artigos:

Descrição geral da arquitetura

O diagrama seguinte ilustra o fluxo de dados de origens de registo para Microsoft Sentinel/áreas de trabalho de análise de registos através do RSyslog e do Agente do Azure Monitor.

Diagrama a mostrar o fluxo de dados da origem para o Log Analytics através de RSyslog e AMA.

Componentes principais:

  • RSyslog/Syslog-ng: Recebe registos na porta 514 e reencaminha-os para o AMA
  • Agente do Azure Monitor: processa os registos de acordo com as Regras de Recolha de Dados (DCR)
  • Regra de Recolha de Dados: define os registos a recolher e para onde os enviar

Passos de verificação inicial

Verificar se os registos estão a ser recebidos

Os registos podem demorar até 20 minutos a aparecer no Microsoft Sentinel após a configuração.

  1. Execute o tcpdump para verificar se os registos estão a chegar ao reencaminhador:

    sudo tcpdump -i any port 514 -A -vv

  2. Verifique se a origem de registo está configurada para enviar mensagens para o endereço IP do reencaminhador correto.

  3. Verifique se existem componentes de infraestrutura que possam afetar a conectividade:

    • Firewalls
    • Balanceadores de carga
    • Grupos de segurança de rede

Verificar Azure estado da extensão do Agente do Monitor

  1. No portal do Azure, navegue para a máquina virtual do reencaminhador de registos.
  2. Selecione Extensões + aplicações.
  3. Selecione a extensão AzureMonitorLinuxAgent .
  4. Verifique se o Estado mostra o Aprovisionamento bem-sucedido.

Verificar a versão do agente

  1. No painel extensão AzureMonitorLinuxAgent , verifique o campo Versão .
  2. Certifique-se de que a versão é uma das versões 2-3 mais recentes. Veja os detalhes da versão AMA das versões mais recentes.

Nota

As novas versões podem demorar até 5 semanas a ser lançadas após o lançamento inicial.

Resolução de problemas ao nível do agente

Certifique-se de que o agente e os serviços RSyslog estão em execução.

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

Verificar a configuração do RSyslog

A configuração do RSyslog é composta por ficheiros /etc/rsyslog.conf e no /etc/rsyslog.d/.

  1. Verificar a configuração da porta:

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

    Resultado esperado:

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

  2. Verifique se a configuração de reencaminhamento AMA existe:

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

    O ficheiro deve começar com:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Verificar o estado da porta

Verifique se as portas necessárias estão a escutar:

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

Resultado esperado:

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))

Isto confirma:

  • O RSyslog está a escutar na porta 514 (TCP e UDP)
  • O MDSD (componente AMA) está a escutar na porta 28330 (TCP)

Verificar a configuração da Regra de Recolha de Dados

Verifique se o DCR está configurado corretamente no agente.

Para registos CEF:

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

Para registos do Cisco ASA:

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

O resultado deve mostrar uma cadeia JSON que contém a configuração DCR.

Rever regras de firewall

Certifique-se de que as regras de firewall permitem a comunicação entre:

  • Origem do registo e RSyslog (porta 514)
  • RSyslog e AMA (porta 28330)
  • Pontos finais ama e Azure

Configuração da Regra de Recolha de Dados

Ativar todas as instalações para resolução de problemas

Para a resolução de problemas inicial:

  1. Na portal do Azure, navegue para a Regra de Recolha de Dados.
  2. Ative todas as instalações do syslog.
  3. Selecione todos os níveis de registo.
  4. Se disponível, ative a recolha de mensagens sem facilidade ou gravidade.

Para obter mais informações, consulte Selecionar instalações e gravidades.

Validação do Formato de Evento Comum (CEF)

Requisitos de formato CEF

O CEF utiliza o Syslog como um mecanismo de transporte com esta estrutura:

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

Exemplo:

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

Problemas comuns de formatação do CEF

Formato de cabeçalho incorreto

  • Certifique-se de que a versão do CEF está presente: CEF:0|
  • Todos os campos de cabeçalho têm de estar presentes e delimitados por carateres de pipe (|)

Escape de carateres incorríveis

  • Os carateres de pipe (|) nos valores do cabeçalho têm de ser escapados: \|
  • As barras invertidas () têm de ser escapadas: \\
  • Os sinais de igual (=) nas extensões têm de ser escapados: \=

Valores em falta ou não mapeados

Para obter a especificação completa do CEF, procure a documentação "Implementar o Formato de Evento Comum (CEF) do ArcSight".

Resolução de problemas avançada

Ativar o rastreio de diagnóstico

Aviso

Ative os sinalizadores de rastreio apenas para sessões de resolução de problemas. Os sinalizadores de rastreio geram um registo extenso que pode preencher rapidamente o espaço em disco.

  1. Edite o ficheiro de configuração AMA:

    sudo vim /etc/default/azuremonitoragent

  2. Adicione sinalizadores de rastreio à linha de 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. Reinicie o agente:

    sudo systemctl restart azuremonitoragent

  4. Reproduza o problema e aguarde alguns minutos.

  5. Reveja as informações de depuração em /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Remova o sinalizador de rastreio e reinicie o agente após a resolução de problemas.

Monitorizar o processamento de registos em tempo real

Veja os registos recebidos à medida que são processados:

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

Filtrar por tipos de registo específicos:

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

Reveja os registos de instalações específicos:

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

Verificar o processamento de registos com êxito

Quando os sinalizadores de rastreio estão ativados, pode verificar se os registos estão a ser processados corretamente ao examinar a saída de depuração.

Exemplo de ingestão de registos do ASA

Para os registos do Cisco ASA, o processamento bem-sucedido aparece nos registos como:

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

Indicadores-chave do processamento bem-sucedido:

  • O evento é reconhecido como um evento CiscoASA
  • O registo é carregado para o ODS (Operations Data Service)
  • É gerado um ID de pedido para controlo
  • O payload contém dados JSON formatados corretamente

Exemplo de ingestão de registos CEF

Para os registos CEF, o processamento com êxito é apresentado como:

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

Indicadores-chave do processamento CEF bem-sucedido:

  • O tipo de dados é SECURITY_CEF_BLOB
  • O pedido de carregamento inclui um ponto final válido
  • A estrutura de mensagens CEF é preservada no payload
  • As métricas de compressão mostram que os dados estão a ser otimizados para transferência

Importante

Lembre-se de desativar os sinalizadores de rastreio após concluir a investigação para evitar a utilização excessiva do disco.

Recolher informações de diagnóstico

Antes de abrir um pedido de suporte, recolha as seguintes informações:

Executar a resolução de problemas do AMA

O script pode ser executado com sinalizadores específicos para diferentes tipos de registo.

  • --cef: para registos do Formato de Evento Comum
  • --asa: Para registos do Cisco ASA
  • --ftd: Para registos da Defesa Contra Ameaças de Poder de Fogo da Cisco

O resultado é guardado em /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]

Conteúdos relacionados

  • Last updated on