Syslog y Common Event Format (CEF) a través de conectores AMA para Microsoft Sentinel

Syslog a través de AMA y Common Event Format (CEF) a través de conectores de datos AMA para Microsoft Sentinel filtrar e ingerir mensajes de Syslog, incluidos los mensajes en formato de evento común (CEF), desde máquinas Linux y desde dispositivos y dispositivos de red y seguridad. Estos conectores instalan Azure Monitor Agent (AMA) en cualquier máquina Linux desde la que quiera recopilar mensajes syslog o CEF. Esta máquina podría ser el originador de los mensajes o podría ser un reenviador que recopile mensajes de otras máquinas, como dispositivos y dispositivos de red o de seguridad. El conector envía las instrucciones de los agentes en función de las reglas de recopilación de datos (DCR) que defina. Los DCR especifican los sistemas que se van a supervisar y los tipos de registros o mensajes que se van a recopilar. Definen filtros para aplicarlos a los mensajes antes de ingerirlos, para mejorar el rendimiento y realizar consultas y análisis más eficaces.

Syslog y CEF son dos formatos comunes para registrar datos de diferentes dispositivos y aplicaciones. Ayudan a los administradores del sistema y a los analistas de seguridad a supervisar y solucionar problemas de la red e identificar posibles amenazas o incidentes.

¿Qué es Syslog?

Syslog es un protocolo estándar para enviar y recibir mensajes entre diferentes dispositivos o aplicaciones a través de una red. Originalmente se desarrolló para sistemas Unix, pero ahora es ampliamente compatible con varias plataformas y proveedores. Los mensajes de Syslog tienen una estructura predefinida que consta de una prioridad, una marca de tiempo, un nombre de host, un nombre de aplicación, un identificador de proceso y un texto de mensaje. Los mensajes de Syslog se pueden enviar a través de UDP, TCP o TLS, según la configuración y los requisitos de seguridad.

El Azure Monitor Agent (AMA) admite mensajes de Syslog con formato según RFC 3164 (Syslog de BSD) y RFC 5424 (Syslog de IETF).

¿Qué es el formato de evento común (CEF)?

CEF, o Common Event Format, es un formato neutral para el proveedor para registrar datos de dispositivos y dispositivos de red y seguridad, como firewalls, enrutadores, soluciones de detección y respuesta y sistemas de detección de intrusiones, así como de otros tipos de sistemas, como servidores web. Una extensión de Syslog, se desarrolló especialmente para soluciones de administración de eventos e información de seguridad (SIEM). Los mensajes CEF tienen un encabezado estándar que contiene información como el proveedor del dispositivo, el producto del dispositivo, la versión del dispositivo, la clase de eventos, la gravedad del evento y el identificador del evento. Los mensajes CEF también tienen un número variable de extensiones que proporcionan más detalles sobre el evento, como las direcciones IP de origen y destino, el nombre de usuario, el nombre de archivo o la acción realizada.

Recopilación de mensajes de Syslog y CEF con AMA

En los diagramas siguientes se muestra la arquitectura de la colección de mensajes syslog y CEF en Microsoft Sentinel, usando Syslog a través de AMA y Common Event Format (CEF) a través de conectores AMA.

En este diagrama se muestran los mensajes de Syslog que se recopilan de una sola máquina virtual Linux individual, en la que está instalado el agente de supervisión de Azure (AMA).

Diagrama de la colección syslog de un solo origen.

El proceso de ingesta de datos mediante el agente de supervisión de Azure usa los siguientes componentes y flujos de datos:

  • Los orígenes de registro son las distintas máquinas virtuales Linux del entorno que generan mensajes de Syslog. El demonio de Syslog local recopila estos mensajes en el puerto TCP o UDP 514 (u otro puerto según sus preferencias).

  • El demonio de Syslog local (o rsyslogsyslog-ng) recopila los mensajes de registro en el puerto TCP o UDP 514 (u otro puerto según sus preferencias). A continuación, el demonio envía estos registros al agente de Azure Monitor de dos maneras diferentes, según la versión de AMA:

    • Las versiones 1.28.11 y posteriores de AMA reciben registros en el puerto TCP 28330.
    • Las versiones anteriores de AMA reciben registros a través del socket de dominio unix.

    Si desea usar un puerto distinto de 514 para recibir mensajes syslog/CEF, asegúrese de que la configuración del puerto en el demonio de Syslog coincide con la de la aplicación que genera los mensajes.

  • El agente de Azure Monitor que instala en cada máquina virtual Linux de la que desea recopilar mensajes de Syslog mediante la configuración del conector de datos. El agente analiza los registros y, a continuación, los envía al área de trabajo de Microsoft Sentinel (Log Analytics).

  • El área de trabajo de Microsoft Sentinel (Log Analytics): los mensajes de Syslog enviados aquí terminan en la tabla Syslog, donde puede consultar los registros y realizar análisis en ellos para detectar y responder a amenazas de seguridad.

Nota:

Al ingerir datos de Syslog mediante un reenviador de registros y Azure Agente de supervisión (AMA), pueden surgir incoherencias entre los TimeGenerated campos y EventTime .

  • TimeGenerated refleja la hora UTC cuando el equipo que hospeda el reenviador o recopilador de registros procesó el mensaje de Syslog.
  • EventTime se extrae del encabezado syslog, que no incluye información de zona horaria y se convierte a UTC mediante el desplazamiento de zona horaria local del reenviador o recopilador.

Esto puede dar lugar a diferencias entre los dos campos cuando el reenviador o recopilador y el dispositivo que genera el registro se encuentran en zonas horarias diferentes.

Proceso de instalación para recopilar mensajes de registro

Desde el centro de contenido de Microsoft Sentinel, instale la solución adecuada para Syslog o Common Event Format. Este paso instala los conectores de datos respectivos Syslog a través de AMA o Common Event Format (CEF) a través del conector de datos AMA. Para obtener más información, consulte Detección y administración de Microsoft Sentinel contenido integrado.

Como parte del proceso de instalación, cree una regla de recopilación de datos e instale Azure Monitor Agent (AMA) en el reenviador de registros. Realice estas tareas mediante el portal de Azure o Microsoft Defender o mediante la API de ingesta de registros de Azure Monitor.

  • Al configurar el conector de datos para la Microsoft Sentinel en el portal de Azure o Microsoft Defender, puede crear, administrar y eliminar DCR por área de trabajo. La AMA se instala automáticamente en las máquinas virtuales que seleccione en la configuración del conector.

  • Como alternativa, envíe solicitudes HTTP a la API de ingesta de registros. Con esta configuración, puede crear, administrar y eliminar DCR. Esta opción es más flexible que el portal. Por ejemplo, con la API, puede filtrar por niveles de registro específicos. En el portal de Azure o Defender, solo puede seleccionar un nivel de registro mínimo. La desventaja de usar este método es que tiene que instalar manualmente el agente de Azure Monitor en el reenviador de registros antes de crear un DCR.

Después de crear dcr y de instalar AMA, ejecute el script de "instalación" en el reenviador de registros. Este script configura el demonio de Syslog para que escuche los mensajes de otras máquinas y abra los puertos locales necesarios. A continuación, configure los dispositivos o dispositivos de seguridad según sea necesario.

Para más información, consulte los siguientes artículos:

Evitación de la duplicación de ingesta de datos

El uso de la misma facilidad para los mensajes syslog y CEF puede dar lugar a la duplicación de ingesta de datos entre las tablas CommonSecurityLog y Syslog.

Para evitar este escenario, use uno de estos métodos:

  • Si el dispositivo de origen habilita la configuración de la instalación de destino: en cada máquina de origen que envía registros al reenviador de registros en formato CEF, edite el archivo de configuración de Syslog para quitar las instalaciones usadas para enviar mensajes CEF. De este modo, las instalaciones enviadas en CEF tampoco se envían en Syslog. Asegúrese de que cada DCR que configure use la instalación pertinente para CEF o Syslog, respectivamente.

    Para ver un ejemplo de cómo organizar un DCR para ingerir mensajes syslog y CEF del mismo agente, vaya a las secuencias syslog y CEF en el mismo DCR.

  • Si el cambio de la instalación del dispositivo de origen no es aplicable: después de crear el DCR, agregue la transformación de tiempo de ingesta para filtrar los mensajes CEF del flujo de Syslog para evitar la duplicación. Consulte Tutorial: Edición de una regla de recopilación de datos (DCR). Agregue una transformación KQL similar al ejemplo siguiente:

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

Pasos siguientes

Configuración de los conectores de datos

  • Last updated on