[En desuso] Solución de problemas del conector de datos CEF o Syslog
Importante
La recopilación de registros de muchos dispositivos y dispositivos ahora es compatible con el formato de evento común (CEF) a través de AMA, Syslog a través de AMA o registros personalizados a través del conector de datos AMA en Microsoft Sentinel. Para más información, consulte Búsqueda del conector de datos de Microsoft Sentinel.
Precaución
Este artículo hace referencia a CentOS, una distribución de Linux que ha alcanzado el estado de finalización del servicio (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 sus mensajes de registro no aparecen en las tablas Syslog o CommonSecurityLog, es posible que su origen de datos no se esté conectando correctamente. También puede haber otra razón por la que no se reciban sus 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 su conector usando un método diferente al procedimiento documentado, y si está teniendo problemas, le recomendamos que deseche la implementación y vuelva a empezar, esta vez siguiendo las instrucciones documentadas.
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 es relevante solo para Syslog o solo para los conectores CEF, se presenta en pestañas separadas. 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 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.
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.
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.
Si no ve ningún resultado de la consulta, compruebe que la solución de seguridad está generando mensajes de registro. O bien, intente llevar a cabo algunas acciones para generar mensajes de registro y verifique que los mensajes se reenvían a su máquina reenviadora de Syslog designada.
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:
Comprueba que el archivo
/etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
existe y es válido.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>
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 garantiza que el análisis se realice correctamente y reinicia 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]
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 garantiza la asignación correcta y reinicia 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]
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).
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
Reinicia el demonio de syslog y el agente de Log Analytics:
service rsyslog restart /opt/microsoft/omsagent/bin/service_control restart [workspaceID]
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
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
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:
Comprueba que el archivo
/etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
existe y es válido.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>
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 garantiza que el análisis se realice correctamente y reinicia 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]
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 garantiza la asignación correcta y reinicia 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]
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).
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);};
Reinicia el demonio de syslog y el agente de Log Analytics:
service syslog-ng restart /opt/microsoft/omsagent/bin/service_control restart [workspaceID]
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
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
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:
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.
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.
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
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
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.
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 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.
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 enpermissive
.
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.
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.
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
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
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.
Para instalar el editor de directivas de firewall, ejecute:
yum install policycoreutils-python
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
Verifique que se haya agregado la excepción. Ejecute:
sudo firewall-cmd --direct --get-rules ipv4 filter INPUT
Vuelva a cargar el firewall. Ejecute:
sudo firewall-cmd --reload
Nota
Para deshabilitar el firewall, ejecute: sudo systemctl disable firewalld
Problemas relacionados con el agente de Linux y OMS
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.