Résoudre les problèmes liés à CEF et Syslog via les connecteurs AMA

Cet article fournit des conseils de dépannage pour la collecte de données CEF (Common Event Format) et Syslog à l’aide de l’agent AZURE Monitor (AMA) dans Microsoft Sentinel. Utilisez ce guide pour diagnostiquer et résoudre les problèmes d’ingestion avec vos machines de transfert de journaux. Les commandes et configurations doivent être exécutées sur les ordinateurs redirecteurs de journaux où AMA et RSyslog/Syslog-ng sont installés.

Avant de commencer la résolution des problèmes, familiarisez-vous avec les articles suivants :

Vue d’ensemble de l’architecture

Le diagramme suivant illustre le flux de données entre les sources de journaux et les espaces de travail Microsoft Sentinel/Log Analytics via RSyslog et l’agent Azure Monitor.

Diagramme montrant le flux de données de la source vers Log Analytics via RSyslog et AMA.

Composants clés :

  • RSyslog/Syslog-ng : reçoit les journaux sur le port 514 et les transfère à AMA
  • Agent Azure Monitor : traite les journaux conformément aux règles de collecte de données (DCR)
  • Règle de collecte de données : définit les journaux à collecter et où les envoyer

Étapes de vérification initiales

Vérifier que les journaux sont reçus

L’affichage des journaux peut prendre jusqu’à 20 minutes dans Microsoft Sentinel après la configuration.

  1. Exécutez tcpdump pour vérifier que les journaux arrivent au redirecteur :

    sudo tcpdump -i any port 514 -A -vv

  2. Vérifiez que votre source de journal est configurée pour envoyer des messages à l’adresse IP du redirecteur approprié.

  3. Recherchez les composants d’infrastructure susceptibles d’affecter la connectivité :

    • Pare-feu
    • Équilibreurs de charge
    • Groupes de sécurité réseau

Vérifier Azure status d’extension de l’agent Monitor

  1. Dans le Portail Azure, accédez à votre machine virtuelle de redirecteur de journaux.
  2. Sélectionnez Extensions + applications.
  3. Sélectionnez l’extension AzureMonitorLinuxAgent .
  4. Vérifiez que l’état indique Que l’approvisionnement a réussi.

Vérifier la version de l’agent

  1. Dans le panneau extension AzureMonitorLinuxAgent, case activée le champ Version.
  2. Vérifiez que la version est l’une des 2 à 3 versions les plus récentes. Consultez les détails de la version AMA pour connaître les dernières versions.

Remarque

Le déploiement des nouvelles versions peut prendre jusqu’à 5 semaines après la publication initiale.

Résolution des problèmes au niveau de l’agent

Assurez-vous que l’agent et les services RSyslog sont en cours d’exécution.

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

Vérifier la configuration de RSyslog

La configuration RSyslog se compose des /etc/rsyslog.conf fichiers et dans /etc/rsyslog.d/.

  1. Vérifiez la configuration du port :

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

    Sortie attendue :

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

  2. Vérifiez que la configuration de transfert AMA existe :

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

    Le fichier doit commencer par :

    # Azure Monitor Agent configuration: forward logs to azuremonitoragent

Vérifier l’status de port

Vérifiez que les ports requis sont à l’écoute :

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

Sortie attendue :

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

Cela confirme les points suivants :

  • RSyslog écoute sur le port 514 (TCP et UDP)
  • MDSD (composant AMA) écoute sur le port 28330 (TCP)

Vérifier la configuration de la règle de collecte de données

Vérifiez si la DCR est correctement configurée sur l’agent.

Pour les journaux CEF :

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

Pour les journaux Cisco ASA :

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

La sortie doit afficher une chaîne JSON contenant la configuration DCR.

Passer en revue les règles de pare-feu

Vérifiez que les règles de pare-feu autorisent la communication entre :

  • Source du journal et RSyslog (port 514)
  • RSyslog et AMA (port 28330)
  • Points de terminaison AMA et Azure

Configuration de la règle de collecte de données

Activer toutes les fonctionnalités de résolution des problèmes

Pour la résolution initiale des problèmes :

  1. Dans le Portail Azure, accédez à votre règle de collecte de données.
  2. Activez toutes les fonctionnalités syslog.
  3. Sélectionnez tous les niveaux de journalisation.
  4. Si disponible, activez la collecte des messages sans aucune fonctionnalité ni gravité.

Pour plus d’informations, consultez Sélectionner des installations et des gravités.

Validation cef (Common Event Format)

Conditions requises pour le format CEF

CEF utilise Syslog comme mécanisme de transport avec cette structure :

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

Exemple :

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

Problèmes courants de mise en forme cef

Format d’en-tête incorrect

  • Vérifiez que la version du CEF est présente : CEF:0|
  • Tous les champs d’en-tête doivent être présents et délimités par des caractères de barre verticale (|)

Échappement de caractères incorrect

  • Les caractères de canal (|) dans les valeurs d’en-tête doivent être placés dans une séquence d’échappement : \|
  • Les barres obliques inverses () doivent être placées dans une séquence d’échappement : \\
  • Les signes égaux (=) dans les extensions doivent être placés dans une séquence d’échappement : \=

Valeurs manquantes ou non mappées

Pour obtenir la spécification CEF complète, recherchez la documentation « Implémentation d’ArcSight Common Event Format (CEF) ».

Dépannage avancé

Activer le suivi des diagnostics

Avertissement

Activez les indicateurs de trace uniquement pour les sessions de résolution des problèmes. Les indicateurs de trace génèrent une journalisation complète qui peut remplir rapidement l’espace disque.

  1. Modifiez le fichier de configuration AMA :

    sudo vim /etc/default/azuremonitoragent

  2. Ajoutez des indicateurs de trace à la ligne 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. Redémarrez l’agent :

    sudo systemctl restart azuremonitoragent

  4. Reproduisez le problème et attendez quelques minutes.

  5. Passez en revue les informations de débogage dans /var/opt/microsoft/azuremonitoragent/log/mdsd.info.

  6. Supprimez l’indicateur de trace et redémarrez l’agent après la résolution des problèmes.

Surveiller le traitement des journaux en temps réel

Affichez les journaux entrants à mesure qu’ils sont traités :

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

Filtrez les types de journaux spécifiques :

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

Passez en revue les journaux d’activité d’installation spécifiques :

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

Vérifier que le traitement des journaux a réussi

Lorsque les indicateurs de trace sont activés, vous pouvez vérifier que les journaux sont traités correctement en examinant la sortie de débogage.

Exemple d’ingestion de journal ASA

Pour les journaux Cisco ASA, le traitement réussi s’affiche dans les journaux comme suit :

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

Indicateurs clés d’un traitement réussi :

  • L’événement est reconnu comme un événement CiscoASA
  • Le journal est chargé dans ODS (Operations Data Service)
  • Un ID de requête est généré pour le suivi
  • La charge utile contient des données JSON correctement mises en forme

Exemple d’ingestion des journaux CEF

Pour les journaux CEF, le traitement réussi s’affiche comme suit :

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

Indicateurs clés d’un traitement CEF réussi :

  • Le type de données est SECURITY_CEF_BLOB
  • La demande de chargement inclut un point de terminaison valide
  • La structure de message CEF est conservée dans la charge utile
  • Les métriques de compression indiquent que les données sont optimisées pour le transfert

Importante

N’oubliez pas de désactiver les indicateurs de trace une fois votre investigation terminée pour éviter une utilisation excessive du disque.

Collecter des informations de diagnostic

Avant d’ouvrir un cas de support, collectez les informations suivantes :

Exécuter l’utilitaire de résolution des problèmes AMA

Le script peut être exécuté avec des indicateurs spécifiques pour différents types de journaux.

  • --cef: pour les journaux de format d’événement commun
  • --asa: Pour les journaux Cisco ASA
  • --ftd: Pour les journaux Cisco Firepower Threat Defense

La sortie est enregistrée dans /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]

Contenu connexe

  • Last updated on