Compartir vía

Solución de problemas del conector de datos CEF o Syslog

  • Artículo

Precaución

En este artículo se hace referencia a CentOS, una distribución de Linux que está cerca de su estado Final de ciclo vida (EOL). Tenga en cuenta su uso y planeación en consecuencia. Para más información, consulte la Guía de fin de ciclo de vida de CentOS.

En este artículo se describen los métodos comunes para verificar y solucionar problemas de un conector de datos CEF o Syslog para Microsoft Sentinel.

Por ejemplo, si los registros no aparecen en Microsoft Sentinel, ya sea en las tablas de Syslog o Common Security Log, es posible que el origen de datos no se pueda conectar o que haya otro motivo por el que no se ingieren los datos.

Otros síntomas de una implementación de conector con errores incluyen cuando faltan los archivos security_events.conf o security-omsagent.config.conf, o bien si el servidor rsyslog no realiza la escucha en el puerto 514.

Para obtener más información, consulte Conexión de la solución externa con el formato de evento común y Colección de datos de orígenes basados en Linux con Syslog.

Si ha implementado el conector mediante un método diferente al procedimiento documentado y tiene problemas, le recomendamos purgar la implementación e instalarla de nuevo como se documenta.

En este artículo se muestra cómo solucionar problemas de conectores CEF o Syslog con el agente de Log Analytics. Para obtener información sobre la solución de problemas relacionados con la ingesta de registros CEF mediante el agente de Azure Monitor (AMA), consulte las instrucciones del formato de evento común (CEF) mediante el conector AMA.

Importante

El 28 de febrero de 2023 introdujimos cambios en el esquema de la tabla CommonSecurityLog. Después de este cambio, es posible que tenga que revisar y actualizar consultas personalizadas. Para obtener más información, consulte la sección de acciones recomendadas en esta entrada de blog. Microsoft Sentinel ha actualizado el contenido preconfigurado (detecciones, consultas de búsqueda, libros, analizadores, etc.).

Cómo usar este artículo

Cuando la información de este artículo solo es pertinente para Syslog o solo para conectores CEF, hemos organizado la página en pestañas. Asegúrese de seguir las instrucciones de la pestaña correcta para el tipo de conector correspondiente.

Por ejemplo, si está solucionando problemas de un conector CEF, comience con Validación de la conectividad CEF. Si está solucionando problemas de un conector Syslog, comience más adelante con Validación de los requisitos previos del conector de datos.

Validación de la conectividad CEF

Una vez que haya implementado el reenviador de registros y configurado la solución de seguridad para enviarle mensajes CEF, siga los pasos de esta sección para verificar la conectividad entre la solución de seguridad y Microsoft Sentinel.

Este procedimiento solo es pertinente para las conexiones CEF y no para las conexiones de Syslog.

  1. Asegúrese de que cumple los siguientes requisitos previos:

    • Debe tener permisos elevados (sudo) en la máquina del reenviador de registros.

    • Debe tener instalado Python 2.7 o 3 en la máquina de reenvío de registros. Use el comando python --version para comprobarlo.

    • En algún momento del proceso, es posible que necesite el id. del área de trabajo y la clave principal del área de trabajo. Puede encontrarlos en el recurso del área de trabajo, en Administración de agentes.

  2. En el menú de navegación de Microsoft Sentinel, abra Registros. Ejecute una consulta con el esquema CommonSecurityLog para ver si recibe registros de la solución de seguridad.

    Los registros pueden tardar hasta 20 minutos en empezar a aparecer en Log Analytics.

  3. Si no ve ningún resultado de la consulta, compruebe que se generan eventos en la solución de seguridad o intente generar algunos, y compruebe que se reenvían a la máquina del reenviador de Syslog que ha designado.

  4. Ejecute el siguiente script en el reenviador de registros (aplicando el id. del área de trabajo en lugar del marcador de posición) para comprobar la conectividad entre la solución de seguridad, el reenviador de registros y Microsoft Sentinel. Este script comprueba que el demonio escucha en los puertos correctos, que el reenvío del demonio está configurado correctamente y que nada bloquee la comunicación entre el demonio y el agente de Log Analytics. También envía mensajes ficticios "TestCommonEventFormat" para comprobar la conectividad de un extremo a otro. 

    sudo wget -O cef_troubleshoot.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_troubleshoot.py&&sudo python cef_troubleshoot.py [WorkspaceID]

    • Es posible que reciba un mensaje que le indique que debe ejecutar un comando para corregir un problema con la asignación del campo Equipo. Consulte la explicación en el script de validación para obtener más detalles.

    • Es posible que reciba un mensaje que le indique que debe ejecutar un comando para corregir un problema con el análisis de los registros de firewall de Cisco ASA. Consulte la explicación en el script de validación para obtener más detalles.

Descripción del script de validación de CEF

En la sección siguiente se describe el script de validación de CEF para el demonio rsyslog y el demonio syslog-ng.

demonio rsyslog

Para un demonio rsyslog, el script de validación de CEF ejecuta las siguientes comprobaciones:

  1. Comprueba que el archivo
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    existe y es válido.

  2. Comprueba que el archivo incluye el texto siguiente:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. Comprueba que el análisis de los eventos del firewall de Cisco ASA esté configurado según lo previsto, con el siguiente comando:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • Si hay un problema con el análisis, el script generará un mensaje de error que le indicará que debe ejecutar manualmente el siguiente comando (debe agregar el id. del área de trabajo en lugar del marcador de posición). El comando garantizará que el análisis se realice correctamente y reiniciará el agente.

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. Comprueba que el campo Equipo del origen de syslog se haya asignado correctamente en el agente de Log Analytics, mediante el siguiente comando:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • Si hay un problema con la asignación, el script generará un mensaje de error que le indicará que debe ejecutar manualmente el siguiente comando (debe agregar el id. del área de trabajo en lugar del marcador de posición). El comando garantizará que la asignación se realice correctamente y reiniciará el agente.

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. Comprueba si hay mejoras de seguridad en el equipo que podrían estar bloqueando el tráfico de red (por ejemplo, un firewall de host).

  6. Comprueba que el demonio de syslog (rsyslog) esté configurado correctamente para enviar mensajes (que identifica como CEF) al agente de Log Analytics en el puerto TCP 25226:

    Archivo de configuración: /etc/rsyslog.d/security-config-omsagent.conf

    if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

  7. Reinicia el demonio de syslog y el agente de Log Analytics:

    service rsyslog restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. Comprueba que se han establecido las conexiones necesarias: TCP 514 para recibir datos, TCP 25226 para la comunicación interna entre el demonio de syslog y el agente de Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Comprueba que el demonio de syslog recibe datos en el puerto 514 y que el agente recibe datos en el puerto 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Envía datos ficticios al puerto 514 en localhost. Estos datos deben poderse observar en el área de trabajo de Microsoft Sentinel ejecutando la siguiente consulta:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

demonio syslog-ng

Para un demonio syslog-ng, el script de validación de CEF ejecuta las siguientes comprobaciones:

  1. Comprueba que el archivo
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    existe y es válido.

  2. Comprueba que el archivo incluye el texto siguiente:

    <source>
    type syslog
    port 25226
    bind 127.0.0.1
    protocol_type tcp
    tag oms.security
    format /(?<time>(?:\w+ +){2,3}(?:\d+:){2}\d+|\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.[\w\-\:\+]{3,12}):?\s*(?:(?<host>[^: ]+) ?:?)?\s*(?<ident>.*CEF.+?(?=0\|)|%ASA[0-9\-]{8,10})\s*:?(?<message>0\|.*|.*)/
    <parse>
        message_format auto
    </parse>
</source>

<filter oms.security.**>
    type filter_syslog_security
</filter>

  3. Comprueba que el análisis de los eventos del firewall de Cisco ASA esté configurado según lo previsto, con el siguiente comando:

    grep -i "return ident if ident.include?('%ASA')" /opt/microsoft/omsagent/plugin/security_lib.rb

    • Si hay un problema con el análisis, el script generará un mensaje de error que le indicará que debe ejecutar manualmente el siguiente comando (debe agregar el id. del área de trabajo en lugar del marcador de posición). El comando garantizará que el análisis se realice correctamente y reiniciará el agente.

      # Cisco ASA parsing fix
sed -i "s|return '%ASA' if ident.include?('%ASA')|return ident if ident.include?('%ASA')|g" /opt/microsoft/omsagent/plugin/security_lib.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  4. Comprueba que el campo Equipo del origen de syslog se haya asignado correctamente en el agente de Log Analytics, mediante el siguiente comando:

    grep -i "'Host' => record\['host'\]"  /opt/microsoft/omsagent/plugin/filter_syslog_security.rb

    • Si hay un problema con la asignación, el script generará un mensaje de error que le indicará que debe ejecutar manualmente el siguiente comando (debe agregar el id. del área de trabajo en lugar del marcador de posición). El comando garantizará que la asignación se realice correctamente y reiniciará el agente.

      # Computer field mapping fix
sed -i -e "/'Severity' => tags\[tags.size - 1\]/ a \ \t 'Host' => record['host']" -e "s/'Severity' => tags\[tags.size - 1\]/&,/" /opt/microsoft/omsagent/plugin/filter_syslog_security.rb && sudo /opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  5. Comprueba si hay mejoras de seguridad en el equipo que podrían estar bloqueando el tráfico de red (por ejemplo, un firewall de host).

  6. Comprueba que el demonio de syslog (syslog-ng) esté configurado correctamente para enviar mensajes que identifica como CEF (mediante regex) al agente de Log Analytics en el puerto TCP 25226:

    • Archivo de configuración: /etc/syslog-ng/conf.d/security-config-omsagent.conf

      filter f_oms_filter {match(\"CEF\|ASA\" ) ;};destination oms_destination {tcp(\"127.0.0.1\" port(25226));};
log {source(s_src);filter(f_oms_filter);destination(oms_destination);};

  7. Reinicia el demonio de syslog y el agente de Log Analytics:

    service syslog-ng restart

/opt/microsoft/omsagent/bin/service_control restart [workspaceID]

  8. Comprueba que se han establecido las conexiones necesarias: TCP 514 para recibir datos, TCP 25226 para la comunicación interna entre el demonio de syslog y el agente de Log Analytics:

    netstat -an | grep 514

netstat -an | grep 25226

  9. Comprueba que el demonio de syslog recibe datos en el puerto 514 y que el agente recibe datos en el puerto 25226:

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Envía datos ficticios al puerto 514 en localhost. Estos datos deben poderse observar en el área de trabajo de Microsoft Sentinel ejecutando la siguiente consulta:

    CommonSecurityLog
| where DeviceProduct == "MOCK"

Validación de los requisitos previos del conector de datos

Use las secciones siguientes para comprobar los requisitos previos del conector de datos CEF o Syslog.

Máquina virtual de Azure como recopilador de CEF

Si usa una máquina virtual de Azure como recopilador de CEF, verifique lo siguiente:

  • Antes de implementar el script de Python del conector de datos de formato de evento común, asegúrese de que la máquina virtual no esté conectada a un área de trabajo de Log Analytics existente. Puede encontrar esta información en la lista de máquinas virtuales del área de trabajo de Log Analytics, en la que una máquina virtual conectada a un área de trabajo de Syslog se muestra como Conectada.

  • Asegúrese de que Microsoft Sentinel esté conectado al área de trabajo de Log Analytics correcta, con la solución SecurityInsights instalada.

    Para obtener más información, vea Paso 1: Implementar el reenviador de registros.

  • Asegúrese de que el tamaño de la máquina sea correcto con al menos los requisitos previos mínimos necesarios. Para obtener más información, consulte la sección Requisitos previos de CEF.

Una máquina virtual local o que no es de Azure

Si usa una máquina local o una máquina virtual que no es de Azure para el conector de datos, asegúrese de que ha ejecutado el script de instalación en una instalación nueva de un sistema operativo Linux compatible:

Sugerencia

También puede encontrar este script en la página del conector de datos de formato de evento común en Microsoft Sentinel.

sudo wget -O cef_installer.py https://raw.githubusercontent.com/Azure/Azure-Sentinel/master/DataConnectors/CEF/cef_installer.py&&sudo python cef_installer.py <WorkspaceId> <Primary Key>

Habilitación de la instalación de CEF y la recopilación del registro de gravedad

El servidor de Syslog, rsyslog o syslog-ng, reenvía los datos definidos en el archivo de configuración correspondiente, que se rellena automáticamente con la configuración definida en el área de trabajo de Log Analytics.

Asegúrese de agregar detalles sobre las instalaciones y los niveles de registro de gravedad que quiere ingerir en Microsoft Sentinel. El proceso de configuración puede tardar unos 20 minutos en procesarse.

Para obtener más información, consulte Explicación del script de implementación.

Por ejemplo, para un servidor rsyslog, ejecute el siguiente comando para mostrar la configuración actual del reenvío de Syslog y revise los cambios en el archivo de configuración:

cat /etc/rsyslog.d/security-config-omsagent.conf

En este caso, para rsyslog, debería mostrarse una salida similar a la siguiente:

if $rawmsg contains "CEF:" or $rawmsg contains "ASA-" then @@127.0.0.1:25226

Solución de problemas del sistema operativo

En esta sección se describe cómo solucionar problemas que seguramente provienen de la configuración del sistema operativo.

Para solucionar problemas del sistema operativo:

  1. Si aún no lo ha hecho, compruebe que está trabajando con un sistema operativo compatible y una versión de Python. Para obtener más información, consulte la sección Requisitos previos de CEF.

  2. Si la máquina virtual está en Azure, verifique que el grupo de seguridad de red (NSG) permite la conectividad TCP/UDP entrante desde el cliente de registro (remitente) en el puerto 514.

  3. Verifique que los paquetes llegan al recopilador de Syslog. Para capturar los paquetes de Syslog que llegan al recopilador de Syslog, ejecute:

    tcpdump -Ani any port 514 and host <ip_address_of_sender> -vv

  4. Realice una de las siguientes acciones:

    • Si ve que no llega ningún paquete, confirme los permisos del grupo de seguridad de NSG y la ruta de acceso de enrutamiento al recopilador de Syslog.

    • Si ve que llegan paquetes, confirme que no se rechazan.

    Si ve paquetes rechazados, confirme que las tablas IP no bloquean las conexiones.

    Para confirmar que los paquetes no se rechazan, ejecute:

    watch -n 2 -d iptables -nvL

  5. Compruebe si el servidor de CEF procesa los registros. Ejecute:

    tail -f /var/log/messages or tail -f /var/log/syslog

    Los registros de CEF que se procesan se muestran en texto sin formato.

  6. Confirme que el servidor rsyslog realiza escuchas en el puerto TCP/UDP 514. Ejecute:

    netstat -anp | grep syslog

    Si tiene algún registro CEF o ASA que se envía al recopilador de Syslog, debería ver una conexión establecida en el puerto TCP 25226.

    Por ejemplo:

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    Si la conexión está bloqueada, es posible que tenga una conexión SELinux bloqueada al agente de OMS o un proceso de firewall bloqueado. Siga las instrucciones pertinentes a continuación para determinar el problema.

SELinux bloquea la conexión al agente de OMS

En este procedimiento se describe cómo se debe confirmar si SELinux actualmente está en un estado permissive o está bloqueando una conexión al agente de OMS. Este procedimiento es pertinente cuando el sistema operativo es una distribución de RedHat o CentOS, y para los conectores de datos de CEF y Syslog.

Nota

La compatibilidad de Microsoft Sentinel con CEF y Syslog solo incluye el sistema de protección de FIPS. Actualmente no se admiten otros métodos de protección, como SELinux o CIS.

  1. Ejecute:

    sestatus

    El estado se muestra como uno de los siguientes:

    • disabled. Esta configuración es compatible con su conexión a Microsoft Sentinel.
    • permissive. Esta configuración es compatible con su conexión a Microsoft Sentinel.
    • enforced. Esta configuración no se admite y debe deshabilitar el estado o establecerlo en permissive.

  2. Si el estado actualmente está establecido en enforced, deshabilítelo temporalmente para confirmar si se trata del bloqueador. Ejecute:

    setenforce 0

    Nota

    Este paso desactiva SELinux solo hasta que se reinicie el servidor. Modifique la configuración de SELinux para mantenerla desactivada.

  3. Para verificar si el cambio se ha realizado correctamente, ejecute:

    getenforce

    Debe devolverse el estado permissive.

Importante

Esta actualización de configuración se pierde cuando se reinicia el sistema. Para actualizar permanentemente esta configuración a permissive, cambie el valor SELINUX a SELINUX=permissive del archivo /etc/selinux/config.

Para obtener más información, vea la documentación de RedHat.

Directiva de firewall bloqueada

En este procedimiento se describe cómo comprobar si una directiva de firewall bloquea la conexión desde el demonio Rsyslog al agente de OMS y cómo deshabilitarla según sea necesario. Este procedimiento es relevante para los conectores de datos tanto de CEF como de Syslog.

  1. Ejecute el siguiente comando para verificar si hay rechazos en las tablas IP, lo que indica el tráfico que descarta la directiva de firewall:

    watch -n 2 -d iptables -nvL

  2. Para mantener habilitada la directiva de firewall, cree una regla de directiva para permitir las conexiones. Agregue reglas según sea necesario para permitir los puertos TCP/UDP 25226 y 25224 a través del firewall activo.

    Por ejemplo:

    Every 2.0s: iptables -nvL                      rsyslog: Wed Jul  7 15:56:13 2021

Chain INPUT (policy ACCEPT 6185K packets, 2466M bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination


Chain OUTPUT (policy ACCEPT 6792K packets, 6348M bytes)
 pkts bytes target     prot opt in     out     source               destination

  3. Para crear una regla que permita los puertos TCP/UDP 25226 y 25224 a través del firewall activo, agregue reglas según sea necesario.

    1. Para instalar el editor de directivas de firewall, ejecute:

      yum install policycoreutils-python

    2. Agregue las reglas de firewall a la directiva de firewall. Por ejemplo:

      sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25226  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p udp --dport 25224  -j ACCEPT
sudo firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 25224  -j ACCEPT

    3. Verifique que se haya agregado la excepción. Ejecute:

      sudo firewall-cmd --direct --get-rules ipv4 filter INPUT

    4. Vuelva a cargar el firewall. Ejecute:

      sudo firewall-cmd --reload

Nota

Para deshabilitar el firewall, ejecute: sudo systemctl disable firewalld

Si los pasos descritos anteriormente en este artículo no solucionan el problema, es posible que tenga un problema de conectividad entre el agente de OMS y el área de trabajo de Microsoft Sentinel.

En tales casos, siga solucionando problemas y verifique lo siguiente:

  • Asegúrese de que puede ver los paquetes que llegan al puerto TCP/UDP 514 en el recopilador de Syslog.

  • Asegúrese de que puede ver los registros que se escriben en el archivo de registro local, ya sea /var/log/messages o /var/log/syslog

  • Asegúrese de que puede ver los paquetes de datos que fluyen en el puerto 25226.

  • Asegúrese de que la máquina virtual tiene una conexión saliente al puerto 443 a través de TCP, o de que puede conectarse a los puntos de conexión de Log Analytics.

  • Asegúrese de que tiene acceso a las direcciones URL necesarias del recopilador de CEF a través de la directiva de firewall. Para obtener más información, consulte Requisitos del firewall del agente de Log Analytics.

Ejecute el siguiente comando para determinar si el agente se comunica correctamente con Azure o si el agente de OMS tiene bloqueada la conexión al área de trabajo de Log Analytics.

Heartbeat
 | where Computer contains "<computername>"
 | sort by TimeGenerated desc

Se devuelve una entrada de registro si el agente se comunica correctamente. De lo contrario, es posible que se bloquee el agente de OMS.

Pasos siguientes

Si los pasos de solución de problemas de este artículo no le han ayudado a solucionar su problema, abra una incidencia de soporte técnico o use los recursos de la comunidad de Microsoft Sentinel. Para obtener más información, consulte Recursos útiles al trabajar con Microsoft Sentinel.

Para obtener más información sobre Microsoft Sentinel, consulte los siguientes artículos: