Compartir a través de

Solución de problemas de CEF y Syslog mediante conectores AMA

En este artículo se proporcionan instrucciones para la solución de problemas en la recopilación de datos utilizando el Formato de Eventos Comunes (CEF) y Syslog mediante el agente de Azure Monitor (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

En el siguiente diagrama se ilustra el flujo de datos desde los orígenes de registro hacia Microsoft Sentinel y las áreas de trabajo de análisis de registros a través de RSyslog y el agente de Azure Monitor.

Diagrama que muestra el flujo de datos de origen a Log Analytics mediante RSyslog y AMA.

Componentes clave:

  • RSyslog/Syslog-ng: recibe 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 los registros que se van a recopilar y dónde enviarlos.

Pasos de comprobación iniciales

Comprobación de que se reciben 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 del 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:

    • Firewalls
    • 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 El estado muestra que el aprovisionamiento se ha realizado correctamente.

Verificar versión del agente

  1. En el panel de extensión AzureMonitorLinuxAgent, compruebe el campo Versión.
  2. Asegúrese de que la versión es 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 de la versión inicial.

Solución de problemas de nivel de agente

Asegúrese de que el servicio del agente y RSyslog estén en funcionamiento.

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 archivos en /etc/rsyslog.d/.

  1. Compruebe la configuración del puerto:

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

    Resultado esperado:

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

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

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

    El archivo debe comenzar con:

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Comprobación del estado del puerto

Compruebe que los puertos necesarios están en estado de escucha:

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

Resultado esperado:

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:

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

Verifique la configuración de reglas 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 de registro y RSyslog (puerto 514)
  • RSyslog y AMA (puerto 28330)
  • AMA y puntos de conexión de 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 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 severidades.

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 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 CEF completa, busque la documentación "Implementación del formato de evento común (CEF)" de ArcSight.

Pasos detallados para solucionar problemas de conexión a Escritorio remoto a máquinas virtuales Windows en Azure

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 rápidamente el espacio en disco.

  1. Edite el archivo de configuración ama:

    sudo vim /etc/default/azuremonitoragent

  2. Agregue marcas de seguimiento a la línea 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 la marca de seguimiento y reinicie el agente después de solucionar 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"

Revise los registros específicos de las instalaciones:

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

Comprobación del procesamiento correcto del registro

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 procesamiento 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 el formato correcto.

Ejemplo de ingestión de registros CEF

Para los registros CEF, el procesamiento exitoso 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 CEF correcto:

  • 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:

Ejecutar el solucionador de problemas AMA

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

  • --cef: para los registros de formato de evento común
  • --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