[Déconseillé] Résoudre les problèmes liés à votre connecteur de données CEF ou Syslog

  • Article

Important

La collecte de journaux dans un grand nombre d’appliances et d’appareils est désormais prise en charge par le CEF (Common Event Format) via AMA, Syslog via AMA ou les journaux personnalisés via le connecteur de données AMA dans Microsoft Sentinel. Pour plus d’informations, consultez Rechercher votre connecteur de données Microsoft Sentinel.

Attention

Cet article fait référence à CentOS, une distribution Linux qui a atteint l’état EOL (fin du service). Veuillez considérer votre utilisation et votre planification en conséquence. Pour plus d’informations, consultez l’aide relative à la fin de vie de CentOS.

Cet article décrit les méthodes courantes de vérification et de dépannage d’un connecteur de données CEF ou Syslog pour Microsoft Sentinel.

Par exemple, si vos messages de journal ne s’affichent pas dans les tables Syslog ou CommonSecurityLog, votre source de données risque de ne pas se connecter correctement. Il peut également y avoir une autre raison pour laquelle vos données ne sont pas reçues.

D’autres symptômes d’un déploiement de connecteur défaillant inclus soit l’absence des fichiers security_events.conf ou security-omsagent.config.conf, soit l’absence de réponse du serveur rsyslog sur le port 514.

Pour plus d’informations, consultez Connecter votre solution externe à l’aide du Format d’évènement commun CEF et Collecter des données à partir des sources Linux à l’aide de Syslog.

Si vous avez déployé votre connecteur à l’aide d’une méthode différente de la procédure documentée, et si vous rencontrez des problèmes, nous vous recommandons de supprimer le déploiement et de recommencer, cette fois en suivant les instructions documentées.

Cet article explique comment résoudre les problèmes liés aux connecteurs CEF ou Syslog avec l’agent Log Analytics. Pour plus d’informations sur la résolution des problèmes liés à l’ingestion de journaux CEF par l’agent Azure Monitor (AMA), consultez les instructions CEF (Common Event Format) par le connecteur AMA.

Important

Le 28 février 2023, nous avons introduit des modifications dans le schéma de table CommonSecurityLog. En conséquence de cette modification, vous devrez peut-être passer en revue et mettre à jour les requêtes personnalisées. Pour plus d’informations, consultez la section actions recommandées dans ce billet de blog. Du contenu prêt à l’emploi (détections, requêtes de chasse, classeurs, analyseurs, etc.) a été mis à jour par Microsoft Sentinel.

Utilisation de cet article

Pour les informations de cet article s’appliquant uniquement à Syslog ou uniquement aux connecteurs CEF, elles sont présentées dans des onglets distincts. Assurez-vous que vous utilisez les instructions sur l’onglet qui correspond à votre type de connecteur.

Par exemple, si vous dépannez un connecteur CEF, commencez par Valider la connectivité CEF. Si vous dépannez un connecteur Syslog, commencez par Vérifier les prérequis de votre connecteur de données.

Valider la connectivité CEF

Après avoir déployé votre redirecteur de journal et configuré votre solution de sécurité pour lui envoyer des messages CEF, suivez les étapes dans cette section afin de vérifier la connectivité entre votre solution de sécurité et Microsoft Sentinel.

Cette procédure s’applique uniquement aux connexions CEF et n’est pas pertinente pour les connexions Syslog.

  1. Assurez-vous que vous disposez des prérequis suivants :

    • Vous devez disposer d’autorisations élevées (sudo) sur votre machine de transfert de journaux.

    • Python 2.7 ou 3 doit être installé sur votre machine de transfert de journaux. Utilisez la commande python --version pour vérifier.

    • Vous pouvez avoir besoin de l’ID et de la clé primaire de l’espace de travail à un moment donné dans ce processus. Vous pouvez les trouver dans la ressource d’espace de travail, sous Gestion des agents.

  2. Dans le menu de navigation de Microsoft Sentinel, ouvrez Journaux. Exécutez une requête à l’aide du schéma CommonSecurityLog pour voir si vous recevez les journaux de votre solution de sécurité.

    Jusqu’à 20 minutes peuvent être nécessaires avant que vos journaux ne commencent à apparaître dans Log Analytics.

  3. Si vous ne voyez aucun résultat de la requête, vérifiez que votre solution de sécurité génère des messages de journal. Ou essayez d’effectuer certaines actions pour générer des messages de journal et vérifiez que les messages sont transférés vers votre machine de redirecteur Syslog désignée.

  4. Pour vérifier la connectivité entre votre solution de sécurité, le redirecteur de journal et Microsoft Sentinel, exécutez le script suivant sur le redirecteur de journal (en appliquant l’ID d’espace de travail à la place de l’espace réservé). Ce script vérifie que le démon écoute les ports appropriés, que le transfert est correctement configuré, et s’assure que rien ne bloque la communication entre le démon et l’agent Log Analytics. Il envoie également des messages fictifs « TestCommonEventFormat » pour vérifier la connectivité de bout en bout. 

    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]

    • Vous pouvez recevoir un message vous indiquant d’exécuter une commande pour corriger un problème avec le mappage du champ Ordinateur. Pour plus d’informations, consultez l’explication dans le script de validation.

    • Vous pouvez recevoir un message vous demandant d’exécuter une commande pour corriger un problème d’analyse de journaux de pare-feu Cisco ASA. Pour plus d’informations, consultez l’explication dans le script de validation.

Explication du script de validation CEF

La section suivante décrit le script de validation CEF pour le démon rsyslog et le démon syslog-ng.

rsyslog daemon

Pour un démon rsyslog, le script de validation CEF exécute les vérifications suivantes :

  1. Vérifie que le fichier
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    existe et est valide.

  2. Vérifie que le fichier contient le texte suivant :

    <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. Vérifie que l’analyse des événements de pare-feu Cisco ASA est configurée comme prévu à l’aide de la commande suivante :

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

    • En cas de problème avec l’analyse, le script génère un message d’erreur qui vous indique d’exécuter manuellement la commande suivante (en appliquant l’ID de l’espace de travail à la place de l’espace réservé). La commande garantit l’analyse correcte et redémarre l’agent.

      # 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. Vérifie que le champ Ordinateur de la source syslog est correctement mappé dans l’agent Log Analytics en utilisant la commande suivante :

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

    • En cas de problème avec le mappage, le script génère un message d’erreur qui vous indique d’exécuter manuellement la commande suivante (en appliquant l’ID de l’espace de travail à la place de l’espace réservé). La commande garantit le mappage correct et redémarre l’agent.

      # 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. Vérifie s’il existe des améliorations de sécurité sur la machine qui peuvent bloquer le trafic réseau (par exemple un pare-feu hôte).

  6. Vérifie que le démon syslog (rsyslog) est correctement configuré pour envoyer les messages (qu’il identifie en tant que CEF) à l’agent Log Analytics sur le port TCP 25226 :

    Fichier de configuration : /etc/rsyslog.d/security-config-omsagent.conf

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

  7. Redémarre le démon syslog et l’agent Log Analytics :

    service rsyslog restart

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

  8. Vérifie que les connexions nécessaires sont établies : TCP 514 pour la réception de données, TCP 25226 pour la communication interne entre le démon syslog et l’agent Log Analytics :

    netstat -an | grep 514

netstat -an | grep 25226

  9. Vérifie que le démon syslog reçoit des données sur le port 514 et que l’agent reçoit les données sur le port 25226 :

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Envoie des données fictives au port 514 sur localhost. Ces données doivent être observables dans l’espace de travail Microsoft Sentinel en exécutant la requête suivante :

    CommonSecurityLog
| where DeviceProduct == "MOCK"

syslog-ng daemon

Pour un démon syslog-ng, le script de validation CEF exécute les vérifications suivantes :

  1. Vérifie que le fichier
    /etc/opt/microsoft/omsagent/[WorkspaceID]/conf/omsagent.d/security_events.conf
    existe et est valide.

  2. Vérifie que le fichier contient le texte suivant :

    <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. Vérifie que l’analyse des événements de pare-feu Cisco ASA est configurée comme prévu à l’aide de la commande suivante :

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

    • En cas de problème avec l’analyse, le script génère un message d’erreur qui vous indique d’exécuter manuellement la commande suivante (en appliquant l’ID de l’espace de travail à la place de l’espace réservé). La commande garantit l’analyse correcte et redémarre l’agent.

      # 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. Vérifie que le champ Ordinateur de la source syslog est correctement mappé dans l’agent Log Analytics en utilisant la commande suivante :

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

    • En cas de problème avec le mappage, le script génère un message d’erreur qui vous indique d’exécuter manuellement la commande suivante (en appliquant l’ID de l’espace de travail à la place de l’espace réservé). La commande garantit le mappage correct et redémarre l’agent.

      # 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. Vérifie s’il existe des améliorations de sécurité sur la machine qui peuvent bloquer le trafic réseau (par exemple un pare-feu hôte).

  6. Vérifie que le démon syslog (syslog-ng) est correctement configuré pour envoyer les messages qu’il identifie en tant que CEF (à l’aide d’une expression régulière) à l’agent Log Analytics sur le port TCP 25226 :

    • Fichier de configuration : /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. Redémarre le démon syslog et l’agent Log Analytics :

    service syslog-ng restart

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

  8. Vérifie que les connexions nécessaires sont établies : TCP 514 pour la réception de données, TCP 25226 pour la communication interne entre le démon syslog et l’agent Log Analytics :

    netstat -an | grep 514

netstat -an | grep 25226

  9. Vérifie que le démon syslog reçoit des données sur le port 514 et que l’agent reçoit les données sur le port 25226 :

    sudo tcpdump -A -ni any port 514 -vv

sudo tcpdump -A -ni any port 25226 -vv

  10. Envoie des données fictives au port 514 sur localhost. Ces données doivent être observables dans l’espace de travail Microsoft Sentinel en exécutant la requête suivante :

    CommonSecurityLog
| where DeviceProduct == "MOCK"

Vérification des prérequis pour le connecteur de données

Utilisez les sections suivantes pour vérifier les prérequis pour votre connecteur de données CEF ou Syslog.

Machine virtuelle Azure en tant que collecteur CEF

Si vous utilisez une machine virtuelle Azure en tant que collecteur CEF, vérifiez les éléments suivants :

  • Avant de déployer le script Python du connecteur de données au format CEF (Common Event Format), vérifiez que votre machine virtuelle n’est pas déjà connectée à un espace de travail Log Analytics existant. Vous pouvez trouver ces informations dans la liste des Machines virtuelles de l’espace de travail Log Analytics, où une machine virtuelle connectée à un espace de travail Syslog est répertoriée comme connectée.

  • Veillez à ce que Microsoft Sentinel soit connecté au bon espace de travail Log Analytics, avec la solution installée SecurityInsights.

    Pour plus d’informations, consultez Etape 1: Déployer le redirecteur de journaux.

  • Assurez-vous que la taille de votre machine est correcte avec au moins les prérequis minimum. Pour plus d’informations, voir les prérequis CEF.

Machine virtuelle locale ou non-Azure

Si vous utilisez une machine locale ou une machine virtuelle non-Azure pour votre connecteur de données, assurez-vous que vous avez exécuté le script d’installation sur une nouvelle installation d’un système d’exploitation Linux pris en charge :

Conseil

Vous pouvez également trouver ce script à partir de la page du connecteur de données Common Event Format dans 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>

Activez votre service CEF et la collecte de gravité du journal

Le serveur Syslog, rsyslog ou syslog-ng, transfère toutes les données définies dans le fichier de configuration approprié, qui est automatiquement rempli par les paramètres définis dans votre espace de travail Log Analytics.

Veillez à ajouter des informations sur les niveaux de journalisation de gravité et d’installation que vous souhaitez ingérer dans Microsoft Sentinel. Le processus de configuration peut prendre environ 20 minutes.

Pour plus d'informations, consultez l’Explication du script de déploiement.

Par exemple, pour un serveur rsyslog, exécutez la commande suivante pour afficher les paramètres actuels de votre transfert Syslog, puis examinez les modifications apportées au fichier de configuration :

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

Dans ce cas, pour rsyslog, une sortie similaire à ce qui suit doit s’afficher :

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

Résoudre les problèmes liés au système d’exploitation

Cette procédure décrit comment résoudre les problèmes qui sont certainement liés à la configuration du système d’exploitation.

Pour résoudre les problèmes liés au système d’exploitation :

  1. Si vous ne l’avez pas encore fait, vérifiez que vous utilisez un système d’exploitation et une version de Python pris en charge. Pour plus d’informations, voir les prérequis CEF.

  2. Si votre Machine virtuelle se trouve dans Azure, vérifiez que le groupe de sécurité réseau (NSG) autorise la connectivité TCP/UDP entrante à partir de votre client de journal (expéditeur) sur le port 514.

  3. Vérifiez que les paquets arrivent dans le Collecteur Syslog. Pour capturer les paquets Syslog arrivant dans le Collecteur Syslog, exécutez :

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

  4. Effectuez l'une des opérations suivantes :

    • Si vous ne voyez pas de paquets arrivant, vérifiez les autorisations du groupe de sécurité NSG et le chemin de routage vers le collecteur Syslog.

    • Si vous voyez des paquets arrivant, vérifiez qu’ils ne sont pas rejetés.

    Si vous voyez des paquets rejetés, vérifiez que les tables IP ne bloquent pas les connexions.

    Pour confirmer que les paquets ne sont pas rejetés, exécutez :

    watch -n 2 -d iptables -nvL

  5. Vérifiez si le serveur CEF traite les journaux. Exécutez :

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

    Les journaux CEF en cours de traitement sont affichés en texte brut.

  6. Vérifiez que le serveur rsyslog est à l’écoute sur le port TCP/UDP 514. Exécutez :

    netstat -anp | grep syslog

    Si des journaux CEF ou ASA sont envoyés à votre Collecteur Syslog, vous devriez voir une connexion établie sur le port TCP 25226.

    Par exemple :

    0 127.0.0.1:36120 127.0.0.1:25226 ESTABLISHED 1055/rsyslogd

    Si la connexion est bloquée, il est possible que vous ayez soit une connexion SELinux bloquée vers l’agent OMS, soit un processus de pare-feu bloqué. Utilisez les instructions appropriées ci-dessous pour déterminer le problème.

SELinux bloquant la connexion à l’agent OMS

Cette procédure décrit comment vérifier si SELinux est actuellement dans un état permissive ou s’il bloque une connexion vers l’agent OMS. Cette procédure s’applique lorsque votre système d’exploitation est une distribution à partir de RedHat ou de CentOS, tant aux connecteurs de données CEF que Syslog.

Notes

La prise en charge de Microsoft Sentinel pour CEF et Syslog comprend uniquement le renforcement des normes FIPS (Federal Information Processing Standard). D’autres méthodes de renforcement de la sécurité, telles que SELinux ou CIS, ne sont pas prises en charge actuellement.

  1. Exécutez :

    sestatus

    L’état peut afficher l'une des valeurs suivantes :

    • disabled. Cette configuration est prise en charge pour votre connexion à Microsoft Sentinel.
    • permissive. Cette configuration est prise en charge pour votre connexion à Microsoft Sentinel.
    • enforced. Cette configuration n’est pas prise en charge et vous devez soit désactiver l’état, soit lui affecter la valeur permissive.

  2. Si l’état est défini sur enforced, désactivez-le temporairement pour confirmer s’il s’agissait du bloqueur. Exécutez :

    setenforce 0

    Notes

    Cette étape désactive SELinux uniquement jusqu’au redémarrage du serveur. Modifiez la configuration de SELinux pour la conserver désactivée.

  3. Pour vérifier si la modification a réussi, exécutez :

    getenforce

    L'état permissive doit être retourné.

Important

Cette mise à jour du paramètre est perdue lors du redémarrage du système. Pour actualiser ce paramètre de manière permanente sur permissive, modifiez le fichier /etc/selinux/config, en modifiant la valeur de SELINUX sur SELINUX=permissive.

Pour plus d’informations, consultez la documentation RedHat.

Stratégie de pare-feu bloquée

Cette procédure décrit comment vérifier si une stratégie de pare-feu bloque la connexion entre le démon rsyslog et l’agent OMS, et comment la désactiver si nécessaire. Cette procédure s’applique tant aux connecteurs de données CEF que Syslog.

  1. Exécutez la commande suivante pour vérifier s’il existe des rejets dans les tables IP, indiquant que le trafic est abandonné par la stratégie de pare-feu :

    watch -n 2 -d iptables -nvL

  2. Pour conserver la stratégie de pare-feu activée, créez une règle de stratégie pour autoriser les connexions. Ajoutez des règles en fonction des besoins pour autoriser les ports TCP/UDP 25226 et 25224 via le pare-feu actif.

    Par exemple :

    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. Pour créer une règle en fonction des besoins pour autoriser les ports TCP/UDP 25226 et 25224 via le pare-feu actif.

    1. Pour installer l’éditeur de Stratégie de pare-feu, exécutez :

      yum install policycoreutils-python

    2. Ajoutez les règles de pare-feu à la stratégie de pare-feu. Par exemple :

      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. Vérifiez l’ajout de l’exception. Exécutez :

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

    4. Rechargez le pare-feu. Exécutez :

      sudo firewall-cmd --reload

Notes

Pour désactiver le pare-feu, exécutez : sudo systemctl disable firewalld

Si les étapes décrites plus haut dans cet article ne résolvent pas votre problème, il se peut que vous rencontriez un problème de connectivité entre l’agent OMS et l’espace de travail Microsoft Sentinel.

Dans ce cas, poursuivez la résolution des problèmes en vérifiant les éléments suivants :

  • Vérifiez que vous pouvez voir les paquets arrivant sur le port TCP/UDP 514 sur le collecteur Syslog

  • Assurez-vous que vous pouvez voir les journaux écrits dans le fichier journal local, soit /var/log/messages ou /var/log/syslog

  • Vérifiez que vous pouvez voir les paquets de données transiter par le port 25226

  • Assurez-vous que votre machine virtuelle dispose d’une connexion sortante vers le port 443 via TCP ou peut se connecter aux points de terminaison de Log Analytics

  • Vérifiez que vous avez accès aux URL requises à partir de votre collecteur CEF par le biais de votre stratégie de pare-feu. Pour plus d’informations, consultez Configuration requise du pare-feu de l’agent Log Analytics.

Exécutez la commande suivante pour déterminer si l’agent communique avec succès avec Azure, ou si l’agent OMS ne peut se connecter à l’espace de travail Log Analytics.

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

Une entrée de journal est retournée si l’agent communique avec succès. Dans le cas contraire, l’agent OMS peut être bloqué.