Partager via

Résoudre les problèmes liés à CEF et Syslog via des 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 redirectrices de journaux. Les commandes et configurations doivent être exécutées sur les ordinateurs du redirecteur 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 des sources de journaux vers les espaces de travail Microsoft Sentinel/analytique des journaux d'activité 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 des journaux sur le port 514 et les transfère à l'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 logs sont bien reçus

Après la configuration, jusqu’à 20 minutes peuvent être nécessaires pour que les journaux apparaissent dans Microsoft Sentinel.

  1. Exécutez tcpdump pour vérifier que les logs arrivent au forwarder :

    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 correcte.

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

    • Firewalls
    • Équilibreurs de charge
    • Groupes de sécurité réseau

Vérifier l’état de l’extension de l’agent Azure Monitor

  1. Dans le portail Azure, accédez à votre machine virtuelle redirectrice 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 de l’extension AzureMonitorLinuxAgent , vérifiez le champ Version .
  2. Assurez-vous que la version est l'une des 2 ou 3 versions les plus récentes. Consultez les détails de la version AMA pour les dernières versions.

Note

Les nouvelles versions peuvent prendre jusqu’à 5 semaines pour être déployées après la version initiale.

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

Assurez-vous que les services de l'agent et de 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 de /etc/rsyslog.conf et de fichiers 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 du 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’état du 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 :

  • 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 de logs 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 pour la résolution des problèmes

Pour la résolution des problèmes initiaux :

  1. Dans le portail Azure, accédez à votre règle de collecte de données.
  2. Activez toutes les installations syslog.
  3. Sélectionnez tous les niveaux de journalisation.
  4. Si cela est possible, activez la collecte de messages ne comportant ni fonction ni niveau de gravité.

Pour plus d’informations, consultez Sélectionner les fonctionnalités et les niveaux de gravité.

Validation du format d’événement commun (CEF)

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

Échappement de caractères incorrect

  • Les caractères de barre verticale (|) dans les valeurs d’en-tête doivent être échappés : \|
  • Les barres obliques inverses () doivent être échappées : \\
  • Les signes égal (=) dans les extensions doivent être échappés : \=

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 étendue 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. Reproduire le problème et attendre 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

Consultez les logs entrants au fur et à mesure qu’ils sont traités.

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

Filtrez sur des types de journaux spécifiques :

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

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

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

Vérifier que le traitement du journal a réussi

Lorsque les indicateurs de trace sont activés, vous pouvez vérifier que les journaux d'activité 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 du 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 de fichier journal CEF

Pour les journaux CEF, le traitement réussi apparaît ainsi :

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 du 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 montrent que les données sont optimisées pour le transfert

Important

N’oubliez pas de désactiver les indicateurs de trace après avoir terminé votre examen pour éviter une utilisation excessive du disque.

Collecter des informations de diagnostic

Avant d’ouvrir un dossier 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 paramètres spécifiques pour différentes catégories de logs.

  • --cef : pour les journaux Common Event Format
  • --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