Syslog e Common Event Format (CEF) através de conectores AMA para Microsoft Sentinel

O Syslog via AMA e o Common Event Format (CEF) através de conectores de dados AMA para Microsoft Sentinel filtrar e ingerir mensagens Syslog, incluindo mensagens no Formato de Evento Comum (CEF), de máquinas Linux e de dispositivos e aplicações 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.

Coleção de mensagens Syslog e CEF com AMA

Os diagramas seguintes ilustram a arquitetura da coleção de mensagens Syslog e CEF no Microsoft Sentinel, com o Syslog via AMA e o Common Event Format (CEF) através de conectores 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:

  • As origens de registo são as várias VMs Linux no seu ambiente que produzem mensagens do 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 estes registos para o Agente do Azure Monitor de duas formas diferentes, consoante a versão 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 instala em cada Linux VM a partir da qual pretende recolher mensagens do Syslog ao configurar 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 do syslog com um reencaminhador de registos e Azure Agente de Monitorização (AMA), podem surgir inconsistências entre os TimeGenerated campos eEventTime.

  • 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 em UTC com o deslocamento do fuso horário local do reencaminhador/recoletor.

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

A partir do Hub de conteúdos no Microsoft Sentinel, instale a solução adequada para o Syslog ou Formato de Evento Comum. 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 Detetar e gerir Microsoft Sentinel conteúdo inicial.

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 o AMA estar instalado, execute o script de "instalação" no reencaminhador de registos. 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 da duplicação da 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. Desta forma, as instalações enviadas no CEF também não são enviadas no Syslog. Certifique-se de que cada DCR configurado utiliza as instalações relevantes para CEF ou Syslog, respetivamente.

    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 da dispositivo de origem não for aplicável: depois de criar o DCR, adicione a transformação do tempo de ingestão para filtrar as mensagens CEF do fluxo do Syslog para evitar a duplicação. Veja Tutorial: Editar uma regra de recolha de dados (DCR). Adicione uma transformação KQL semelhante ao seguinte exemplo:

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

Próximas etapas

Configurar os conectores de dados

  • Last updated on