Solución de problemas de CEF y Syslog a través de conectores AMA

En este artículo se proporcionan instrucciones de solución de problemas para common event format (CEF) y recopilación de datos de Syslog mediante el agente de supervisión de Azure (AMA) en Microsoft Sentinel. Use esta guía para diagnosticar y resolver problemas de ingesta con las máquinas de reenvío de registros. Los comandos y configuraciones deben ejecutarse en las máquinas del reenviador de registros donde están instalados AMA y RSyslog/Syslog-ng.

Antes de empezar a solucionar problemas, familiarícese con los siguientes artículos:

Introducción a la arquitectura

El siguiente diagrama ilustra el flujo de datos desde las fuentes de registro hasta los espacios de trabajo de Microsoft Sentinel o de Log Analytics a través de RSyslog y Azure Monitor Agent.

Diagrama que muestra el flujo de datos desde el origen a Log Analytics a través de RSyslog y AMA.

Componentes clave:

  • RSyslog/Syslog-ng: recibe los registros en el puerto 514 y los reenvía a AMA.
  • agente de Azure Monitor: procesa los registros según las reglas de recopilación de datos (DCR)
  • Regla de recopilación de datos: define qué registros se van a recopilar y dónde enviarlos

Pasos de comprobación iniciales

Verificar que se estén recibiendo los registros

Los registros pueden tardar hasta 20 minutos en aparecer en Microsoft Sentinel después de la configuración.

  1. Ejecute tcpdump para comprobar que los registros llegan al reenviador:

    sudo tcpdump -i any port 514 -A -vv

  2. Compruebe que el origen de registro está configurado para enviar mensajes a la dirección IP correcta del reenviador.

  3. Compruebe si hay componentes de infraestructura que puedan afectar a la conectividad:

    • Cortafuegos
    • Equilibradores de carga
    • Grupos de seguridad de red

Comprobación del estado de la extensión del agente de Azure Monitor

  1. En Azure Portal, vaya a la máquina virtual del reenviador de registros.
  2. Seleccione Extensiones y aplicaciones.
  3. Seleccione la extensión AzureMonitorLinuxAgent .
  4. Compruebe que Estado muestra El aprovisionamiento se realizó correctamente.

Comprueba la versión del agente

  1. En la hoja de extensión AzureMonitorLinuxAgent , compruebe el campo Versión .
  2. Asegúrese de que la versión sea una de las 2 o 3 más recientes. Consulte los detalles de la versión de AMA para obtener las versiones más recientes.

Nota:

Las nuevas versiones pueden tardar hasta 5 semanas en implementarse después del lanzamiento inicial.

Solución de problemas de nivel de agente

Asegúrate de que el agente y los servicios RSyslog estén en ejecución.

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

Comprobación de la configuración de RSyslog

La configuración de RSyslog consta de /etc/rsyslog.conf y de archivos en /etc/rsyslog.d/.

  1. Compruebe la configuración del puerto:

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

    Salida esperada:

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

  2. Compruebe que existe la configuración de reenvío de AMA:

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

    El archivo debe empezar por:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Comprobación del estado del puerto

Compruebe que los puertos necesarios están escuchando:

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

Salida esperada:

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

Esto confirma lo siguiente:

  • RSyslog está escuchando en el puerto 514 (TCP y UDP)
  • MDSD (componente AMA) está escuchando en el puerto 28330 (TCP)

Comprobación de la configuración de la regla de recopilación de datos

Compruebe si el DCR está configurado correctamente en el agente.

Para los registros CEF:

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

Para los registros de Cisco ASA:

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

La salida debe mostrar una cadena JSON que contenga la configuración de DCR.

Revisión de las reglas de firewall

Asegúrese de que las reglas de firewall permiten la comunicación entre:

  • Origen del registro y RSyslog (puerto 514)
  • RSyslog y AMA (puerto 28330)
  • Puntos de conexión de AMA y Azure

Configuración de la regla de recopilación de datos

Habilitación de todas las instalaciones para la solución de problemas

Para la solución de problemas inicial:

  1. En el Azure Portal, vaya a la regla de recopilación de datos.
  2. Habilite todas las instalaciones de Syslog.
  3. Seleccione todos los niveles de registro.
  4. Si está disponible, habilite la recopilación de mensajes sin instalación ni gravedad.

Para obtener más información, consulte Seleccionar instalaciones y gravedades.

Validación del formato de evento común (CEF)

Requisitos de formato CEF

CEF usa Syslog como mecanismo de transporte con esta estructura:

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

Ejemplo:

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 comunes de formato CEF

Formato de encabezado incorrecto

  • Asegúrese de que la versión de CEF está presente: CEF:0|
  • Todos los campos de encabezado deben estar presentes y delimitados por caracteres de canalización (|)

Secuencia de escape de caracteres incorrecta

  • Los caracteres de canalización (|) en los valores de encabezado deben tener escape: \|
  • Las barras diagonales inversas () deben tener escape: \\
  • Los signos de igual (=) en las extensiones deben tener escape: \=

Valores que faltan o no están asignados

Para obtener la especificación completa de CEF, busque la documentación "Implementing ArcSight Common Event Format (CEF)".

Solución de problemas avanzada

Habilitación del seguimiento de diagnóstico

Advertencia

Habilite las marcas de seguimiento solo para las sesiones de solución de problemas. Las marcas de seguimiento generan un registro extenso que puede rellenar el espacio en disco rápidamente.

  1. Edite el archivo de configuración de AMA:

    sudo vim /etc/default/azuremonitoragent

  2. Agregue marcas de seguimiento a la línea 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 el agente:

    sudo systemctl restart azuremonitoragent

  4. Reproduzca el problema y espere unos minutos.

  5. Revise la información de depuración en /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Quite el indicador de seguimiento y reinicie el agente después de completar la solución de problemas.

Supervisión del procesamiento de registros en tiempo real

Vea los registros entrantes a medida que se procesan:

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

Filtre por tipos de registro específicos:

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

Revisar registros específicos de instalaciones:

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

Comprobación del procesamiento de registros correcto

Cuando se habilitan las marcas de seguimiento, puede comprobar que los registros se están procesando correctamente analizando la salida de depuración.

Ejemplo de ingestión de registros de ASA

Para los registros de Cisco ASA, el procesamiento correcto aparece en los registros 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 clave del procesamiento correcto:

  • El evento se reconoce como un evento CiscoASA
  • El registro se carga en ODS (Operations Data Service)
  • Se genera un identificador de solicitud para el seguimiento
  • La carga contiene datos JSON con formato correcto

Ejemplo de ingesta de registros CEF

En el caso de los registros CEF, el procesamiento correcto aparece 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 clave del procesamiento correcto de CEF:

  • El tipo de datos es SECURITY_CEF_BLOB
  • La solicitud de carga incluye un punto de conexión válido
  • La estructura del mensaje CEF se conserva en la carga.
  • Las métricas de compresión muestran que los datos se están optimizando para la transferencia

Importante

Recuerde deshabilitar las marcas de seguimiento después de completar la investigación para evitar un uso excesivo del disco.

Recopilación de información de diagnóstico

Antes de abrir un caso de soporte técnico, recopile la siguiente información:

Ejecución del solucionador de problemas de AMA

El script se puede ejecutar con marcas específicas para diferentes tipos de registro.

  • --cef: Para registros en formato Common Event Format
  • --asa: Para los registros de Cisco ASA
  • --ftd: Para los registros de Cisco Firepower Threat Defense

La salida se guarda en /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]

Contenido relacionado

  • Last updated on