Compartir a través de

Syslog y Formato de evento común (CEF) a través de conectores AMA para Microsoft Sentinel

  • Artículo

Los conectores de datos de Syslog mediante el AMA y Formato de evento común (CEF) a través del AMA para el filtro de Microsoft Sentinel y los mensajes de Syslog de ingesta, incluyendo aquellos de Formato de evento común (CEF), desde máquinas Linux y desde dispositivos de seguridad y red. Estos conectores instalan el agente de Azure Monitor (AMA) en cualquier máquina Linux desde la que quiera recopilar mensajes Syslog o CEF. Esta máquina podría ser el origen de los mensajes, o podría ser un reenviador que recopila mensajes de otras máquinas, como dispositivos de seguridad o de red. El conector envía las instrucciones de los agentes en función de las reglas de recopilación de datos (DCR) que defina. Las DCR especifican los sistemas que se van a supervisar y los tipos de registros o mensajes que se van a recopilar. Definen filtros que se aplicarán a los mensajes antes de que se ingieren, 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 ya 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 id. de proceso y un texto del 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 agente de Azure Monitor admite los puertos RFC 3164 y 5424 de Syslog.

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

CEF, o formato de evento común, es un formato neutral del proveedor para registrar datos de dispositivos de red y seguridad (por ejemplo,firewalls, enrutadores, soluciones de detección y respuesta, y sistemas de detección de intrusiones), así como de otros tipos de sistemas (por ejemplo, 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, el producto y la versión del dispositivo, así como la clase, la gravedad y el id. 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.

Colección de mensajes Syslog y CEF con AMA

En los diagramas siguientes se muestra la arquitectura de la colección de mensajes de Syslog y CEF en Microsoft Sentinel, mediante el uso de los conectores Syslog a través de AMA y formato de evento común (CEF) a través de 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 Azure Monitor (AMA).

Diagrama de la colección de Syslog desde un único origen.

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

  • Orígenes de registros son las distintas máquinas virtuales Linux del entorno que generan mensajes de Syslog. Estos mensajes se recopilan mediante el demonio de Syslog local en el puerto TCP o UDP 514 (u otro puerto según, sus preferencias).

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

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

    Si desea usar un puerto distinto del 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 se instala en cada máquina virtual Linux de la que quiere 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 que se envían aquí terminan en la tabla Syslog, donde puede consultar los registros y realizar análisis sobre ellos para detectar y responder a amenazas de seguridad.

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 Formato de evento común. En este paso se instalan los conectores de datos respectivos Syslog a través de AMA o Formato de evento común (CEF) a través del conector de datos AMA. Para más información, consulte Descubra y administre el contenido listo para usar de Microsoft Sentinel.

Como parte del proceso de instalación, cree una regla de recopilación de datos e instale el agente de Azure Monitor (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 Microsoft Sentinel en el portal de Azure o Microsoft Defender, puede crear, administrar y eliminar DCR por área de trabajo. El AMA se instalará 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 ingestión de registros. Con esta configuración, puede crear, administrar y eliminar varios controladores de dominio. Esta opción es más flexible que el portal. Por ejemplo, puede filtrar por niveles de registro específicos con la API. En el portal de Azure o Defender solo puede seleccionar un nivel de registro mínimo. El inconveniente de utilizar 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 el DCR y instalar el AMA, ejecute el script de "instalación" en el reenviador de registros. Este script configura el demonio de Syslog para escuchar mensajes de otras máquinas y para abrir los puertos locales necesarios. A continuación, configure los dispositivos de seguridad O dispositivos según sea necesario.

Vea los siguientes artículos para más información:

Prevención de la duplicación de ingesta de datos

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

Para evitar esta situación, usa uno de estos métodos:

  • Si el dispositivo de origen permite 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, edita el archivo de configuración de Syslog para eliminar las instalaciones utilizadas y así 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 utilice la función correspondiente para CEF o Syslog, respectivamente.

    Para ver un ejemplo de cómo organizar un DCR para ingerir mensajes Syslog y CEF desde el mismo agente, vaya a Flujos Syslog y CEF en el mismo DCR.

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

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

Pasos siguientes

Configuración de los conectores de datos