Syslog e Common Event Format (CEF) usando conectores AMA para o Microsoft Sentinel

Os conectores de dados Syslog via AMA e Common Event Format (CEF) via AMA do Microsoft Sentinel filtram e ingerem mensagens Syslog, incluindo mensagens no formato Common Event Format (CEF), de máquinas Linux e de dispositivos e equipamentos de rede e segurança. Estes conectores instalam o Agente do Azure Monitor (AMA) em qualquer computador Linux a partir do qual pretenda recolher mensagens Syslog e/ou CEF. Este computador pode ser o originador das mensagens ou pode ser um reencaminhador que recolhe mensagens de outras máquinas, como dispositivos e aplicações de rede ou segurança. O conector envia as instruções dos agentes com base nas Regras de Recolha de Dados (DCRs) que definir. Os DCRs especificam os sistemas a monitorizar e os tipos de registos ou mensagens a recolher. Definem filtros a aplicar às mensagens antes de serem ingeridas, para um melhor desempenho e uma consulta e análise mais eficientes.

O Syslog e o CEF são dois formatos comuns para registar dados de diferentes dispositivos e aplicações. Ajudam os administradores de sistema e analistas de segurança a monitorizar e resolver problemas da rede e a identificar potenciais ameaças ou incidentes.

O que é o Syslog?

O Syslog é um protocolo padrão para enviar e receber mensagens entre diferentes dispositivos ou aplicações através de uma rede. Foi originalmente desenvolvido para sistemas Unix, mas agora é amplamente suportado por várias plataformas e fornecedores. As mensagens do Syslog têm uma estrutura predefinida que consiste numa prioridade, um carimbo de data/hora, um nome de anfitrião, um nome de aplicação, um ID de processo e um texto de mensagem. As mensagens do Syslog podem ser enviadas através de UDP, TCP ou TLS, consoante a configuração e os requisitos de segurança.

O Agente do Azure Monitor (AMA) suporta mensagens Syslog formatadas de acordo com RFC 3164 (Syslog BSD) e RFC 5424 (Syslog IETF).

O que é o Common Event Format (CEF)?

O CEF, ou Formato de Evento Comum, é um formato neutro para o fornecedor para registar dados de dispositivos e aplicações de rede e segurança, como firewalls, routers, soluções de deteção e resposta e sistemas de deteção de intrusões, bem como de outros tipos de sistemas, como servidores Web. Uma extensão do Syslog, foi desenvolvida especialmente para soluções de gestão de informações e eventos de segurança (SIEM). As mensagens CEF têm um cabeçalho padrão que contém informações como o fornecedor do dispositivo, o produto do dispositivo, a versão do dispositivo, a classe do evento, a gravidade do evento e o ID do evento. As mensagens CEF também têm um número variável de extensões que fornecem mais detalhes sobre o evento, como os endereços IP de origem e de destino, o nome de utilizador, o nome do ficheiro ou a ação tomada.

Coleta de mensagens Syslog e CEF com AMA

Os diagramas a seguir ilustram a arquitetura da coleta de mensagens Syslog e CEF no Microsoft Sentinel, usando os conectores Syslog via AMA e Formato Comum de Evento (CEF) via AMA.

Este diagrama mostra as mensagens Syslog a serem recolhidas a partir de uma única máquina virtual Linux individual, na qual o agente do Azure Monitor (AMA) está instalado.

Diagrama da coleção Syslog de origem única.

O processo de ingestão de dados com o Agente do Azure Monitor utiliza os seguintes componentes e fluxos de dados:

  • Fontes de log são as várias VMs Linux em seu ambiente que produzem mensagens Syslog. Estas mensagens são recolhidas pelo daemon Syslog local na porta TCP ou UDP 514 (ou outra porta de acordo com a sua preferência).

  • O daemon Syslog local (ou rsyslog ) syslog-ngrecolhe as mensagens de registo na porta TCP ou UDP 514 (ou noutra porta de acordo com a sua preferência). Em seguida, o daemon envia esses logs para o Azure Monitor Agent de duas maneiras diferentes, dependendo da versão do AMA:

    • As versões 1.28.11 e superiores da AMA recebem registos na porta TCP 28330.
    • As versões anteriores do AMA recebem registos através do socket de domínio Unix.

    Se quiser utilizar uma porta diferente da 514 para receber mensagens Syslog/CEF, certifique-se de que a configuração da porta no daemon do Syslog corresponde à da aplicação que está a gerar as mensagens.

  • O agente do Azure Monitor que você instala em cada VM Linux da qual deseja coletar mensagens do Syslog, configurando o conector de dados. O agente analisa os registos e, em seguida, envia-os para a área de trabalho do Microsoft Sentinel (Log Analytics).

  • A área de trabalho do Microsoft Sentinel (Log Analytics): as mensagens Syslog enviadas para aqui acabam na tabela Syslog, onde pode consultar os registos e realizar análises sobre os mesmos para detetar e responder a ameaças de segurança.

Observação

Ao ingerir dados de syslog usando um encaminhador de logs e o Agente do Azure Monitor (AMA), podem surgir inconsistências entre os campos TimeGenerated e EventTime.

  • TimeGenerated reflete a hora UTC em que a mensagem syslog foi processada pelo computador que aloja o reencaminhador de registos ou recoletor.
  • EventTime é extraído do cabeçalho do syslog, que não inclui informações de fuso horário, e é convertido para UTC usando o deslocamento do fuso horário local do encaminhador/coletor.

Isto pode levar a diferenças entre os dois campos quando o reencaminhador/recoletor e o dispositivo que gera o registo estão em fusos horários diferentes.

Processo de configuração para recolher mensagens de registo

No Content hub do Microsoft Sentinel, instale a solução apropriada para Syslog ou Common Event Format. Este passo instala os respetivos conectores de dados Syslog através do AMA ou do Common Event Format (CEF) através do conector de dados AMA. Para obter mais informações, consulte Descobrir e gerenciar o conteúdo pronto para uso do Microsoft Sentinel.

Como parte do processo de configuração, crie uma regra de recolha de dados e instale o Azure Monitor Agent (AMA) no reencaminhador de registos. Efetue estas tarefas com o portal Azure ou Microsoft Defender ou com a API de ingestão de registos do Azure Monitor.

  • Quando configura o conector de dados para o Microsoft Sentinel no portal Azure ou Microsoft Defender, pode criar, gerir e eliminar DCRs por área de trabalho. O AMA é instalado automaticamente nas VMs que selecionar na configuração do conector.

  • Em alternativa, envie pedidos HTTP para a API de Ingestão de Registos. Com esta configuração, pode criar, gerir e eliminar DCRs. Esta opção é mais flexível do que o portal. Por exemplo, com a API, pode filtrar por níveis de registo específicos. No portal do Azure ou do Defender, só pode selecionar um nível mínimo de registo. A desvantagem de utilizar este método é que tem de instalar manualmente o Agente do Azure Monitor no reencaminhador de registos antes de criar um DCR.

Depois de criar o DCR e instalar o AMA estiver, execute o script de "instalação" no encaminhador de log. Este script configura o daemon do Syslog para escutar mensagens de outros computadores e para abrir as portas locais necessárias. Em seguida, configure os dispositivos ou aplicações de segurança conforme necessário.

Para saber mais, confira os seguintes artigos:

Prevenção de duplicação na ingestão de dados

A utilização da mesma facilidade para mensagens Syslog e CEF pode resultar na duplicação da ingestão de dados entre as tabelas CommonSecurityLog e Syslog.

Para evitar este cenário, utilize um destes métodos:

  • Se o dispositivo de origem ativar a configuração da instalação de destino: em cada computador de origem que envia registos para o reencaminhador de registos no formato CEF, edite o ficheiro de configuração do Syslog para remover as instalações utilizadas para enviar mensagens CEF. Dessa forma, os recursos enviados no CEF também não serão enviados no Syslog. Certifique-se de que cada DCR que você configurar utilize a instalação relevante para CEF ou Syslog, respectivamente.

    Para ver um exemplo de como organizar um DCR para ingerir mensagens Syslog e CEF do mesmo agente, aceda a Fluxos Syslog e CEF no mesmo DCR.

  • Se a alteração da instalação para o dispositivo de origem não for aplicável: após criar a DCR, adicione uma transformação de tempo de ingestão para filtrar mensagens CEF do fluxo Syslog e evitar a duplicação. Veja Tutorial: Editar uma regra de recolha de dados (DCR). Adicione uma transformação KQL semelhante ao seguinte exemplo:

    Observação

    A partir da versão 1.41 do AMA, o campo ProcessName pode não conter "CEF" de forma confiável para mensagens de fornecedores que não seguem o formato de cabeçalho syslog RFC 3164/RFC 5424. Para garantir que as mensagens CEF sejam filtradas corretamente, verifique ambos ProcessName e SyslogMessage.

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

Próximas etapas

Configurar os conectores de dados

  • Last updated on